Change catalog file location after creating a backup set?

[jhg]

Retrospect 16.6.0.133

Given an existing backup set, is it possible to change the location where the catalog file is written?

I have a Disaster Recovery backup for my C:\ drive that writes its catalog into a directory on D:\ and I'd like to change it to put the catalog on the same disk as the backup set itself.

Can I alter the backup set? I don't see a way to do this from the "Properties" dialog.

[jhg]

OK, so I moved the catalog file to the desired location, then ran the backup script.

It asked me "Where is the Catalog File for " the backup set.  When I navigated to the new location and selected the catalog file it says "File Not Found"

If I select the parent directory of the catalog file instead it says "The name is not valid"

I see other messages in the forum about this problem in the context of attempting a disaster recovery restore... this does not inspire confidence that DR will actually work.

Why does it not accept the new location of the catalog file?

[Lennart_T]

30 minutes ago, jhg said:

OK, so I moved the catalog file to the desired location, then ran the backup script.

It asked me "Where is the Catalog File for " the backup set.  When I navigated to the new location and selected the catalog file it says "File Not Found"

If I select the parent directory of the catalog file instead it says "The name is not valid"

I see other messages in the forum about this problem in the context of attempting a disaster recovery restore... this does not inspire confidence that DR will actually work.

Why does it not accept the new location of the catalog file?

I think (not sure) that you should double-click the catalog file (in Windows Explorer) while the backup is NOT running.

[x509]

10 hours ago, jhg said:

OK, so I moved the catalog file to the desired location, then ran the backup script.

It asked me "Where is the Catalog File for " the backup set.  When I navigated to the new location and selected the catalog file it says "File Not Found"

If I select the parent directory of the catalog file instead it says "The name is not valid"

I see other messages in the forum about this problem in the context of attempting a disaster recovery restore... this does not inspire confidence that DR will actually work.

Why does it not accept the new location of the catalog file?

Possible dumb question.  Have you tried to change the location of the backup set using the Properties of that backup set, of course, while that backup set is not in use.

[jhg]

15 hours ago, x509 said:

Have you tried to change the location of the backup set using the Properties of that backup set, of course, while that backup set is not in use.

The Properties dialog for a backup set does not allow changes to the catalog file location:

[Lennart_T]

7 hours ago, jhg said:

The Properties dialog for a backup set does not allow changes to the catalog file location:

No, not in the "Summary" pane. Try the "Options" pane.

Also try what I wrote in a previous reply.

[DavidHertzberg]

jhg,

What you need to do is Recreate the catalog file on D:\ from its D:\ Member.  The most recent time I did this was last Friday on my "backup server" 2010 Mac Pro (that can have up to 4 internal drives), which normally boots from an internal SSD but where I keep the catalog files on an old internal HDD (in case I have to revert to a previous version of Retrospect Mac).  I was experimenting with creating a Storage Group—a container for multiple Backup Sets that is not relevant to this discussion—and I carelessly let Retrospect Mac 16 default to creating the catalog file for the misnamed "Media Set Groupie" (I thought I should have "Media Set" instead of "Storage Group" as the lead part of the name) on the SSD.  I didn't discuss it in the second substantive paragraph of this post, but to fix my carelessness I did the Retrospect Mac 16 equivalent of what is described on pages 456-458 of the Retrospect Windows 16 User's Guide.

That description was primarily written for a Backup Set with removable-disk Members, but it is also applicable to a Backup Set with HDD Members.  Your Backup Set has only one HDD Member, to which you will almost certainly have to navigate inside the "Retrospect" folder on your D:\ drive in steps 5 and 6.  I recommend you put the new catalog file someplace outside the D:\Retrospect folder, but you probably can get away with putting it inside D:\Retrospect.  When the Recreate is finished and you have tested it with a script edited per page 458, save disk space by deleting the old catalog file on your C:\ drive.

[jhg]

None of this makes any intuitive sense.

I created a backup set on a hard disk, and placed the catalog (from the start) on the same disk.  At the time, the backup set was in E:\Retrospect, and the catalog ("DRImage.rbc") was in e:\catalog.

Now I'm trying to restore a file from that image. The disk is now H: after a reinstall of Windows 10.

When trying to open the backup set it asks "Where is the Catalog File for DRImage".  When I navigate to H:\catalog, no matter what I do it says it cannot find the file.

This seems awfully broken to me.  If I point it to the catalog, it should find the catalog.  The catalog was updated just yesterday, the only thing that has changed is that the drive letter has changed. 

 

[DavidHertzberg]

jhg,

If you want to submit a Support Case for a bug—because "This seems awfully broken to me ... the only thing that has changed is that the drive letter has changed", here's why and how to do it.  Just to reiterate what my linked-to boilerplate post says, Retrospect "Inc." personnel no longer look at these Forums.

[jhg]

OK, there is definitely something very broken in how Retrospect locates the catalog.

I rearranged the drive letters to make the image backup disk E: again, and it has no trouble, just opens the backup set and does not prompt for the catalog location.  This indicates to me that Retrospect is storing the catalog drive and path in its metadata.

If it's not possible to read a catalog from a different location than what is saved in Retrospect's metadata, then it shouldn't be presented as an option.  Clearly that is not what is intended, so Retrospect should be able to update its metadata to read the catalog from a different location.

[jhg]

I have opened a support case.  https://www.retrospect.com/en/support/case?case_id=5000P00000q2rrJQAQ

[DavidHertzberg]

jhg,

In the Retrospect "Inc." Support Case system, ordinary customers cannot read any Support Cases they have not personally submitted. I followed the link in your post, and it merely led to the sign-in screen, with my personal customer e-mail ID and password already filled in—which is what usually happens.  At least post your Support Case number, so other users of the Support Case system can refer to that in their own Support Cases.

Under the "Retrospect 9 or higher for Macintosh" Forum, there still exists a "Retrospect bug reports" sub-forum.  However J.G. Heithcock e-mailed me a couple of years ago saying Retrospect Inc. personnel are no longer routinely reading any of these Forums, excepting Product Suggestions to assess feature demand.  The charitable 🤣 explanation is that posters were not supplying needed supporting information—Retrospect Edition and version and OS version etc.—that the Support Case system forces a submitter to supply.  The uncharitable explanation is that the Support Case system used to slam a submitter in the face with pressure to add on Annual Support and Maintenance, which prior to the StorCentric acquisition obviously  paid most of the Technical Support departmental budget.  (I was assured a couple of years ago in an e-mail from the head of Technical Support that one doesn't have to have ASM to submit a Support Case, which is why my boilerplate posts—which I keep linking to—emphasize that ASM is only required for personalized help in dealing with a bug.)

Such foolishness has IMHO been one of the main reasons the Retrospect application has a decades-long reputation for not having its bugs fixed promptly.  When I started a thread about Retrospect on the Ars Technica Mac forum in 2016, I was immediately hit with a barrage of posts from Ars sages denouncing the application for past bugginess—so I'm not exaggerating.  I'm quite sure Mihir Shah of StorCentric is aware of that reputation; I hope he can change it.

[jhg]

Understood; the support case is number 73057.

I've been a user of Retrospect since one of the earliest versions on a Mac SE30 (backing up to 1.44MB floppies) and generally been satisfied, but I agree that bugs linger for ages before being addressed.  But glacial bug resolution pace seems to be the norm -- see Apple, Microsoft, Quicken, etc.

[x509]

I know that I have had to relocate backup datasets on several occasions.  See this screen grab:

For dataset properties, select the Members tab and then in the Member Properties window, just edit the location.

However, one of the pleasant surprises in V16 (or was it 15) was that Retrospect is now smart enough to locate a backup dataset that is not in the "default" location.  I recently had to work with several years of datasets for compression/grooming.  I organize all my datasets by year.  Each year gets a new HDD (until older years get really groomed/discarded and then consolidated onto one HDD).  So I would place a drive, call it 2017 Backups, in my drive dock, so intead of G:, that dataset would be on drive H:, in my case. And shazam!, Retrospect just located the dataset without any further work on my part.

I'm sorry that i didn't remember all this a week ago, but I've been busy trying to find toilet paper in the stores. 

Here is the drive dock I use:  https://www.amazon.com/gp/product/B07GZHTNLD/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1

It replaced a similar unit from Orico, which stopped working, and Orico didn't respond to my emails.

 

[DavidHertzberg]

Thank you, x509, but you are talking about relocating a Member of a Backup Set—whereas jhg is talking about relocating the Catalog File for a Backup Set.  (Please excuse my using initial-upper-cased names for Retrospect entities, a habit I adopted some years ago from the User's Guides that IMHO encourages clarity at the expense of style.)

I believe that what you call "one of the more pleasant surprises" was introduced in Retrospect Windows 11, where it is briefly mentioned as "Portable Backup Sets/Media Sets" on page 14 of the Retrospect Windows 11 User's Guide.  (One of my often-expressed peeves about the UGs is that, for the last 5 years, certain features mentioned in the "What's New" chapter for one major version were never copied into a later chapter for the next major version—and thus disappeared from non-Retrospect-Inc. knowledge because they weren't considered important enough to appear in a Knowledge Base article.)  It says:

Quote

Retrospect v11 for Windows and Retrospect v13 for Mac now allow customers to move the member folders of disk sets to new locations and let Retrospect know by simply editing the members and picking the new location.

That would be after what we benighted Retrospect Mac users call a Finder move; I don't know what the equivalent Windows term is.  But anyway, the quote says "move the member folders of disk sets" and not Catalog Files—which is what jhg has done.  He wants a feature to make that move be effective.

Pages 113 and 433 of that same UG (I'm sure only the page number has changed in later editions) say the default location of the Catalog File is "..My Documents\Retrospect Catalog Files".  I don't know what ".." in that context means to Windows users, but—by analogy with Retrospect Mac—I suspect it means the letter for the "backup server" boot drive followed by a colon and backslash.  See the first paragraph of this up-thread post for a Mac discussion.

I'm still puzzled as to why jhg wants to keep the Catalog File for his Backup Set on the same HDD as its first Member.  Maybe it's because his Backup Set is for Disaster Recovery, a situation where the "backup server" boot drive would just have been re-initialized—and not yet Restored.  Faced with the same situation, I'd just re-install Retrospect on the boot drive and then Recreate the Backup Set's Catalog File from its Member(s).

[jhg]

After a couple of posts in the bug report, here is a workaround, and my assessment (as a 40-year career developer) of where the bug is.

Retrospect support suggested that I could try to open the moved catalog file by double clicking on it (the catalog file) to launch Retrospect.  Here is my latest response on the bug ticket:

Quote

I tried your suggestion of double-clicking on the catalog file in its new location... and that actually works.

So, clearly the catalog is OK.  The issue (and it IS a bug that needs to be addressed) is that if you try to open the backup set from within Retrospect (Configure/Backup Sets then select a set and click Properties) it

a) Detects that the catalog is not where it expects

b) Prompts for the new catalog location

c) Is unable to correctly handle the new location and gives the "File not found" error message. 

Note that in the error dialog, it says (in my case) "DRImage file not found" instead of "DRImage.rbc file not found". This suggests that the code behind the dialog is looking for a file without the ".rbc" extension, which would of course fail.

I hope this is enough information for your developers to find and fix the bug.

 

[Lennart_T]

On 3/29/2020 at 9:32 PM, Lennart_T said:

I think (not sure) that you should double-click the catalog file (in Windows Explorer) while the backup is NOT running.

 

22 minutes ago, jhg said:

 

Retrospect support suggested that I could try to open the moved catalog file by double clicking on it (the catalog file) to launch Retrospect.  

 

Interesting. I was indeed right.  

[jhg]

You were, and somehow I missed your original post.  Thanks!

This looks like a trivial bug that should be fixed -- at least I hope so.

[Lennart_T]

18 minutes ago, jhg said:

This looks like a trivial bug that should be fixed -- at least I hope so.

Exactly.  

[DavidHertzberg]

jhg,

AFAICT you haven't done a couple of acid tests:

1. With Retrospect opened by clicking on the Disaster Recovery Catalog File in its new location, run a Backup script whose destination is the Backup Set on your Disaster Recovery disk.  Use the No Files Selector if you don't want the script to actually do any backing up.
2. With Retrospect opened the way it normally does—such as a schedule, run the Backup script whose destination is the Backup Set on your Disaster Recovery disk.  Use the No Files Selector if you don't want the script to actually do any backing up.

If either of these test fails to work, do what I suggested in this up-thread post.  (If I've gotten the drive letter for your Disaster Recovery disk wrong by calling it "D:\", please excuse my error.)  However, over the long term, IMHO the bug you've described needs to be fixed.

Edited April 8, 2020 by DavidHertzberg
Add use of No Files Selector to acid tests

[x509]

I stand corrected.

[x509]

On 4/4/2020 at 3:00 PM, DavidHertzberg said:

jhg,

Such foolishness has IMHO been one of the main reasons the Retrospect application has a decades-long reputation for not having its bugs fixed promptly.  When I started a thread about Retrospect on the Ars Technica Mac forum in 2016, I was immediately hit with a barrage of posts from Ars sages denouncing the application for past bugginess—so I'm not exaggerating.  I'm quite sure Mihir Shah of StorCentric is aware of that reputation; I hope he can change it.

Mihir Shah may or may not be aware of that reputation.  If his staffers don't tell him, then how would he find out?  Lots of staffers have learned the hard way not to bring bad news to the chief, unless it directly affects revenue.

And if we all keep on buying the upgrades as loyal customers, then the management is happy.  In any case, it would take a BIG customer, not a mom-and-pop SMB, or an individual user like me, to really get their attention.  Or maybe one of their big resellers.

[DavidHertzberg]

8 hours ago, x509 said:

Mihir Shah may or may not be aware of that reputation.  If his staffers don't tell him, then how would he find out?  Lots of staffers have learned the hard way not to bring bad news to the chief, unless it directly affects revenue.

And if we all keep on buying the upgrades as loyal customers, then the management is happy.  In any case, it would take a BIG customer, not a mom-and-pop SMB, or an individual user like me, to really get their attention.  Or maybe one of their big resellers.

x509,

IMHO Mihir Shah is well aware of Retrospect's reputation for taking a long time to fix bugs.  My evidence is in the Support Case system.  From 2017 it hit any administrator filing a Support Case with a strongly-worded pitch for buying Annual Support and Maintenance.  In fact I felt it necessary to include a fifth paragraph in my boilerplate post on filing a Support Case for a bug, saying an administrator doesn't need to be signed up for ASM to report a bug.  Sometime in the last month or so that ASM pitch has disappeared, which I take as an indication that Mihir Shah realized the pitch—which apparently was added to the Support Case system because Tech Support's departmental budget was largely dependent on ASM—was deterring administrators from reporting bugs and therefore the engineers from fixing them.

[x509]

Sorry for the late reply.  I just spent over a week building up a new Windows 10 machine, and then rebuilding it after a strange situation where pressing the power button didn't even get the fans spinning, let alone doing a boot up operation.

You are probably right, but the "proof" will be when the next release contains very few new features and a long list of bugs fixed.  Bonus points to Mihir if Retrospect publishes a list of bugs that will be fixed on a priority basis.  If he does even just fixes a lot of bugs, that will make the resellers happy, since they are often the ones who get flak for bugs.  A home user like me doesn't have a reseller to complain to.