Jump to content

dahotvet

Members
  • Content count

    2
  • Joined

  • Last visited

Community Reputation

0 Neutral

About dahotvet

  • Rank
    Newbie
  1. dahotvet

    1018 error: not enough memory

    Thanks David for the comments, particularly where ASM is not required for submission. Did not know that. Will be filing a report. Under normal circumstances in a larger shop, I would be upgrading in a test environment to ensure that everything works before release to production. Unfortunately, that is difficult in our setup. The issue does not seem to be related to backing up a windows client, rather a Linux NAS box via Samba that has been static for years to a local Raid on the server. I was contemplating using a Linux client, but did not get that far (yet). I installed Windows 15.6.1.104 on 10/18/2019, almost a year after it was released on November 29, 2018. 15.1.2 was installed on 7/22/2018, a month after it was released on June 13, 2018 After 15 years, I was at the very edge of giving up on Retrospect and finding another solution. The reason I wrote this up was that I was unable to find ANY similar instance and that there was similarly little to no documentation I could find on the ini file parameters, let alone how and when to modify them. Figuring there may be others with similar problems, I wanted to leave at least one crumb for someone else...
  2. dahotvet

    1018 error: not enough memory

    This is for others who have had this problem described in the title. I have found little to no guidance for how to deal with this error. It would pop up nearly every day and would require a reboot to fix. Completely unacceptable as a backup solution. Long time Retrospect Professional for Windows user (started with 7.0), small business environment with somewhat regular upgrades (5), currently on Retrospect 15.6.1 in a now primarily Windows 10 environment with a 24 TB Raid WD Linux NAS for primary network storage. Multiple machines, multiple redundant stores and duplicate locations. Approximately 60TB of storage and backup under management. Generally works well, having experienced many of the usual warts. Runs on Windows 10 Professional i7 machine with 16 GB memory (now 32 GB), mostly dedicated as a backup machine with 32 TB of local Raid storage With 15.1 installed 7/2018, we started getting occasional -1018 errors: not enough memory. Sometimes shows as -1019 Could not find any guidance on 1018 errors, but found this old forum reference for 1019. No help. Multiple reboots. Same problem. Reinstall. No difference. Upgraded to 15.6.1 in 10/2019. No difference. Upgraded from 16 GB to 32 GB memory. No difference. Modified several of the backup scripts. No difference. Found we could only go 1 day or so before the 1018 errors, requiring a reboot of the server machine to clean. Unacceptable as a backup solution. The largest backup set manages 500k files, 70k folders and 3TB Rethink. Every update was done in place. The config77.dat was 17MB, seemed larger than it needed to be. Exported the configuration XML. Uninstall Retrospect with reboots. Cleaned out the ProgramData/RetroISA and Retrospect directories (backups of the directories in separate sub-directories) Install 15.6.1 with reboots. License Key and imported the config XML. Had to re-input the many sub-volumes for the source and destination for each script. Ran well for a day, then the same 1018 errors, this time with a duplication script. Reboot and same problem within a day. Take a closer look at memory usage. RetroISA stayed constant at 430 MB working set Retrospect working set would vary between 57 MB and 242 MB, depending on the script being run. Examined the retro.ini and retro_isa.ini files for any possible memory clues. Could not find anything relevant in a lit search. In retro.ini there are two: MemBlockKB=8192 and MaxMemPercent=30 Could not find anything in the Retrospect support areas nor the forum nor anywhere else 😞 Arbitrarily doubled the memory to: MemBlockKB=16384 and the nearly doubled the MaxMemPercent=50 Have not experienced that error (nor any other error) since, running for several days and many more scripts than usual, both backups and duplicates. At this point I don't know if we are on the edge of similar errors or if we have completely over killed the problem. Don't like being blind on problems like this. YMMV.
×