Verifying Time Machine backups

21

12

I'm preparing my system for a Snow Leopard upgrade, and I prepare for the worst case scenario: full reinstall and restore.

I would like to verify that my Time Machine backups are valid, and will restore correctly. My Time Machine backups go to a Linux server running Netatalk, and the backups complete successfully.

How do I do a test restore to an alternative location, or otherwise verify my data without overwriting any existing files? Do I need to save anything in particular externally to make sure I can access the backups if I have to reinstall from scratch?

jtimberman

Posted 2009-09-27T21:22:28.107

Reputation: 20 109

Answers

14

Time Machine does not have any built-in mechanism to verify a set of backups as being valid. That's one issue with Time Machine, being consumer orientated instead of enterprise...

Performing a Disk Repair in Disk Utility doesn't validate the Time Machine backup data, but will verify the structure and integrity of the backup disk. (Of course, Disk Warrior verifies / repairs in a complementary manner).

The only way that I see that you could verify the data in the backup is to do a full restore.

Please note, you can open the Console logs, and filter against BACKUPD to see what happens during a backup, and see if any error conditions occurred.

Edit:

Time Machine does include an option, if you hold down the option key and click on the Time Machine menu bar add-on, to "Verify backups".

This does not verify the contents of the backup. In other words, that backed up file abcd.txt is the same as abcd.txt, instead this verifies that the Disk image the time machine data is not damaged.

Take a look at http://support.apple.com/kb/HT4076

Benjamin Schollnick

Posted 2009-09-27T21:22:28.107

Reputation: 4 313

1My understanding is that TM uses a directory and file structure that essentially mirrors the actual one. Doesn't this mean we can just use diff to verify the backup, assuming a relatively quiet file system? – kec – 2014-09-16T12:56:06.117

1Try SuperDuper! — with it you can be sure that your disk is copied – tig – 2010-07-10T09:47:37.357

1This is either wrong or out of date. The command line interface for time machine includes a "verifychecksums" command. It's not clear if this will be run occasionally as part of the regular backup process, but it seems logical that it would. – Abhi Beckert – 2017-01-25T02:30:01.953

2Actually if you click Time machine icon in menu bar and then press 'Option' you get a Verify Backups option. – William Macdonald – 2011-02-04T07:15:24.747

The Time Machine option to verify backups, does not verify the backed up data, it verifies the disk image that contains the backup. This is a common misconception, and Apple should relabel the option. – Benjamin Schollnick – 2011-02-06T16:23:55.537

Not really what I'm looking for, but after more research this accurately describes the situation. Consumer-grade backup solutions have always sucked in this regard. I'll probably look into another solution for the long term. – jtimberman – 2009-10-18T17:55:41.113

I wouldn't advise restoring back on the original medium to test. What if there is some corruption in the backup, and it is restored as is? I am not sure if Time Machine protects us from such a scenario with some checksums, but may be it is safer to restore on an external drive and diff? – haridsv – 2012-11-30T16:39:06.313

12

In the end, a Time Machine backup is a collection of folders for each backup date. Each of those folders holds all files that existed on that date. So, you can compare the names and contents of all those files with those on your Mac.

Of course, many files will change by simply using your Mac. So the results take some common sense to interpret. The best option is to close all running applications, run Time Machine, and then compare right away.

After you have connected your backup disk, use the following in Terminal to find the differences. For the cd command below you might want to use Tab command line completion rather than just pasting the first line:

cd /Volumes/Backup*/Backups.backupdb/*/Latest/*/
echo "Current folder on backup disk: $(pwd -P)"
sudo diff -qr . / 2>&1 | tee $HOME/timemachine-diff.log

This will compare the current folder (being the latest backup) with the root of your Mac. It shows the results on the screen, but also captures these in the file timemachine-diff.log in your home folder.

The above will run a VERY long time (hours, maybe even days), so for testing you can first limit to a specific folder. Like for your desktop:

cd /Volumes/Backup*/Backups.backupdb/*/Latest/*/$HOME/Desktop
echo "Current folder on backup disk: $(pwd -P)"
sudo diff -qr . $HOME/Desktop 2>&1 | tee $HOME/timemachine-diff.log

If there's no output, then there are no differences. For testing just rename a file on your desktop, which should give you both "Only in ." for the original name (which is only on your backup) and "Only in /Users/username/Desktop" for the new name (which is not in the backup).

Notes:

  • When backing up over a network you'll probably use a sparse bundle. Just double-click that sparse bundle file to mount it before running the above commands. When done, right-click and Eject it.

  • Some files are excluded by design, some software may simply exclude itself, and FileVault folders are only written to a backup when you log out first. See Does Apple’s Time Machine app really copy everthing?

  • To see what has been written to the (latest) backup, see TimeTracker (GUI) or timedog (command line). Note that, even when running as an admin user, sometimes these programs need to be run as root to see all files. See How do I retrieve files from Time Machine backups from another computer? for help.

  • Log messages are not only written to Console (in Applications, Utilities; filter on backupd, or use Time Machine Buddy), but different log messages are also kept in a hidden .Backup.log file on the backup disk itself, within the folder with the backup date. See also What is Time Machine doing? at Server Fault.

  • Since 10.6.3 I noticed a "Verifying Backup..." stage in Time Machine, followed by "Preparing 51,959 Items...", prior to "Backing Up". Console mentions "Running backup verification", "QUICKCHECK ONLY; FILESYSTEM CLEAN" and "Backup verification passed!"

    I have no idea what verification does. Maybe it's comparing the backup to the current disk contents: when I only have about 3.5 GB free disk space on my Mac, I noticed "CopyHFSMeta hit low disk space threshold", so apparently it's copying a lot of data back to my Mac? This is then followed by "Backup verification skipped during CopyHFSMeta", "Insufficient space on boot volume to complete backup verification" and a false "Backup verification skipped by user!" while I did not skip this myself. These messages are only found in the log; no indication to the user whatsoever, and the backup completes without any warning.

  • Apple offers a support article named About "Time Machine completed a verification of your backups. To improve reliability, Time Machine must create a new backup for you." In that article, the steps to manually verify the backup disk only check the physical condition of the disk image, and do not compare its contents to the disk of your Mac. So I guess that error is not about the backup contents either. Odd quote from that article:

    Note: Do not repair the disk image with Disk Utility.

Time Machine uses hard links, which makes each backup look like it holds all files. See a fine technical explanation at Ars Technica.

Arjan

Posted 2009-09-27T21:22:28.107

Reputation: 29 084

I wonder about the circumstances in which CopyHFSMeta (currently in hfs-191.1) may be run by the operating system.

– Graham Perrin – 2012-08-19T11:46:27.047

4

As per Mac OS X 10.6.4, you can initiate a verification of your backup by option-clicking the Time Machine icon in the menu bar.

I'm not sure what exactly is verified, but when I did it, Time Machine recommended that I start a new backup to improve reliability.

Further reading: Apple knowledgebase article.

Frost

Posted 2009-09-27T21:22:28.107

Reputation: 268

1Nice. Odd that OS X cannot just create a new up-to-date backup without removing the history, but maybe those days will come too... – Arjan – 2010-07-12T17:20:27.313

1That verification process is just running a Disk Utility Verify on the Disk image on the Time Capsule. If you don't have a Time Capsule, nothing will happen. It's not verifying the backup data, just the integrity of the Disk image it is stored on. – Benjamin Schollnick – 2010-07-23T15:44:10.797

@Benjamin, can you tell us how you know? I just ran into "Insufficient space on boot volume to complete backup verification" when having just 3.5 GB free disk space on a MacBook, which somehow tells me it's copying a lot of data back to that MacBook. (Plenty of space left on the backup disk. In my set up, that disk is attached to another Mac --and shared wirelessly through AFP-- but that other Mac has plenty of space too.) – Arjan – 2010-11-10T20:21:48.677

@Arjan, Time Machine doesn't do verification of individual files (eg copy file, verify file to ensure copied correctly, nor corrupted). Make a up to date TM backup, change a specific file, and option click on the TM menu extra, and choose verify backup. It won't report a bad backup.. See the Apple KBase article above. And http://blog.fosketts.net/2010/08/11/time-machine-completed-verification-backups-improve-reliability-time-machine-create-backup/ . Time Machine doesn't have a verification phase in it's backup cycle.

– Benjamin Schollnick – 2010-11-10T20:30:29.910

Oh... And the real proof is, run a Time Machine backup verification. I have 356 GB of backups, and my verification takes less then 10 seconds. But my TM disk is directly connected to my system, so there is no sparse disk image, thus the quick finish. – Benjamin Schollnick – 2010-11-10T20:33:54.913

Hmmm, odd, @Benjamin: my verification takes hours. (Wireless indeed, but hours compared to seconds is a bit odd.) I guess you're right, but still I wonder why/what it's copying then. I guess next time I'll monitor it a bit more (and see how long a plain Disk Utility validation takes). – Arjan – 2010-11-10T21:02:03.383

While running verification one can see fsck_hfs in the process list taking up quite some resources. And it checks the filesystem of sparse bundle image. – Michael Krelin - hacker – 2013-08-10T14:46:32.667

2

The Time Machine command-line utility has an option to do this: "tmutil compare". Check "man tmutil" for all the various switches available.

https://www.google.com/search?q=tmutil%20compare

William Croft

Posted 2009-09-27T21:22:28.107

Reputation: 21

Please don't use links to non-static information like the results of a Google search in your answer. Edit it to include a short summary of what you want to express, or (in this case) perhaps just remove the link since the search term is rather straightforward. – jstarek – 2016-02-05T14:32:40.873

1

You may try one application from Mac's utilities (Application->Utilities): Migration Assistant. With this tool, you may use one option to transfer information from your backup Time Machine to local computer.

Another way is to use this tool to install Mac from Time-machine to another virtual Mac on HD. I have not tried this yet. Not sure if it is possible to make a virtual box with OSX.

David.Chu.ca

Posted 2009-09-27T21:22:28.107

Reputation: 2 967

Migration Assistant -> From Time Machine doesn't show anything useful. – jtimberman – 2009-10-04T04:44:24.040

0

Check out BackupLoupe – it gives you some great ways to navigate across your Time Machine backups.

Martin Cleaver

Posted 2009-09-27T21:22:28.107

Reputation: 131

1How did you find this program? – Canadian Luke – 2012-09-21T09:05:27.950

1Can you add more information on how this program solves the problem in the question. – ChrisF – 2012-10-01T21:24:35.863

0

Doing a Time Machine backup to a network-based share is known to be more risky and fraught with problems. So, if you really, really, do not want to run the risk of hitting trouble with your upgrade and then having further trouble getting back to where you were then I would strongly recommend temporarily using a local disk and a tool like ShirtPocket's SuperDuper! or Carbon Copy Cloner

For just brute-force verifying your data, however, I think the best you can do is to manually mount the sparsebundle on your network drive, and use something as simple as 'diff -cr' to compare the bulk of the files from the 'Latest' version against your system drive (which is obviously going to throw up some that have changed since TimeMachine last ran.)

jrg

Posted 2009-09-27T21:22:28.107

Reputation: 745

Just tried the diff method, and it doesn't seem to work... I suspect that Diff doesn't manage hard links very well? – Benjamin Schollnick – 2009-09-28T17:14:04.063

I don't see why it should stumble over that.

I just tried it ("diff -r --brief" seems to work better, for a summary) over a small portion of two subsequent Time Machine hierarchies and it seemed to do ok, reporting "Files... differ", "Only in ...". It does throw up some errors related to symbolic links, if they can't be resolved to actual files. Those seem to be because there actually are dangling symbolic links even in the source copy. – jrg – 2009-10-07T16:48:02.650