Jump to content

Strange new problem - help


DMULLARD

Recommended Posts

I run Retrospect Pro 7.5 to backup my Windows Vista Ultimate PC to a NAS drive. I do an automatic backup once a week. Up until 9 February it typically took 40-50 minutes to run. On the 16 February it ran for about 5 hours but finished ok. There was an error message, see log. On 23 February it ran for a few hours and then failed. There was an assert log. I ran it manually and though it took nearly 3 hours it finished ok. Every week since it has done the same as that. So there are 2 symptoms. It runs much longer and the automatic update fails producing an assert error log, near the end I would guess. A manual run always works. The only thing that I can think of is that there was a particularly large batch of Windows updates on the 14 February automatic update.

 

Though the log is for the 7.5.387 version I have since installed 7.5.508 and it still does the same.

 

Some of the log.

 

+ Retrospect version

Automatically launched at 09/02/2008 10:00

 

+ Normal backup using Weekly at 09/02/2008 10:00

To Backup Set Backup Set A (Antec)...

 

- 09/02/2008 10:00:35: Copying Local Disk (C:)

09/02/2008 10:37:01: Snapshot stored, 201.5 MB

09/02/2008 10:37:51: Comparing Local Disk (C:)

09/02/2008 10:53:53: Execution completed successfully

Completed: 2393 files, 28.2 GB, with 96% compression

Performance: 1649.4 MB/minute (1525.5 copy, 1797.0 compare)

Duration: 00:53:18 (00:18:24 idle/loading/preparing)

 

Exit at 09/02/2008 10:54

 

+ Retrospect version 7.5.387

Launched at 09/02/2008 11:08

+ Driver Update and Hot Fix, version 7.5.13.100

Exit at 09/02/2008 11:10

 

+ Retrospect version

Automatically launched at 16/02/2008 11:27

Can't save "Config75.bak", error -1018 (not enough memory)

Can't save "Config75.bak", error -1018 (not enough memory)

 

+ Normal backup using Weekly at 16/02/2008 11:28

To Backup Set Backup Set A (Antec)...

 

- 16/02/2008 11:28:06: Copying Local Disk (C:)

16/02/2008 16:00:09: Snapshot stored, 212.0 MB

16/02/2008 16:01:48: Comparing Local Disk (C:)

16/02/2008 16:21:48: Execution completed successfully

Completed: 8417 files, 30.0 GB, with 93% compression

Performance: 1453.9 MB/minute (1379.5 copy, 1536.5 compare)

Duration: 04:53:43 (04:11:33 idle/loading/preparing)

 

Exit at 16/02/2008 16:22

 

+ Retrospect version

Automatically launched at 23/02/2008 11:10

Can't save "Config75.bak", error -1018 (not enough memory)

 

+ Retrospect version 7.5.387

Launched at 23/02/2008 14:16

+ Driver Update and Hot Fix, version 7.5.13.100

Exit at 23/02/2008 14:20

 

+ Retrospect version 7.5.387

Launched at 23/02/2008 14:23

+ Driver Update and Hot Fix, version 7.5.13.100

Exit at 23/02/2008 14:24

 

+ Retrospect version 7.5.387

Launched at 23/02/2008 14:43

+ Driver Update and Hot Fix, version 7.5.13.100

 

+ Executing Immediate Backup at 23/02/2008 14:45

To Backup Set Backup Set A (Antec)...

 

- 23/02/2008 14:45:22: Copying Local Disk (C:)

23/02/2008 17:26:40: Snapshot stored, 215.4 MB

23/02/2008 17:27:29: Comparing Local Disk (C:)

23/02/2008 17:33:17: Execution completed successfully

Completed: 808 files, 12.2 GB, with 98% compression

Performance: 2170.3 MB/minute (2195.9 copy, 2145.2 compare)

Duration: 02:47:55 (02:36:28 idle/loading/preparing)

 

Exit at 23/02/2008 18:13

 

Link to comment
Share on other sites

I have just tried that. I deleted Config75.bak and set up to do an automatic backup. It did the same as before. It ran for nearly 5 hours and then failed. I hadn't mentioned that it is failing with the error

 

Assertion failure at 'tmemory.cpp-1203'.

 

Should I be deleting the Config75.dat file as well?

Link to comment
Share on other sites

I have done a few tests.

 

Deleting Config75.bak or Config75.dat makes no difference. I discovered that you cannot delete both at once.

 

I have a second internal hard disk, 500GB and nearly empty. To eliminate my NAS drive as cause of the problem, I set up a new backup of my C drive to that drive. That was run manually. It took nearly 9 hours, which seems a bit long, but finished ok. I then set up an automatic backup to the same backup set and that failed as before. This still ran for nearly 5 hours even though there must have been almost nothing to backup. See edited log below. That eliminates the NAS drive, and the existing backup set as causes of the problem. It seems to me that this must be a windows problem. The difference bewtween the ones that work and those that don't is that the ones run manually are run under my Admin user where as the automatic ones run as a System task.

 

+ Retrospect version 7.5.508

Launched at 17/03/2008 20:22

+ Driver Update and Hot Fix, version 7.5.13.100

 

+ Executing Immediate Backup at 17/03/2008 20:28

To Backup Set Backup Set B...

 

- 17/03/2008 20:28:50: Copying Local Disk (C:)

18/03/2008 01:48:44: Snapshot stored, 239.0 MB

18/03/2008 01:49:37: Comparing Local Disk (C:)

File "C:\Users\Public\Documents\microsoft\Manuals\Step by Step Guide to Controlling Device Installation and Usage with Group Policy.doc": didn't compare

18/03/2008 05:14:45: 1 execution errors

Completed: 343501 files, 163.4 GB, with 47% compression

Performance: 785.0 MB/minute (755.0 copy, 816.9 compare)

Duration: 08:46:14 (01:43:44 idle/loading/preparing)

 

Exit at 18/03/2008 07:46

 

 

+ Retrospect version

Automatically launched at 18/03/2008 11:00

Can't save "Config75.bak", error -1018 (not enough memory)

Can't save "Config75.bak", error -1018 (not enough memory)

 

 

Link to comment
Share on other sites

  • 1 year later...

I think that this problem is due to Retrospect being a 32-bit application. We have been having similar problems. We have an 8GB RAM server running Retrospect, and Retrospect is only able, in theory, to use 4GB of that RAM. In reality, I've never seen Retro get above 2GB, though.

 

I've been working with EMC on this, and we are in agreement that in order to correct these problems, Retrospect needs to be able to access more memory. The real way to fix this is to make the program 64-bit.

Link to comment
Share on other sites

I think that this problem is due to Retrospect being a 32-bit application. We have been having similar problems. We have an 8GB RAM server running Retrospect, and Retrospect is only able, in theory, to use 4GB of that RAM. In reality, I've never seen Retro get above 2GB, though.

 

I've been working with EMC on this, and we are in agreement that in order to correct these problems, Retrospect needs to be able to access more memory. The real way to fix this is to make the program 64-bit.

 

It's very unlikely this problem (or any problem relating to Retrospect) has to with a lack of memory or Retrospect's being 32-bit. I have yet to see any backup task or tasks where a 64-bit version of Retrospect would be beneficial let alone required. It's far more likely you'll run of execution slots and backup windows on a single copy of Retrospect before you'll run out of RAM.

 

I run Retrospect Pro 7.5

 

What if you ran this with 7.6.123?

Link to comment
Share on other sites

In 32-bit Windows, each task is limited to 2 GB, not 4 GB. 4 GB is the limit for total memory without using PAE (of which only a little over 3 GB is usable), but each process gets max 2 GB even if using PAE to break the 4 GB barrier.

So 32-bit Retrospect not being able to use more than 2 GB seems correct for a single-process application.

 

 

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.

Guest
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.

Loading...
×
×
  • Create New...