Time Machine Verification Issue

Thank you... wasn't sure.. so I put { in the string

ok so have finally tried this process and set it in motion yesterday morning... this is where I am at... and it hasn't moved on...

HELP

Alex:~ alex$ sudo su

Password:

sh-3.2# chflags -R nouchg /Volumes/TimeMachine/Alex.sparsebundle

sh-3.2#

sh-3.2#

sh-3.2#

sh-3.2#

sh-3.2#

sh-3.2# hdiutil attach -nomount -noverify -noautofsck /Volumes/TimeMachine/Alex.sparsebundle

/dev/disk2 Apple_partition_scheme

/dev/disk2s1 Apple_partition_map

/dev/disk2s2 Apple_HFSX

sh-3.2# tail -f /var/log/fsck_hfs.log

/dev/rdisk4s2: fsck_hfs run at Sun Feb 26 11:05:41 2012

/dev/rdisk4s2: ** /dev/rdisk4s2 (NO WRITE)

/dev/rdisk4s2: Executing fsck_hfs (version diskdev_cmds-491.6~3).

QUICKCHECK ONLY; FILESYSTEM CLEAN

/dev/rdisk2s2: fsck_hfs run at Sun Feb 26 12:17:12 2012

/dev/rdisk2s2: ** /dev/rdisk2s2 (NO WRITE)

/dev/rdisk2s2: Executing fsck_hfs (version diskdev_cmds-491.6~3).

QUICKCHECK ONLY; FILESYSTEM CLEAN

The article http://www.garth.org/archives/2011,08,27,169,fix-time-machine-sparsebundle-nas-b ased-backup-errors.html is very good, gives the points you need to do to be able to run fsck properly and try to repair the volume.

However, some portions of the article are a bit complex to a few people, so, let me try to help you here. In short, this is what you will do.

Mount the volume where your <whatever name it is>.sparsebundle file is. You can use the Finder and just click on it. If the Eject button shows up on the right side of the device and you can see the sparsebundle file, that is all we need.

Start Terminal, then open two windows:

spotlight -> Terminal -> <enter> -> after it opens Command+N

You should have two terminal windows now.

In one, just type this:

tail -f /var/log/fsck_hfs.log

This is what

On the other, you'll do a few commands. Please just type what is in a single line in bold. Italics are results.

sudo sh -

Type in your password when asked.

You MUST be root to do these things. If you don't know what root is, that is the SUPER USER for your Mac, in other words: GOD. For your sake, be VERY careful with any command you do as SU. Most of the "protections" don't work because as you're GOD you're supposed to know what the ffff you're doing.

whoami

root

This is just to confirm you're root. If you do NOT see "root" after, you did something wrong in sudo sh -. Do NOT proceed as things will not work.

chflag -R nouchg <drag your sparsebundle file from finder over the terminal window>

This should help those having issues with the name. In Terminal, some characters must be changed to this and that, some people just type stuff and use tab, others prefer commas, or you can just drag the file. They all work.

If you get this:

chflags: /Volumes/<a lot of your stuff>: No such file or directory

It is bad. The command didn't work and you need to make it work. Just for crying out loud, google a bit about Unixes and get it working, it is **** easy. If you can't, turn it all off and go to a Genius bar.

The past command is kind of the "trick". It removes the restrictions in the sparsebundle files so you can actually run a filesystem check, otherwise, we will run into a few problems, specifically with the image being read only. I'll show some results about it in the next command.

hdiutil attach -nomount -noverify -noautofsck <drag your sparsebundle file from finder over the terminal window>

/dev/disk1 Apple_partition_scheme

/dev/disk1s1 Apple_partition_map

/dev/disk1s2 Apple_HFSX

Now it is when it gets intersting. This command is to "attach" the sparsebundle file to your system. Just to give you some clue, a sparsebundle is basically a LOT of files and directories that when "attached" simulate a physical drive. Once this process is done, the operating system looks at the "disks" and "partitions" inside the image as real devices.

Once you run this hdiutil command, it will automatically trigger a filesystem check.

Remember that other window with the "tail -f /var/log/fsck_hfs.log" command? You should have seen some activity there.

If you get this:

/dev/rdisk1s2: fsck_hfs run at Thu Mar 22 11:45:37 2012

/dev/rdisk1s2: ** /dev/rdisk1s2 (NO WRITE)

/dev/rdisk1s2: Executing fsck_hfs (version diskdev_cmds-540.1~34).

QUICKCHECK ONLY; FILESYSTEM DIRTY

Then you did NOT do the chflags command properly. Detach the image and go back and check what you could have done wrong.

To detach:

hdiutil detach /dev/disk1

"disk1" unmounted.

"disk1" ejected.

Again, this is in my case. If you got anything different when you ran hdiutil attach, then that is what you want to put here.

What we are looking for is something like this:

/dev/rdisk1s2: fsck_hfs run at Thu Mar 22 11:45:37 2012

/dev/rdisk1s2: ** /dev/rdisk1s2

/dev/rdisk1s2: Executing fsck_hfs (version diskdev_cmds-540.1~34).

** Checking Journaled HFS Plus volume.

** Detected a case-sensitive volume.

The volume name is Time Machine Backups

** Checking extents overflow file.

** Checking catalog file.

** Checking multi-linked files.

** Checking catalog hierarchy.

** Checking extended attributes file.

** Checking multi-linked directories.

** Checking volume bitmap.

** Checking volume information.

** The volume Time Machine Backups appears to be OK.

Yay!!!! =D

If you got that, then yes buddy, we fixed the problem. I really wish Apple would switch from HFS to XFS. **** stupid filesystem corrupts so easily... =/

Did you know? FSCK_HFS stands for File System ChecK, and HFS stands for Hierarchical File System, a file system developed by Apple in the 80s.

Anyway, even with everything in order, Time Machine will outsmart us by just skipping any looks on the image. **** you TM! Then is when you need to remove those lines mentioned in the article. In short, find the file com.apple.TimeMachine.MachineID.plist inside your .sparsebundle package. You can use Finder for that. Just right click your sparsebundle file, Show Package Contents and there you have it.

Remove the lines:

<key>RecoveryBackupDeclinedDate</key>

<date>**whatever**</date>

<key>RecoveryBackupDeclinedDate</key>

<date>**whatever**</date>

Find these lines and change the 2 to 0:

<key>VerificationState</key>

<integer>2</integer> --> change to <integer>0</integer>

Now just your Time Machine icon in the menu bar and choose "Back Up Now". Mine started and did yet another "Back Up Verification". This process is important as Time Machine will "fix" some of the changes we did, in this particular case putting back the flags we changed with chflags.

And there we go!!! It worked for me as a charm!

I did this over Wifi without problems, didn't take that unbelievably long, althout it is an N at 5GHz network. If yours is not, you might want to just go with Ethernet as suggested. Ethernet is always better, but sometimes it is a pain in the butt to get a cable going.

I hope you guys can make it work too.

Thanks for the article link and good luck.

btw, shouldnt you be doing chflags not chflag above?

Crap... yes, yes it should. =/

I wish I could edit and fix the post.

I have had this message since I changed to Lion. I have a MacBook Pro and my backup goes by WLAN and LAN to a QNAP NAS now, but I had the same problem with a WD NAS before (which I replaced hoping that QNAP would provide better Apple support and TimeMachine reliability than WD).

At the beginning, the message appeared in shorter intervals (about every two weeks), but the last three occurrences after the change of the NAS were on December 4th, February 4th and April 4th - after exactly two months every time. Is this just by accident or does it give somebody a clue as to what might happen here?

However, this time I tried the solution given by morph21 / Garth and it worked, much better and easier than trying repairs with the disc utility! Thank you!

I'm glad it worked for you too rolfz.

Stay with me on this message so the end of it could make some sense to you.

Maybe what people don't understand is that the sparsebundle container is like a hard drive. Let me make an analogy here.

This is your computer's hard drive:

> Hard Drive

-> Partition Table

--> Partitions

---> Filesystems

It is in the filesystem where all information is stored. Now, lets look at a sparsebundle container:

> Sparsebundle container

-> Partition Table

--> Partitions

---> Filesystems

Hey!!! It is the same!!! Yes, yes it is.

So, we can say that a sparsebundle container is basically a "virtual" hard drive, right?

Now, tell me this:

- Would you "hot" unplug your hard drive, in other words, while the computer is active and running?

- Would you put a bad quality cable connecting your hard drive to your computer?

When you have network problems communicating with the external drive that holds the time machine backups, aka the sparsebundle container, it would be the same as having problems communicating with a physical hard drive.

Networks do have a lot of algorithms to prevent packet loss and other issues, but if your network is bad, specially if in wifi with interference and bad signal, that leads to corruption of the filesystem, and THIS is the main cause of all these problems with time machine backups.

Other possibilities are that your external drive or network storage is giving you data corruption, and although OS X should warn you about that, maybe it happens out of the OS control zone, which then again will lead to corruption of the filesystem and trouble.

I hope this helps to understand it a bit more.

TL;DR: check your network. If you're running wifi make sure to try cable for a while to see if the problems go away, if they do, that is your problem.

Thank you for your clear explanation.

But it doesn't help solving the problem. Maybe my network has some faults. I don't care. Everything else works like it should.

TimeMachine should just work. Apple used to make things that just work. Either Apple should make this just work or let it die. Steve would never have tolerated this faulty thing to stay alive without it being repared.

Thank you for your detailled answer. I would understand such problems if I'd just pull the plug of the NAS while its writing to disc - this would be an unexpected "(power) network interruption" a home NAS could not handle. But interruptions in the communications network are not totally unexpected and have to be handled by the network or applications on both side.

First, my network is reliable enough for all other applications, my Powerbook is in the same room as the wifi router most of the time, the NAS is connected by cable - I do not think that it is a "bad" network.

Second, as you said, if there are small problems the network software should handle them without affecting the data written to the disc. If I copy a file to the NAS and Finder tells me it's ok, then it has to be ok! If TimeMachine writes a backup somewhere and gets an "ok", the backup must be ok. And if TimeMachine doesn't get an "ok", then it must be able to handle this situation, e.g. by stopping the backup and retrying it later. Invalidating perhaps years of backup data because of one failed write operation over a network is not a proper way of handling common network problems.

(Certainly, the error could also be within the NAS. But as I had these problems myself with different NAS brands and I see a lot of people having those problems with all other kinds of NAS, USB sticks, TimeCapsule and the like, I would expect the failure being on the side that is common to all: TimeMachine)

Third, TimeMachine is meant to work in the background. As a user, I never know whether it is doing something right now or not, unless I am actually working at my Mac and looking at its icon. So, TimeMachine is bound to meet situations like e.g. somebody restarting the router from another PC while TimeMachine is working and other unexpected major problems. It it clear that with such a problem, TimeMachine will not be able to finish the actual backup. Nevertheless, it must not destroy any older backup even in such a situation! Later on, when everything is working again, it must finish (or delete) this unfinished backup and build a consistent new one. At least, that's what I would expect from a backup application.

So, I could only accept "a bad network" as the reason of those problems if you or Apple tell me that TimeMachine is not meant to work in a network environment at all and should be used only with local hard discs...

I couldn't agree more.

However, somtimes things just go wrong.

If you can try to plug your external storage directly into your computer and use it like that for a few days. I had an external drive that I used for backup of my iMac before plugged through firewire and I never had ANY issues with that until I went to a wireless network.

Sometimes I still regret not having bought a simple 1TB external USB small portable drive to have the backups done localy and be done with the whole wireless backup issues.

I have been having this issue every few months and I use a Synology NAS. I have called apple care and they say that the only supported network drive is Time Capsule and they cannot help me. I contacted Synology and got the following response:

Thanks for writing us and I apologize for the inconvenience this is causing you. I have seen this before. Please use a wired connection when doing your Time Machine backups. The reason it keeps redoing them is the sparse bundle gets corrupted. This is a Time Machine issue, not a DiskStation one however I have a link for what to try. This is NOT a supported method but should work.

http://www.garth.org/archives/2011,08,27,169,fix-time-machine-sparsebundle-nas-b ased-backup-errors.html

I’m not trying to pass the buck, just stating fact. This has resolved this issue prior.

Warm Regards,

Michael

Synology America Corp

www.Synology.com

Whats the point of having a network drive if I have to backup using a wired connection! This whole thing is complete BS.

I'm loosing trust in Time Machine. In the last 6 months I've done 4 restores using TM on various Macs. All of them left 'gotchas' Mail asking to set up accounts again -- or having corrupt messages -- Software that had to be re-registered. Permisions that needed fixing.

A. Does anyone have a TM like way to do things that is truly robust:

Robust backup:

1. Interuptions in network connectivity are only that: Interuptions.

2. Deals with active disks during backup.

3. Can flawlessly restore.

4. Has mechanisms for verifying that the backup was performed properly.

5. Monitors the health of the destination drive.

B. Failing TM's convient view of the timeline:

Other good backup solutions.

There are ways of achieving what you want, but none of them together and specially not through a wireless network.

Allow me to make a few comments on your list considering Time Machine's operation.

1. Interuptions in network connectivity are only that: Interuptions.

This is at the Operating System layer. Unfortunately, you can't bit / byte compare to "resume exactly where you left". TM does restart where it left it but it copies the whole files again, not just parts of it. Then again, when it writes on the .sparsebundle file, if at those crucial moments where it is updating table of contents, catalogs and lets say the filesystem, you can NOT have interrupts. Think of it like turning of the power while updating your phone's firmware. You simply can't trust what is in there.

2. Deals with active disks during backup.

Time Machine doesn't do that well, and honestly, with backups being made in hourly basis, that is quite hard. Their main idea was that "a bit every hour is better than a bunch at the end of the day". Still, if you make changes on large files (100Mb or more) often, this is a problem, and you might want to consider other backup solutions.

3. Can flawlessly restore.

This is almost impossible. Although you can copy a file and change back all its flags and attributes, which TM does, when the application that uses that file starts it might have other checks performed to determine if the file was "tainted". A lot of applications do that to avoid "counterfeit" installations. When this is the case, there is nothing you can do. Same could be said about mail. Have you tried Menu Bar -> Mailbox -> Rebuild? Those cache files every now and then are changed while your backup is being made, which leads to corruption.

4. Has mechanisms for verifying that the backup was performed properly.

TM does that, as much as to squeek at the sight of any inconsistency, thus asking to make a new backup. It is not perfect, but it is not as if it didn't do anything.

5. Monitors the health of the destination drive.

Oh well, this is regarding where your "destination drive" is responsibility. Lets say it is in a NAS solution, that solution must have settings to allow you to put an e-mail or anything so it could warn you on any possible problem.

In the past two months I also had a few issues with a hard drive, which ended up dying, and I had to restore my TM backup 3 times. In all three, the things that didn't work were exactly the ones that I expected would not, as I mentioned in item 3. I can say I didn't loose a single message, and that all I had to do was to "activate / register" two or three applications.

There are solutions for corporate backup that costs dozens of thousands dollars. They do have software that will do everything you're asking, but they have both a server for backup, a client application and a lot of infra-structure to support that. Yet, even on this structure if you unplug the power cord during a backup you risk the backup server, the backup itself is marked as "incomplete / corrupt" and you need to make a new backup.

Time Machine offers a very good realiable solution for just plugging a hard drive on, and if wireless networking or simply networking is such a big problem for you, buy an USB / Firewire / Thunderbolt drive, plug it in and enjoy having close to no issues and way faster backups.

It is not my intention to defend or be picky, just to give a good view of what you're asking for and where those problems might come from. As Steve Jobs said when the whole iPhone 4 antennagate issue came up: "We can't overcome the laws of physics, yet."

Agreed. I was presenting an ideal. However there are some ways that can work around some of the issues.

1. The file system supports snapshots. Example: ZFS, Novel, BTRFS, The idea is that writes that occur after a snapshot has been made, the file is copied on write. This can still trip you up, if the file has long periods where it is not in a useful state. And this does get around the issue of file being moved while backup is going on.

2. Verification after write: Read a file off the source, write to backup, read back the file, compare to original.

I was running a backup using a drobo. Despite the log being filled with firewire errors, TM proceeded as if nothing was wrong. Ended up with 3 weeks of unsable backups. (Yes, I'm furious with Drobo too.) I don't think that TM is actually reading the disk to verify a file. I would be willing for TM to take longer to run less often in order to actually verify.

However the problems that people are having with TM speak of something fundamentally wrong -- they are losing their entire backup history.

3. Postponing open files. If files are open, let them be for the time being, come back at the end. These should be tracked for a while, and a user settable parameter should ask, "Would you please close the following files so they can be backed up."

4. Implement a 'flush to disk' API where the OS can tell an app to flush pending operations. This is needed anyway just for shutdown purposes. (I *should* be able to click "restart" my mac and have it do the right thing, however, there is always at least two apps that hang with a dialog box.)

5. Implement a "Complete Backup" that can be run once a week or day or on command that can give you a perfect restore image. So if you KNOW that you are going to replace the user disk, , do the backup, replace the disk and do the restore.

In essence this would be a 'hibernate the system to disk' run backup, wake the system up. If you restored a full system from this you end up in the exact state as you would waking the machine from hibernation.

When I worked with Unix systems user level backups happened nightly when most users had logged off. In one place we had periodic rsyncs that happened at 2 hour intervals, but users were told that these were not guaranteed. But I kept backups in 13plicate -- daily for a week, weekly for a month, monthly for a year,.

System level backups (Anything NOT in user space) were much rarer, and were done shut down to single user mode. In this way, the ONLY thing happening in the machine was the backup. This should be possible in multiuser mode with snap shots -- if system programs can be depended on.

Applications generally should not have writeable files anywhere in their directory tree, so archive once, and restore as needed. (Windows was (may be still) notoriously bad about this.) Unixen are generally pretty good. Apps that needed to track real time multiple licenses generally used a subdirectory of /var

Flawless restores are trivial. I had a computer lab that did a flawless restore every night every machine. The key to it is that you need two mechanisms to boot. In my case I could to a network boot from a dos image, do either a restore or a save of the local hard disk. You can also do this by having a way to book off of alternate partitions.

I love the way it handles file history, but Time Machine is flawed. Hopefully discussion of it's flaws will help Apple to improve it.

I'm still looking for alternate solutions.

I've just completed the repair recipe posted by Garth, and further detailed by morph21

http://www.garth.org/archives/2011,08,27,169,fix-time-machine-sparsebundle-nas-b ased-backup-errors.html/

It successfully repaired the problem with my TM sparsebundle file.

The fsck scan reported "invalid volume free block count", and then fixed it.

Instead of using the tail command to monitor the progress of fsck, I ran Console and viewed /private/log/var/fsck_hfs.log

MacBook Pro, Snow Leopard 10.6.8, TM backing up to raided drives on a Netgear ReadyNAS.

The MBP is generally connected using WiFi (w/Airport Extreme 802.11N).

TM is now running once again.🙂