That’s why you do something called “cloning” at the end of the month, where all your full backup sets are consolidated onto a clone. “Deduped” clone in this case, of course.

For example, Legato NetWorker has the capability to produce clones (and automatically, too). I don’t know if it has the capability to deduplicate, but the groundwork is there. Other backup software likely has some sort of cloning capability too, and if it doesn’t, it should. It’s one’s ‘insurance policy’ and consolidation after all, and that’s not to be taken lightly.

The new backup system: Full backup Saturday night, dedupe backups the rest of the week. This requires us to have both the full backup tape from Saturday night and the nightly dedupe in order to perform a restoration.

The more things change…

Frankly, this deduping sounds like a defensive measure implemented by a tech in a fight with a Dilbert style PHB who has declared that incrementals/differentials are bad since they are not full backups. The PHB doesn’t care that full backups take longer than 24 hours, he just declares that the tech must get everything working. The tech knows that he needs to do full backup on Saturday, then incrementals or differentials during the week. So the tech creates this new name ‘deduping’. The PHB is happy and goes back to his golf game, and the data is safe under the same general procedures that have been working fine for thirty or so years in the computer industry.

File level recovery from block level backups requires an interim recovery of required blocks from media into a cache, with files/data then reconstructed out of that cache. The more heavily fragmented the files originally at backup time, the slower and more painful this process is (or the significantly larger the cache space required to minimise media passes!)

I don’t see how recovery from dedupe tape would be any different from this.

And we do at least bi-weekly tape backups of the current snapshot to store them off-site.

There are other tools (rsnapshot, rdiff-backup) with a similar approach.

This may or may not work in your environment, especially the original data should be rsync-friendly (e.g. a directory tree with only some not so big files changing, i.e. not a database).

morphium