Duplicate-Copy has stopped working in 15.6

[Fredspon]

I have been backing up my backup disks to another disk for some time but since I have moved from V12 to V15 it has stopped working. After many trials I think I have discovered the reason why and I'd like any thoughts on this as it is quite bizarre. It would appear that the duplicate program won't now copy from the original backup disk anything inside a folder called Retrospect!!

I do a straight copy of the whole disk and all I get is the data that is not inside the retrospect folder although I do get an empty retrospect folder. I have ruled out any space issues.

Thanks in advance.

 

[DavidHertzberg]

Fredspon,

As this post in a 2012 thread shows (click the blue-underlined link to be taken to it, then click the Back arrow in your web browser to be taken back here), "it's not a bug, it's a feature!"   There's a zero-byte file named "Backup Media" in the "Retrospect" folder on the "backup disks" Member(s) of your Backup Set that's designed to activate the feature.

The reason Dantz Development Corp. (the predecessor of Retrospect Inc.) put in this feature years ago is to prevent administrators from "holding it wrong" (that's a Macintosh joke, referring to a Steve Jobs on-stage remark about a previous version of the iPhone), as this post (responding to the one linked to in the preceding paragraph of this post) says.

Quote

The correct method for what you are trying to achieve is to create a second backup set on the offsite media, then use "Transfer" (not "Duplicate") operations to copy files to it from the onsite backup set.

If you've scheduled a Transfer operation (not "program"; you'd better be more precise about terminology if you want us to help you ) after each Backup operation, then use Transfer Snapshots—here's the Tutorial that you should watch after the one linked-to in the next sentence.  If not, use Transfer Backup Sets—here's the Tutorial that you should watch before the one linked-to in the preceding sentence.  For the scripted operations, see pages 206-217 of the Retrospect Windows 15 User's Guide; for the Immediate operations, see pages 141-152.

Edited May 16, 2019 by DavidHertzberg
Added links to Tutorials

[Fredspon]

Thanks very much for your help.

After exhaustive testing I finally went for the Transfer Backup Sets option with the following changes in Options:-

Verification Off (to speed things up).
Executions > Transfers > Copy Snapshot ticked but everything else un-ticked (Especially the Recycle Source Backup as I want the original backups to remain intact as they are recycled by their own scripts after 3 months).
Executions > Matching > Match source catalog file un-ticked.

With Scheduled Executions set as recycle.

 

Having now run this a few times “live” I am happy that it does exactly what I want it to do.

Once again, thanks for your help.

 

I trust this terminology is within your preciseness?

[DavidHertzberg]

Fredspon,

After rereading this, I question whether you should set your Scheduled Executions as Recycle.  You say "I want the original backups to remain intact as they are recycled by their own scripts after 3 months".  However page 226 of the Retrospect Windows 15 User's Guide says:

Quote

Recycle clears the Catalog contents (if any) of a Backup Set so it appears no files are backed up. Then it looks for the first media member of the Backup Set and erases it if it is available.

If I understand what you probably want to do, it is to Recycle your primary Backup Set disk Members after 3 months to prevent their running out of space, but to keep accumulating forever the backups on your secondary disks in case you need those backups for disaster recovery.  This is the user-demanded feature that the EMC predecessor of Retrospect Inc. built with Transfer in the early 2000s; many enterprise users wanted—and still want—their secondary Backup Set Members to be on tape (beats chest, shouts "Real enterprises use tape!" ) because buying an additional high-capacity blank tape every so often is cheaper (once they've shelled out upwards of US$1500 for a tape drive) than buying an additional hard disk drive every so often.

If this is what you want to do, then—besides changing Scheduled Executions to Normal—you should tick Match Source Volumes to Catalog File and tick Don’t Add Duplicates to Backup Set and tick Transfer Any Needed Intermediate Database Snapshots (I've initially-upper-cased some more words in these option names to make the names easier to read).  Although those options will slightly increase the running time for your Transfer Backup Set scripts, it will allow you to Transfer incremental backups while preventing any multiple transfer of the same backup.  You won't have any unpleasant surprises after 3 months, and I doubt you tested for that long.

I should point out that I am a lowly home user of Retrospect Macintosh, who does a Recycle backup every Saturday onto a brought-back-from-bank-safety-deposit-box portable HDD and does incremental backups onto it Sundays through Fridays.  So an administrator with real enterprise experience should correct me if I'm wrong.   However I just found my applicable three-year-old post, and the options in it are the same ones I said to tick in my third  paragraph (second below the quote) of this post.  I'm not providing a link, because the thread it's in is about doing Cloud backups using Retrospect Mac and involves initial "seeding".  However three years ago I changed the options ticked in the post after the head of Retrospect Tech Support posted a Tutorial, to which I also won't link because I see the Transfer options in Retrospect Windows have changed since the Tutorial was posted.

P.S.: If what I suggested in the paragraph below the quote is not what you want to do, at least have your Transfer Backups Sets script(s) be scheduled to do a Recycle at least one run after your Backup script(s) are scheduled to do a Recycle.  That way you don't run into the following  bad situation, which Murphy's Law says will happen:

1. One or more data folders on your source drive go bad.
2. Your Backup script runs with a scheduled Recycle immediately after that happens, so your primary Backup Set no longer contains data from the now-bad folder(s) .
3. You don't notice the error message(s) from your Backup script, so you allow your Transfer Backups Sets script to run with a scheduled Recycle.
4. Result is that you no longer have that data on either your source drive or your primary Backup disk Member or your secondary Transfer Backups Sets disk Member.  Back in the early 2000s your Transfer Backup Sets script(s) would have had tape Members as their destinations, so (provided you hadn't re-used your existing tapes for the Transfer Backups Sets run that did the Recycle) you could have done a Recreate of your secondary Backup Set's Catalog file from the tape Members and done a Restore using that secondary Backup Set; however you're probably not using tape.

Edited June 3, 2019 by DavidHertzberg
Initially-upper-cased some more words in option names in third paragraph (second below the quote); added 3 more sentences of reassurance to fourth paragraph (third below the quote); P.S. cautioning about avoiding bad situation