2

My MacBook Pro typically backups to my iMac Time Machine server. I went on a year long trip, during which time I switched my MBP to instead back up to my router (which acts as a NAS and runs a Time Machine server of its own, which writes to a sparsebundle). Now that I'm back from my trip, I would like to resume backing up my MBP to my iMac.

I would like to "merge in" the backups from my NAS's sparsebundle, so that my iMac has the full history. Is this possible?

Original Time Machine destination: A sparsebundle hosted by my iMac

$tree -L 1 /Volumes/old_backup_sparse_bundle/Backups.backupdb/Alex's\ MacBook\ Pro
    /Volumes/old_backup_sparse_bundle/Backups.backupdb/Alex's\ MacBook\ Pro
    ├── 2017-12-29-033257
    ├── 2018-01-06-141057
    ├── 2018-01-13-041417
    ⋮
    ├── 2018-03-03-094036
    ├── 2018-03-07-233939
    ├── 2018-03-08-001351
    └── Latest -> 2018-03-08-001351

Temporary Time Machine destination: A sparsebundle hosted by my router

$ tree -L 1 /Volumes/newer_backup_sparse_bundle/Backups.backupdb/Alex's\ MacBook\ Pro
    /Volumes/newer_backup_sparse_bundle/Backups.backupdb/Alex's\ MacBook\ Pro
    ├── 2018-10-14-091702
    ├── 2018-10-21-100253
    ├── 2018-11-01-202140
    ⋮
    ├── 2019-03-03-192937
    ├── 2019-03-04-142255
    ├── 2019-03-04-153448
    └── Latest -> 2019-03-04-153448

Desired outcome: My iMac's sparebundle is backfilled with the router sparsebundle's snapshots:

$tree -L 1 /Volumes/newer_backup_sparse_bundle/Backups.backupdb/Alex's\ MacBook\ Pro
    /Volumes/newer_backup_sparse_bundle/Backups.backupdb/Alex's\ MacBook\ Pro
    ├── 2017-12-29-033257               ┐
    ├── 2018-01-06-141057               │
    ├── 2018-01-13-041417               │
    ⋮                                   │ Already present in this sparsebundle
    ├── 2018-03-03-094036               │
    ├── 2018-03-07-233939               │
    ├── 2018-03-08-001351               ┘
    ├── 2018-10-14-091702               ┐
    ├── 2018-10-21-100253               │
    ├── 2018-11-01-202140               │
    ⋮                                   │ "Merged in" from the router's sparsebundle sparsebundle
    ├── 2019-03-03-192937               │
    ├── 2019-03-04-142255               │
    ├── 2019-03-04-153448               ┘
    └── Latest -> 2019-03-04-153448
Improve this question

2 Answers 2

Reset to default
1

This is a really bad idea. How many files exist in one snapshot? Since you have hard links to contend with and protective permissions that prohibit most write operations, I would presume most attempts to construct a working hybrid will fail.

The failure modes likely are:

  • insufficient iops to get the job done in months to longer timeframe.
  • insufficient sophistication handling the unpublished checksum handling of when a backup has been tampered with or just failed to be successful.

I would love for someone to prove me wrong, but please make a backup copy of your backups if your main goal is actually preserving their viability. It’s likely you will be able to recover data from any tampered backup, but less likely you’ll be able to continue using a merged backup to make new backups. If that happens you now have another set and are further forked.

Improve this answer
2
  • I'm sorry, but you are criticizing this question based on your judgment that the idea is completely unfeasible. It's not unfeasible and in fact it is clearly highly desirable. There are several questions like this in Ask Different and many others all over the web; I myself have at least 6 TM backups I'd love to merge. The only thing I agree with is that we must back up the merge target before merging.
    – Andrew Wolfe
    Aug 13, 2019 at 15:16
  • Very fair points @AndrewWolfe - I’ve seen people ruin backups trying to merge them so many times. I look forward to learning when and how this can be safely done. My marginal time is more expensive than a pristine dive, but I would need presume anyone else has the same time value of money or access to storage. This is an opinionated answer, and I hope to see other opinionated answers. Votes will show over time which are most resonant or useful. Sparse bundles are an order of magnitude more fragile in my experience than HDD time machine making a sparse merge high risk.
    – bmike ♦
    Aug 13, 2019 at 17:51
0

There is no 'officially supported' way: by which I mean that Apple has provided no methods and no documentation for doing so.

Similar questions have been asked here many times, and only one of them has provided any possible solution, which is to copy one disk onto a third empty drive using SuperDuper!, and then copy the 2nd TM backup onto the third drive using option in SuperDuper! to copy only the files that are different, without erasing.

Note that this method is probably not supported by SuperDuper! either, and the integrity of your merged backup will be unknown.

You may also need to 'inherit' the new merged backup using tmutil inheritbackup /path/to/backup to get the Mac to recognise the backup as its own.

It is much safer just to keep the two backups separate (or continue backing up to both), and then browse through the relevant one when you need to restore something.

Improve this answer
3
  • The steps you outline work, but they don't let you merge backups. They just let you pick one up and carry it forward. You don't even need a clone, btw. A simple file-system-level file copy works
    – Alexander
    Aug 13, 2019 at 16:47
  • @Alexander Why doesn't it merge? Copying one drive and then copying another, leaving the original files in place sounds like a merge. I'm not advocating anyway, I think it's asking for trouble. I doubt a 'simple' file copy would work either.
    – benwiggy
    Aug 13, 2019 at 16:51
  • "then copy the 2nd TM backup" Ah I missed this. I don't remember for sure now, but I'm almost certain I tried this. The extensive use of hard-links makes there be a "discontinuity" between the old set of the files and the new ones
    – Alexander
    Aug 14, 2019 at 3:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .