Jump to content

1018 error: not enough memory


Recommended Posts

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.
Link to comment
Share on other sites


Here's why and how to file a Support Case for a bug 

When you do that, be sure to state the precise Windows 10 versions of your "backup server" and all your "client" machines.  Although I'm a Retrospect Mac administrator, I notice that the cumulative Retrospect Windows Release Notes for versions later than 15.6.1 (which you seem to have installed a month before it was released) list several "New Windows 10 ... Update certification" items.  I presume you have not frozen your installation Windows updates the way you have frozen your Retrospect updates.

If you upgrade now, I believe you are entitled to a 30-45-day trial period.  If you do that now, you'll be entitled to a free upgrade to Retrospect 17, which is predicted to be released in March 2020.  However, if R.T.S. can give you a version of Retrospect Windows 16 that fixes your problem, you may want to stay with it for a while—because IMHO there are indications that the Retrospect Windows GUI will change substantially in either March or August 2020.


Link to comment
Share on other sites

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 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...
Link to comment
Share on other sites


The reason there isn't a sticky post in every Forums thread saying that ASM isn't required for bug submission is that Retrospect Tech Support evidently doesn't want administrators to know that fact.  That is because the budget of R.T.S. has long been dependent on ASM, a Retrospect Inc. policy that is IMHO a major contributor to the reputation for slow-to-non-existent bug fixing that has long plagued the product.

IMHO the reason you were unable to find instances related to your problem is that you were too cagey in your "Forums Search Fu" (analogous to "Google Fu").  You concentrated on the Windows error code, instead of using the search terms "NAS" and "Samba".  Let's cut to the chase; here's the first applicable post in a 1.5-week-old Windows-Professional thread whose problem turned out to be soluble by upgrading from SMB1 to SMB2—even though the OP insists on running his/her "backup server" on Windows 7.  The OP is running a Netgear ReadyNAS server.

You don't say what variety your "Linux NAS box via Samba" is, but here's another thread in which the OP is running a Synology server.  That thread is about a Mac "backup server", and the OP is using the obsolete Apple Filing Protocol instead of any version of SMB/Samba.  As a Retrospect Macintosh administrator, my impression from several recent Forums threads is that the "backup server" Engine—which is the same for both variants of Retrospect aside from GUI—lost its ability in version 15 to handle certain old versions of network protocols used by NASes.

Try looking in the Operations Log, as described on pages 344 "Finding Events in the Operations Log" and 345-346 of the Retrospect Windows 15 User's Guide.

Sorry I got the year wrong on when you updated from 15.1.2 to 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Create New...