Jump to content
AWL

Upgrade source hard drive

Recommended Posts

I'm sure people have run into this situation before, but I can't find it easily by Search in the forums:

I just upgraded a source external HD with an external SSD and cloned the files over, and I set aside the old drive.  Retrospect 16 recognizes the clone as a new drive.  When I replace the old source in a backup script with the new drive, will the backup recognize that the files are the same as from the old drive?  Or will the backup start copying the files over to the media set as if they were from an entirely new drive?  If the latter, what do I do to make the backup of the old drive be inherited by the new drive?

Share this post


Link to post
Share on other sites

AWL,

You asked what is essentially the same question on 25 August 2016 in your only previous post in these Forums, and got a slightly-less-brief version of the same answer from Lennart_T.  I'll assume that your memory is not failing you,😁 but that you are instead a victim of long-time inadequate documentation of the deduplication feature in the Retrospect Mac 17 User's Guide  (but it's also a fault in older/Windows versions).  Page 31 says:

Quote

Because Retrospect only needs to add one instance of each unique file to the backup, it saves space on the backup media that would otherwise be used up storing duplicate copies of files. This space-saving technique is known as file-level deduplication or single-instance storage.

The problem with that paragraph is that it doesn't explain what a "unique file" is.  Although this 2012 Lennart_T post defines a "unique file" better for Windows (despite being in a Mac Forum thread), the general baseline definition turns out to be buried in this Knowledge Base article—which says: 

Quote

.... ...Retrospect performs file level backup and deduplication based on file name, date and size. If a file at the backup source matches one already in the backup [Mac Media] set, Retrospect skips the file without reading it. This efficiently deduplicates identical files across backup sources, reducing disk IO operations at the backup sources, network traffic as well as server storage IO operations and space consumption. ....

Checkmarking options described on pages 99–102 of the UG can expand that KB baseline definition—no doubt an excuse for page 31's omitting it.  Match only file in same location/path would do what you make it clear in your OP you don't want done, resulting in the cloned files being copied over again to the Media Set.  Use attribution modification date when matching a Macintosh source, Use status modifiied date when matching a Linux source, and Back up file security from ... a Windows source expand the definition of "unique file" in ways most administrators probably don't want.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×