Jump to content
x509

Retrospect no longer recognizes the backup drive with all my backup sessions

Recommended Posts

As part of the preparation for Disaster Recovery, I  had to resize the 2020 Backup partition on my G: drive, to make space for my DATA partition.  (Why, it's not worth it to explain, but I won't do that ever again.)  The result is that

1. My Disaster Recovery process failed because Retrospect could not find the specific member of the backup set.

2. All my backup scripts are clearly failing because they seemed to be tied to the original 2020 Backup partition, not the resized partition.  Here is part of the Volumes display.  Note that the first (and original) 2020 Backup (G:) is greyed out.  Is there any way to get Retrospect to recognize that original partition?  My ability to do that Disaster Recovery depends on this.  The contents themselves have not changed.

image.png.59723f0517cc3933b0f0f45f53e7b9a6.png

I seem to recall that there is a way to solve this problem, and I even searched my Retrospect Log doc file, which goes back years, but I can't find it.

 

Share this post


Link to post
Share on other sites

x509,

I'm a Mac user as you know, so my ability to help is limited.  However it sounds as if your problem is really a Windows problem, since your original G: partition is greyed-out.  A recent poster had a somewhat similar problem, but it concerned Open File Backup and a Windows 10 System Reserved Partition.

That poster's desired partition was missing in Windows Explorer, but the original "2020 Backup" partition you want to access is greyed-out in the Retrospect Volumes display (???) screenshot in your OP.  Assuming it would also be greyed-out in the Windows Explorer display, you might want to try this free AOMEI utility or this $11 PartedMagic one to temporarily get rid of your new "2020 BACKUP" partition—and temporarily shrink your DATA partition again.  I believe either of those utilities can get rid of the new partition on your G: drive and expand the old one.  It sounds to me as if you should have used one of these utilities to shrink your original "2020 Backup" partition to make room for your DATA partition, but that's Monday morning quarterbacking.  It also sounds to me as if you were counting on the NTFS filesystem's case-sensitivity to also be a feature of Retrospect, but Retrospect may be case-insensitive since the old Apple HFS+ filesystem is case-insensitive (the new Apple APFS filesystem is case-sensitive).

Assuming you can thus get Retrospect to recognize your original partition as a Volume and find the specific Member of the Backup Set, you should be able to execute your Disaster Recovery process once more.  As far as your Backup scripts are concerned, that depends on whether you end up keeping the original "2020 Backup" partition or replacing it with a new partition having a different name—and I don't mean just replacing lower-case letters with upper-case letters.  If it's replacing it with a new partition, you can copy the Members from the old partition to the new partition and then do the operation in the third paragraph of this 2012 post to change the new Catalog File.  In that case you'll have to change the destination names in all your Backup Scripts; as we used to say back in the 1950s, "that's the way the cookie crumbles".

Share this post


Link to post
Share on other sites

I think having duplicate names may be the issue, and it's ambivalent from the Retrospect POV.  I'd rename the backup drive on the Retrospect server to "Backup2" in Windows.  Then you'll need to rebuild the catalog for all of the backup sets.  I think I'd do one as a test, since the rebuild will take a long time.

This is just an opinion.  The closest I've come to this is making a backup on a Windows 7 system where Drive C had one name, then installing Windows 10 on the same system overwriting everything.  W10 uses a different drive naming convention, so I had to adjust a lot of scripts.

Share this post


Link to post
Share on other sites
22 hours ago, DavidHertzberg said:

x509,

I'm a Mac user as you know, so my ability to help is limited.  However it sounds as if your problem is really a Windows problem, since your original G: partition is greyed-out.  A recent poster had a somewhat similar problem, but it concerned Open File Backup and a Windows 10 System Reserved Partition.

That poster's desired partition was missing in Windows Explorer, but the original "2020 Backup" partition you want to access is greyed-out in the Retrospect Volumes display (???) screenshot in your OP.  Assuming it would also be greyed-out in the Windows Explorer display, you might want to try this free AOMEI utility or this $11 PartedMagic one to temporarily get rid of your new "2020 BACKUP" partition—and temporarily shrink your DATA partition again.  I believe either of those utilities can get rid of the new partition on your G: drive and expand the old one.  It sounds to me as if you should have used one of these utilities to shrink your original "2020 Backup" partition to make room for your DATA partition, but that's Monday morning quarterbacking.  It also sounds to me as if you were counting on the NTFS filesystem's case-sensitivity to also be a feature of Retrospect, but Retrospect may be case-insensitive since the old Apple HFS+ filesystem is case-insensitive (the new Apple APFS filesystem is case-sensitive).

Assuming you can thus get Retrospect to recognize your original partition as a Volume and find the specific Member of the Backup Set, you should be able to execute your Disaster Recovery process once more.  As far as your Backup scripts are concerned, that depends on whether you end up keeping the original "2020 Backup" partition or replacing it with a new partition having a different name—and I don't mean just replacing lower-case letters with upper-case letters.  If it's replacing it with a new partition, you can copy the Members from the old partition to the new partition and then do the operation in the third paragraph of this 2012 post to change the new Catalog File.  In that case you'll have to change the destination names in all your Backup Scripts; as we used to say back in the 1950s, "that's the way the cookie crumbles".

David,

The operative phrase in y our message is the first sentence of your last paragraph.

I already use a free version of MiniTool Partition Wizard, which is pretty much the same as the AOMEI utility, +/- one or two obscure features.  I have been using it for years now, and it's the favorite of the cognoscenti over at TenForums (www.tenforums.com), which is my go to web forum for Windows and related topics.  The issue is that any time that Partition Wizard touches a partition in any way, Retrospect barfs and no longer recognizes it, even if the physical drive is the same and the Windows drive letter is the the same.  That's why I had an "old" and a "new partition C (my programs and Windows), D (my data), and G (my Retrospect dataset backups).

Partition names are unchanged, so case isn't an issue.  From what I can tell, from Lightroom forums, case sensitivity is an issue on MacOS systems, but not Windows systems.  Not surprising, considering the MacOS roots in UNIX.

After reading your post, and puzzling around for a bit, I realized that I needed to recreate my catalog sets on the "new" drive G.  That worked, and I was able to run Disaster Recovery.  it still failed on me, which I will discuss in a new thread.

And I had to redo all the individual drive assignments in my Storage Groups.  My scripts work against Storage Groups, not individual drives on individual systems.  Much more convenient, except when it's not.

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

×