one volume is backing up almost 100% daily

[colletti]

Hello! I need some help! We have a new backup server (dual xeon, 4g ram) running retrospect 7.5.324 with hotfix 7.5.6.105. We run D2D2T with incremental monday-friday, and transfer to tape over the weekend. One volume on one of our servers (redhat 9) seems to be doing a full backup every night (600,000+ files nightly!!!), instead of incremental as specified. And the other three volumes on this machine are successfully running incremental backups daily.

 

Can anyone point me in a direction to go from here? We have 600G of space to backup two machines that have approximately 145G worth of data. And this is filling up the 600G in roughly one week worth of backups!

 

Thanks.

[RonaldL]

Do other volumes on this RH9 server show this problem? If you examine the snapshots from two different days and get properties for a certain file that should not have changed, do the attributes match exactly for the two days? Also, take a look at the operations log to see if there are any errors/warnings when backing up this volume. Also be sure to update Retrospect as there were some issues with duplicate data being backed up from clients.

[colletti]

Thank you for the repy. We are backing up four volumes on this RH9 machine. Two of the four volumes backup just fine with incrementals. But the other two volumes seem to be doing full backups nightly.

 

We looked at snapshots from two different days, and more specifically at one particular file and it did not change at all. And the snapshots looked almost identical on both days.

 

Next we checked the Operations Log. Again both backups (from the two snapshots mentioned above) are similar. Here is the output from the operations log for backups on 12/14-15 and 12/31;

 

12/14/2006 8:34:05 PM: Copying /home on ares

12/15/2006 4:52:27 AM: Snapshot stored, 155.1 MB

12/15/2006 4:52:48 AM: Comparing /home on ares

File "/home/quota.user": different modify date/time (set: 12/14/2006 6:00:04 AM, vol: 12/15/2006 4:17:03 AM)

12/15/2006 6:00:47 AM: 1 execution errors

Completed: 663557 files, 60.1 GB

Performance: 221.9 MB/minute (126.4 copy, 905.5 compare)

Duration: 09:26:41 (00:13:04 idle/loading/preparing)

 

-----

 

12/31/2006 9:22:09 AM: Copying /home on ares

12/31/2006 11:55:40 AM: Snapshot stored, 156.4 MB

12/31/2006 11:56:13 AM: Comparing /home on ares

File "/home/mullins/align2/35-file.en": different modify date/time (set: 12/29/2006 10:09:18 PM, vol: 12/31/2006 2:07:56 PM)

File "/home/mullins/align2/35-file.zh": different modify date/time (set: 12/29/2006 10:09:13 PM, vol: 12/31/2006 2:08:00 PM)

12/31/2006 1:24:41 PM: 2 execution errors

Completed: 663527 files, 60.1 GB, with 38% compression

Performance: 524.9 MB/minute (421.5 copy, 695.7 compare)

Duration: 04:02:31 (00:08:18 idle/loading/preparing)

[Lennart_T]

Historically, changing the time zone and/or daylight savings time has caused full backups. I think that's been fixed in recent versions of Retrospect, but it might be worth looking into.

[colletti]

Thanks for the reply and idea. Unfortunately we have not changed the time zone or anything to that effect.

 

I'm beginning to think this is not a problem with the Retrospect backup app itself, but maybe with the client? We run two backup groups nightly that backup five of our servers. Out of those five machines and all those directories, only two seem to be a problem, and they are both on the same machine...