Jump to content

Incremental failing


Recommended Posts

We use desktop 4.3 to back up a Snap Server to an Ecrix drive on a Mac with 9.2. Typically we use two backups, with incremental data adding up to between 500MB and 1GB every 2 days. I will run these two sets the whole year and then do a new set on Jan. 1. This has been working well for the last two years. However, this week, both of my automated sets backed up the entire server (over 40 GB). Is there some setting I can change or adjust to prevent this? Or is there some reason that Retrospect sees all new files?

Link to comment
Share on other sites

  • 3 weeks later...

Retrospect uses several matching criteria to compare files that have already been backed up to what is about to be backed up. If one of the following has been changed at all, Retrospect will back up the file again: name, size, type, creator, creation date and time, modify date and time, and label.

 

 

 

If Retrospect is reporting that it is about to back up files you know have not changed since your last backup, take a closer look at a sample file. Choose a file and start a restore by search for that file. When you get to the final window (you don't actually have to do the restore), click Files Chosen and Get Info (type Command-I) on the most recent version of the file on the backup. Print or take a screenshot of this window.

 

 

 

Now, go to the Configure tab from the Retrospect Directory and click Volumes. Choose the volume the file is on and click Browse. Find the file in question and Get Info on it. Put the two windows side by side and look for even the slightest difference in any of the criteria I listed above.

 

 

 

Many things can cause a change in a file, even if the file has not been accessed by the user. The operating system, as well as applications, are constantly making changes to files. Further, whenever you change time zones in the Date & Time control panel, your creation and modify dates are offset. We have also found an issue in Mac OS 8.1 with HFS+ formatted volumes where changing the Daylight Savings Time setting offsets the creation and modify dates of all files.

 

 

 

There is also an issue where AppleShare might make a time translation when connecting to another machine whose time is off by more than a certain number of minutes. This time translation would also offset the creation and modify dates of all files. I have also seen this happen when upgrading operating systems or doing a complete restore of data with Retrospect.

 

 

 

Unfortunately the only known way around this problem is to do a full backup of your data. I know of no way to force file attributes to regress to the way they were before. Either do a full backup or use this time to introduce new media.

 

 

 

You should also look at the Backup Set configuration window. From the Retrospect Directory click Configure, then Backup Sets. Choose the set and click Configure. Click Members. Are any members marked "Missing?" If so, mark them found again. Retrospect will attempt to recopy any files on a member marked as missing.

 

 

Link to comment
Share on other sites

I am seeing a simlar problem and it has me baffled.

 

 

 

I am running Retrospect Desktop 5.0.205 at home under OS 9.2 on a beige G3 w/ built-in SCSI. I have two backup devices, both from APS Technology: a Sony SDT 9000 DAT drive, and a Yamaha CRW6416S (firmware 1.0d).

 

 

 

I backup two clients using Retrospect client 1.0.427: another similar G3 running OS X, and my Ti PowerBook running OS X.

 

 

 

On my OS X G3 client, I have a partition called "Archive" which has a top-level folder called "Documents" in which I store...things I want to archive.

 

 

 

Perhaps the upgrade to Retrospect 5 is a red herring, but prior to upgrading to version 5 my

 

"Archive" script worked just fine to incrementally backup the above remote client Documents folder to CD-R media. Now however it seems to ALWAYS want to do a FULL backup, despite me having not changed (and having confirmed) all of the normal/default incremental settings, and effectively "no time" (only a few hours) passing between attempts.

 

 

 

1. I tried doing a "normal" (incremental) backup to my existing (pre-upgrade) Archive set, and it wanted to backup all 7.5 GB. I went ahead anyway. A media request timed out after about 10 disks (I was asleep) so it quit. I checked the catalog and it appeared to have the correct snapshots and disk members.

 

2. I tried doing a "normal" (incremental) backup to that incomplete set, and it wanted to backup all 7.5 GB again. I went ahead and fed it disks to cover all 7.5 GB, and it completed "successfully".

 

3. I immediately ran the same script (with a normal/incremental setting). Retrospect scanned the folder (surprisingly quickly) and then proceeded to try and backup all 7.5 GB again.

 

 

 

4. I chose the option to make a new catalog/set (Archive [001]) and ran the script w/ that. It backed up all 7.5 GB onto 12 or so disks. When it was done, I checked the snapshots, members, etc. All of these indicated that the backup set was "aware" that I had just backed-up everything.

 

5. I immediately ran the same script with a normal/incremental setting. Retrospect scanned the folder (surprisingly quickly) and then proceeded to try and backup all 7.5 GB again.

 

 

 

6. I re-booted the machine and tried again. Same thing. It wants to backup everything.

 

 

 

7. I tried to re-build the catalog from the disks. I patiently fed the drive all 12 disks, it says it completed successfully, but then if I try and do an incremental backup it trys to backup all 7.5 GB again.

 

 

 

I found it strange that both backup sets (before and after re-build--I saved the original) seem to be relatively small to me, on the order of 200 KB. Perhaps since there are only about 500 files (a lot of stuffit archives) this makes sense, but it surprised me a little.

 

 

 

I don't know what else to try at this point. I might run a disk utility (Disk Warrior) on the server's partition to see if there is some problem w/ the catalog file, but beyond that I don't know what to try.

 

 

 

Any suggestions would be welcome. I'm not terribly excited about having to pay for support on a product I just purchased (upgraded).

 

 

 

Thanks.

 

Greg Welch

 

 

Link to comment
Share on other sites

The result of the "Get Info" test, applied to several files and folders, is that the files and folders are identical. Date and time stamps, owner, permissions, etc. I did not check all 500 files, but maybe 10, and some enclosing folders.

 

 

 

I should also note that my "Nightly" backup to the DAT drive seems to "increment" flawlessly. This is from the same client as the "Archives" but a different partition. The source for the Archives script is my Archives partition on that client, the source for the Nightly script is the boot partition.

 

 

 

I have since booted from the OS 9 CD and run Alsoft's Disk Warrior on the boot partition (which is pretty vanilla/stock). I then attempted to backup a single sub-folder of the complete Archives hierarchy to a brand new CD backup set. This seemed to work--I was subsequently able to repeat the same script and it correctly said that there were 0 files to backup.

 

 

 

I am now attempting to backup a larger subset (sub-tree of the complete hierarchy) to CD, where the subset requires more than a single CD. We'll see how that goes.

 

 

 

It also occurred to me that because the upgrade included a new application, the memory allocation (on the "Get Info" panel/dialog) for the application would be set to the default. I seem to recall (but cannot confirm) that I found it necessary to increase the memory allocation w/ version 4. So I have increased it for version 5 too. Perhaps unnecessarily, but I have 512 MB so....

 

 

 

--Greg

Link to comment
Share on other sites

Well... it is working now.

 

 

 

I rebooted and rebuilt the desktop (necessary after the upgrade to 5?), then abandoned the original Archive catalog and script, making brand new ones.

 

 

 

Then I started the backup process, and after each disk (14 total) I stopped the backup, copied (saved) the catalog, recorded the stated completed and remaining numbers, and then started the script again to see if it matched. For the most part it did (within reason).

 

 

 

In the end, I am now able to start the script, it scans, and then properly says nothing needs to be done.

 

 

 

--Greg

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...