Retrospect backup sets

[OZSJ]

I am backing up my Retrospect backup sets to an online storage system and have some questions relating to how Retrospect creates and modifies these sets.

 

1. If I schedule a daily backup of a folder that is aprox 2GB, the first will write the full 2GB into 4 Disk Backups Sets (from what I can see Retrospect limits the size of these to 614MB). Now if I modify some files before the next backup is run, will these original backup sets need to be accessed or does Retrospect keep a catalog of files that have already been backed up.

I ask because when I ran my second backup (that only had a couple files change) Retrospect wanted to download the entire previous disk backup set. Is this expected behavior?

 

2. I would have thought that the only reason retrospect needs to access a previous Disk Backup Set is if the grooming option was enabled.

 

I appreciate your hep with this matter.

[nekr0phage]

Quote:

---

 

I am backing up my Retrospect backup sets to an online storage system

 

 

---

 

Could you elaborate?

 

Quote:

---

 

(from what I can see Retrospect limits the size of these to 614MB)

 

 

---

 

Correct.

 

Quote:

---

 

does Retrospect keep a catalog of files that have already been backed up

 

 

---

 

Yes it does, it is called (ready?) the catalog file. The default location is C:/Docs & Settings/(User)/My Documents/Retrospect Catalog Files, though you can point it to anywhere.

 

Were you using verification when you backed up? It could be that the destination has nothing to do with your experience. You could test that out by running a test backup to a local volume and then running an incremental backup.

[OZSJ]

Thank you.

 

I am using the Amazon S3 storage service.

 

I was in fact using normal backup with Thorough verification. I have now selected the "media verification" option. It looks like this is what I am after but I still have two questions.

 

1. I want to make sure that retrospect never has a need to read/write again to a previous disk backup set. Obviously this would be extremely prohibitive over the internet. Can you confirm that using media verification will never result in the need for this to occur.

 

2. I was under the impression that all the "normal backups" in the backup options were incremental after the first backup. If this is not the case then where is this incremental option?

 

Steve

[nekr0phage]

Steve,

 

1) Thorough verification performs a direct compare of source file and backup file, media verifies based on the MD5 sum generated for backed up files, however, I can't recall exactly how the matching works. It is designed so that you do not need to re-read the source volume, but I'm not sure if it simply verifies info in just the catalog, or catalog and backup set. Perhaps someone else can confirm this. Please note: there were a few (uncommon) issues with media verification with early versions of 7.5. So you'll want to make sure you're up-to-date.

 

2) Technically all Normal backups are incremental, it's just that the first one has nothing to compare against. If unmodified data is being backed up repeatedly there may be an issue with the verification of those files. I know there previously existed an issue where a file's session contents would specify a 'miscompare' flag for some files, but nothing would be reported in the operations log. This was resolved with one of the updates, so again, you should make sure you have the latest build.

 

Again, a good quick test to determine whether the problem occurs only when backing up to S3 would be to simply create a disk backup set on the local volume and run a few test backups to see if the same thing happens.

[OZSJ]

Thanks for the detailed reply Foster.

 

I have created a test schedule for the last few days. To my disappointment even with the lower "media verification" today Retrospect downloaded the first full backup before it would process the two latest files added. I must admit I am surprised by this behavior. Obviously that only leaves "no verification" or "duplicate" which has no encryption options.

 

This is a shame because I use Retrospect with many clients for backups to external drives and would prefer not to have a different program for net backups.

[nekr0phage]

That is indeed a shame. A potential workaround (though it would be more troublesome) would be to backup to a local backup set, then manually copy completed .rdb files to the S3 server via whatever utility necessary. That would at least allow you to continue using encryption for your backups.

[OZSJ]

Yeah, I had just thought of that too. Although once the backed up to the local backup set with encryption I can run a separate "duplicate" backup script to S3.

 

It should work because with Media Verification and no grooming it appears that Retrospect never needs to write again to the initial "full" disk backup set. As a result the duplicate will only need to upload incremental changes.

 

Fantastic! Thanks for your help Foster.

 

Steve