Why Retrospect sees a partition size change as a new drive

[x509]

I submitted a support case based on the fact that Retrospect detects a partition size change as a new drive.  For me, that approach means extra work to recreate all subvolumes and to update all Storage Groups, since I organize my backups around storage groups.  Each storage group has the same drive, e.g, \Photo\Catalog, from multiple systems.  Here is Robin Mayoff's reply.  I still think that Retrospect should give me the option to identify the "new' drive letter as the same as the "old" drive letter.

--------

 

>all I did was resize a partition using Windows Administrative Tools, ON THE SAME DRIVE.

 

When you change the partition size, Retrospect will think this is a different physical disk. Changing the size of a partition is a major change and partition size is an attribute used to identify one disk over another.  The reason why Retrospect is very picky about this type of change is to protect users from dataloss during a possible restore operation.  It would be a very bad situation if Retrospect wrote data to the wrong disk during a restore operation, so Retrospect uses many different criteria to identify disks so that the software can't accidentally overwrite the wrong drive during a potential restore.

 

[Lennart_T]

I don't quite understand how Retrospect (technically) should be able to recognise the "new" disk as the same as the "old" one. I think Retrospect uses UUID to distinguish two volumes from each other and when you change the size of a volume a new UUID is generated.

[x509]

Lennart,

I agree with your point. Retrospect can't automatically recognize the new drive partition as the same the old one.  I was trying to suggest to Retrospect that they give the user a change to configure the new volume to be the same as the old one.

[Lennart_T]

Yes, but what criteria must Retrospect match to offer that choice?

I mean, It's obvious that if all metadata about the volume has changed that it is another volume.

But if (like in your case) the size has changed, the UUID has changed, the creation date has changed and only the drive letter is the same, is it really the same volume? Or is it a completely (and physically) new drive in the same drive bay as the old one. You might even have cloned al files over from the old drive, but it still would be another one.

I say it is better to be safe rather than sorry and never offer that to the user. Yes, unfortunately it is a bit of a nuisance to have to change scripts and subvolumes, so it would be a great feature if it was a consistent and fail safe way to determine if it is a new drive or not.

[x509]

33 minutes ago, Lennart_T said:

Yes, but what criteria must Retrospect match to offer that choice?

I mean, It's obvious that if all metadata about the volume has changed that it is another volume.

But if (like in your case) the size has changed, the UUID has changed, the creation date has changed and only the drive letter is the same, is it really the same volume? Or is it a completely (and physically) new drive in the same drive bay as the old one. You might even have cloned al files over from the old drive, but it still would be another one.

I say it is better to be safe rather than sorry and never offer that to the user. Yes, unfortunately it is a bit of a nuisance to have to change scripts and subvolumes, so it would be a great feature if it was a consistent and fail safe way to determine if it is a new drive or not.

Lennart,

I believe that the only criterion should be to match the volume drive letter and name.  Of course, the user should be warned about the consequences and be given a chance to cancel out.

I guess it's a tradeoff. And there are bigger issues that I would want Retrospect to address first, notably the inability to recover a Windows boot volume.

[DavidHertzberg]

x509,

To clarify, this thread is really just a continuation of this preceding thread.  You seem to have a fondness for forking off new threads about one same basic problem.    For example, this thread and this thread and this thread are about your previous stages solving this same basic problem.  IMHO it makes it difficult for other administrators to find solutions.  Bulletin: signed-in Forums users see threads that are new or newly-added-to as bolded!

This thread also illuminates a problem with Storage Groups, which is that—when the bottom of page 53 of the Retrospect Windows 17 User's Guide says "Under the hood, a Storage Group is a container for per-volume backup sets"—that means the "backup server"'s definition of a volume (on a particular source machine).  This is magnified by use of subvolumes, so you had to "recreate all subvolumes and to update all Storage Groups" per your OP.  As you mentioned in the next-to-last paragraph of this post in a preceding related thread, following the Tools>Repair Catalog procedure on UG pages 380–381 for each per-volume Backup Set found the appropriate Member data on the "new" drive G "volume"—since no data had actually been deleted when you resized the partition.  (You're fortunate to be using Retrospect Windows; Retrospect Mac—with its as-yet-incomplete Storage Group GUI—doesn't allow access to the component Media Sets—the Retrospect Mac term—of a Storage Group in order to do the equivalent of pages 380-381.  However maybe the same procedure actually presents the dialog on the bottom of UG page 52 for each Media Set component in succession.  Not surprisingly, I caution Retrospect Mac administrators not to use Storage Groups—which I don't—unless they absolutely have to! )

Edited June 1, 2021 by DavidHertzberg
First paragraph: Add sentence about bolded threads for signed-in Forums users at end. Second paragraph: Move parenthesized sentences about Retrospect Mac Storage Groups to end, replace sentence about drive assignments with one about subvolumes.