Can QR backup and restore a Time Machine Backups.backupdb file?

I have a few older Time Machine Backups.backupdb files on some HDDs attached to my "stationary" Mac. I'd like to backup these drives containing the Backups.backupdb files to my NAS, and I'm wondering whether QR can backup the Time Machine dbs and then properly restore the dbs to a future attached HDD. Based on what I've read so far, it appears that this should be no problem because QR seems to create a single monolithic file with its own internal structure, but I just wanted to verify.

And I have one other question - In my trial observations of QR in action, during the first Capture I'm seeing large amounts of data going back and forth between my Mac and my NAS. What's happening when the data goes from the NAS to the Mac? Verification?

maxbraketorque wrote:I have a few older Time Machine Backups.backupdb files on some HDDs attached to my "stationary" Mac. I'd like to backup these drives containing the Backups.backupdb files to my NAS, and I'm wondering whether QR can backup the Time Machine dbs and then properly restore the dbs to a future attached HDD. Based on what I've read so far, it appears that this should be no problem because QR seems to create a single monolithic file with its own internal structure, but I just wanted to verify.

I'm honestly not sure. I have no doubts QRecall can capture the Backups.backupdb package, but I'm scratching my head as to whether it would properly restore it. I say this because Apple added a special "hard-linked directory" feature to the HFS filesystem just for Time Machine. And while QRecall will properly capture and restore hard-linked files, I suspect hard-linked directories would just look like two separate directories. And the only software that seems to use this feature is Time Machine, so support was never added.

I suspect you'd have better luck using asr or creating HFS+ disk images of the Time Machine backup volume. That, in theory, should persevere and restore the hard linked directories correctly.

And I have one other question - In my trial observations of QR in action, during the first Capture I'm seeing large amounts of data going back and forth between my Mac and my NAS. What's happening when the data goes from the NAS to the Mac? Verification?

QRecall doesn't just copy files. It chops them into small chunks and adds those chunks to a database. At a minimum, each block of new data has to be checked against the corpus of data already captured to make sure it's not a duplicate. That requires at least one, and often several, queries. In subsequent captures, it has to read the meta data of the previously captured file to determine what has changed. So there's a lot of back and forth data happening.

James Bucanek wrote:

maxbraketorque wrote:I have a few older Time Machine Backups.backupdb files on some HDDs attached to my "stationary" Mac. I'd like to backup these drives containing the Backups.backupdb files to my NAS, and I'm wondering whether QR can backup the Time Machine dbs and then properly restore the dbs to a future attached HDD. Based on what I've read so far, it appears that this should be no problem because QR seems to create a single monolithic file with its own internal structure, but I just wanted to verify.

I'm honestly not sure. I have no doubts QRecall can capture the Backups.backupdb package, but I'm scratching my head as to whether it would properly restore it. I say this because Apple added a special "hard-linked directory" feature to the HFS filesystem just for Time Machine. And while QRecall will properly capture and restore hard-linked files, I suspect hard-linked directories would just look like two separate directories. And the only software that seems to use this feature is Time Machine, so support was never added.

I suspect you'd have better luck using asr or creating HFS+ disk images of the Time Machine backup volume. That, in theory, should persevere and restore the hard linked directories correctly.

And I have one other question - In my trial observations of QR in action, during the first Capture I'm seeing large amounts of data going back and forth between my Mac and my NAS. What's happening when the data goes from the NAS to the Mac? Verification?

QRecall doesn't just copy files. It chops them into small chunks and adds those chunks to a database. At a minimum, each block of new data has to be checked against the corpus of data already captured to make sure it's not a duplicate. That requires at least one, and often several, queries. In subsequent captures, it has to read the meta data of the previously captured file to determine what has changed. So there's a lot of back and forth data happening.

Thanks for the quick responses. I'm a bit fascinated that apparently no one has asked the question before about correctly copying and restoring a TM backup. If you think it might work, I could try restoring the TM backup to another drive and then attempt to use TM to restore some files. If I move the TM backups to an HFS+ dmg, will QR correctly backup and restore the dmg file?

QRecall can most certainly capture and restore a DMG file?it's just a file.

People tend to use TM as an adjunct to QRecall. This is honestly the first time anyone has asked about getting meta and asking one backup program to backup the backup of another backup program.

James Bucanek wrote:QRecall can most certainly capture and restore a DMG file?it's just a file.

People tend to use TM as an adjunct to QRecall. This is honestly the first time anyone has asked about getting meta and asking one backup program to backup the backup of another backup program.

It took forever for QR to backup the Time Machine backup. QR spent a bunch of time dealing with the 500,000+ files. If I dump the backup into a HFS+ dmg, then QR only has to deal with a single monolithic file. I think that will go much faster, and the file will never change.

On a tangential note, I'm wondering whether its easier for QR to repair damage done to a few small files among a huge batch of files or whether its easier to repair a small amount of damage to a single large file. No issues right now. Just thinking about potential future liabilities.

Thanks much.

maxbraketorque wrote:On a tangential note, I'm wondering whether its easier for QR to repair damage done to a few small files among a huge batch of files or whether its easier to repair a small amount of damage to a single large file. No issues right now. Just thinking about potential future liabilities.

I love it when people are thinking about potential failure liabilities

I assume you're referring to archive data redundancy. That's implemented at the block level of the main data file, so the granularity of the archive content doesn't make it "easier" or "harder" to repair data. If any block in the file is damaged, there's a limited amount of correct data available to reconstruct it.

However, the granularity of the archive does matter if the data can't be recovered. A single damaged block in a massive 10GB DMG file means that entire DMG file is probably a lost cause. While a single damaged block in a document file means you've lost one document out of millions.

That's the difference.

ok, sounds like as long as QR can correctly restore a TM backup, its better to backup the .backupdb file directly rather than dump the .backupdb into an HFS+ dmg. If you're not sure whether QR can correctly restore the .backupdb, then perhaps I'll restore the TM backup to a spare HDD and extract the files that I need.

Note that the only thing I'm really concerned about is hard-linked directories being treated as separate directories in the QRecall archive that, when restored, will take up a lot more space.

As a fall-back, you should be able to dig into the TM package and recall whatever specific items you want directly in QRecall.