A policy based upon a deduplication storage folder with client side de-duplication splits the task into two halves for performance reasons. Whilst backing up a 3TB server yesterday, the server went offline due to an intermittent fault on one of the hard disks (which is why we're backing it up :-)) but the verify task started and is still running.
Do I infer correctly from this that the verify stage is checking the validity of the data in the de-duplication storage folder itself and isn't doing a byte level compare against the source?
Allied to this, if one does a full backup of a large server with de-duplication that has just been backed up, the backup is far quicker than a normal backup-to-disk folder as the majority of the data already exists in the de-duplication folder and doesn't get sent across the network and written to backup store.
But what about the verify step of a full backup? Does it always read and verify EVERY file in the backup set whether or not it was actually written during that backup or does it only verify the files that had to be refreshed in the backup due to a change?
Final question for now. With a full backup with client side deduplication, is EVERY file read from disk by the client, split into 64k blocks and checked if they already exist in the deduplication storage folder? Or is there some clever kind of check that the client can carry out without reading the entire file to see if it's changed?
Cheers, Rob.
