Synology DS112j and time machine - the backup disk is not available

[mentaluproar]

I have this unit set up and updated to the latest DSM 4.2, my retina macbook pro running just fine (finally arrived!) but time machine is very unstable.

The only way I can get time machine to backup to the NAS is to head into the web interface of the NAS, switch the time machine setting from "The Wayback Machine" to "not selected yet", clicking apply, then switching it back again. That only grants my mac a single run at it though, and it wont keep it that way. I have to keep resetting it. Otherwise, the NAS runs just fine.

Time machine worked perfectly with my mac mini. Why does my rMBP seem to have such an aversion to it?

 

[blueroom]

Try the 4.3 update, see if it stabilizes it. TM works fine on all our macs.

 

[mentaluproar]

Sorry, it is DSM 4.3. My bad.

 

[priitv8]

Sounds like a Bonjour problem. TM uses the Automatic Disk Discovery (_adisk._tcp.) service advertisement to find the backup disk on local network.

 

[mentaluproar]

It was a quota problem. I stopped and reset quota early on. I reset quota again, deleted the sparse bundle, and allowed the backup to start over. All better!

 

[deadwalrus]

I have warned people on these forums in the past: Do not trust Time Machine with a 3rd party NAS. Apple has made it extremely fragile. There are countless stories online of people thinking it was working fine, and then when they went to recover it failed utterly.

It is an Apple issue that they will not fix, responding "Sorry we do not support 3rd party backup devices. Please buy a Time Capsule thx."

The issue is simple: If Time Machine encounters an error of any kind (including slow-to-wake-up hard drive), it will corrupt all previous and future backups.

Yes, all future backups will be corrupt as well. But the best part is that it does not warn you that the backups are not working properly, it just continues to act like it's working, and when you try to restore, you are SOL.

Smart design, no?

 

[mentaluproar]

If they opened up the AFP documention, this would be a non-issue.

 

[priitv8]

The issue is simple: If Time Machine encounters an error of any kind (including slow-to-wake-up hard drive), it will corrupt all previous and future backups.

Do you have any facts that can support this claim? As i see it, drive needs to be awake, before one can even mount the sparsebundle, to begin with. After mounting, fsck_afp will be run, before backup can even start. So, it's hard to buy this late waking drive as a problem. But I'd like to be taught otherwise.
I've been struggling myself with backups going bad on USB-attached external drive connected to AirPort Extreme. On a balancing note, same USB-drive connected to OS X Server's Time Machine service has yet to fail on me.
PS Last such failure was logged as:

backupd[20786]: Found 49 files (5.3 MB) needing backup
backupd[20786]: 1.6 GB required (including padding), 648.67 GB available
backupd[20786]: Copied 1344 files (24.5 MB) from volume Macintosh SSD.
backupd[20786]: Created new backup: 2013-09-17-205800
backupd[20786]: Starting post-backup thinning
kernel[0]: hfs: node=74570 fileID=4 volume=Time Machine Backups device=/dev/disk2s2
kernel[0]: hfs: Runtime corruption detected on Time Machine Backups, fsck will be forced on next mount.

As is obvious from this log, the failure occurred after actual backup had been completed, during post-backup thinning.

 

[mentaluproar]

USB drives on AirPort Extreme are really prone to corruption. You can do it, but don't.

 

[deadwalrus]

Do you have any facts that can support this claim?

https://discussions.apple.com/thread/3684176?start=0&tstart=0
http://www.garth.org/archives/2011,...ine-sparsebundle-nas-based-backup-errors.html
http://www.readynas.com/forum/viewtopic.php?f=71&t=62390
https://discussions.apple.com/thread/2465249?start=75&tstart=0
http://blog.fosketts.net/2010/08/11...prove-reliability-time-machine-create-backup/
http://forum.qnap.com/viewtopic.php?p=326624
http://forum.qnap.com/viewtopic.php?p=248013
http://apple.stackexchange.com/questions/56063/time-machine-keeps-asking-to-create-new-backup
http://www.readynas.com/forum/viewtopic.php?f=71&t=48501
https://discussions.apple.com/thread/4207296?start=0&tstart=0
http://apple.stackexchange.com/ques...achine-sparsebundle-that-will-no-longer-mount
https://discussions.apple.com/thread/3170910?start=15&tstart=0

https://discussions.apple.com/thread/2716411?start=0&tstart=0

 

[ColdCase]

Yes the web is full of examples.... there are a few that have made it work, and more that thought TM was working fine until they needed it....

 

[priitv8]

https://discussions.apple.com/thread/3684176?start=0&tstart=0
http://www.garth.org/archives/2011,...ine-sparsebundle-nas-based-backup-errors.html
lots of links...

Yes, I've seen most of these posts.
I've mainly skipped the NAS-related topics, because they're below my radar.
Still, none of the posts seem to get to the root cause of the problem.
I've run Garth's recovery procedure numerous times, and it has never been able to repair any of my broken sparsebundles! Apparently, things have changed since 2011 when that article was written.
But these repair attempts have revealed an interesting phenomenon: the sparsebundle is always broken at one of it's B-Trees!

/dev/rdisk1s2: fsck_hfs run at Tue Sep 17 22:40:46 2013
/dev/rdisk1s2: ** /dev/rdisk1s2
/dev/rdisk1s2:    Executing fsck_hfs (version diskdev_cmds-557.3.1~5).
** Checking Journaled HFS Plus volume.
** Detected a case-sensitive volume.
   The volume name is Time Machine Backups
** Checking extents overflow file.
** Checking catalog file.
   Invalid key length
(4, 74570)
/dev/rdisk1s2: ** The volume Time Machine Backups could not be verified completely.

Remember, node=74570 fileID=4 was exactly the point in above log, where the run-time error occurred?
I've seen both Invalid key length and Invalid node height messages.
For me, the question still remains: given the same type of USB external drive, in a cheap enclosure, connected to OS X Server never fails, but connected to AP Extreme, fails at unpredictable intervals. It looks as if one can eliminate the drive completely from the equation. It must be either the OS handling low-level file-system taks or low-level handling of USB port, that causes this. If the same problem appears also on TC-s internal SATA-disk, then also USB should not be the cause.

 

[deadwalrus]

Yes, I've seen most of these posts.
I've mainly skipped the NAS-related topics, because they're below my radar.
Still, none of the posts seem to get to the root cause of the problem.

Somewhere deep in there I read that Time Machine uses sector level copying instead of file-level copying. Supposedly, copying by sector instead of file leaves no room for jitter, and so is much more error prone. Apparently Apple accounts for this in their Time Capsule product and communicates problems back to the Time Machine computer via some proprietary protocol that no one else has access to.

 

[priitv8]

Somewhere deep in there I read that Time Machine uses sector level copying instead of file-level copying.

Hmm, this theory sounds interesting. I will try to pinpoint these posts from those forums via googling.
BUT, in my case, the filesystem failed during post-flight thinning, which is essentially removal of outdated backups (it will remove last day's hourly backups and leave only the last one, maybe there's also some consolidation involved?).
Another question is this: considering that TM incremental backup consists for the most part just from hard links and not files themselves, how can a sector-level copying be used in this scenario at all?

 

[slapple]

I have warned people on these forums in the past: Do not trust Time Machine with a 3rd party NAS. Apple has made it extremely fragile. There are countless stories online of people thinking it was working fine, and then when they went to recover it failed utterly.

It is an Apple issue that they will not fix, responding "Sorry we do not support 3rd party backup devices. Please buy a Time Capsule thx."

The issue is simple: If Time Machine encounters an error of any kind (including slow-to-wake-up hard drive), it will corrupt all previous and future backups.

Yes, all future backups will be corrupt as well. But the best part is that it does not warn you that the backups are not working properly, it just continues to act like it's working, and when you try to restore, you are SOL.

Smart design, no?

So all these 3rd party NAS vendors that say they support Macs and Time Machine are either lying or they didn't do enough testing to run into problems?

EDIT:

If they opened up the AFP documention, this would be a non-issue.

Looks like Apple does have AFP documentation available for 3rd parties to write AFP compatible servers/clients:
https://developer.apple.com/library...working/conceptual/afp/Concepts/Concepts.html
https://developer.apple.com/library...erence/AFP_Reference/Reference/reference.html

"This specification is a list of commands that are part of the Apple Filing Protocol wire protocol. These are primarily of interest to developers writing AFP client or server software."

Also Apple has a document specifically for 3rd parties who want to develop a volume that can be used for backing up Time Machine:
https://developer.apple.com/library...n.html#//apple_ref/doc/uid/TP40008951-CH1-SW1

So any 3rd party NAS that has problems with Time Machine probably isn't following these specs exactly. Apple has provided the documentation.

EDIT: Didn't see deadwalrus's reply to me before I edited this post. Apparently Apple doesn't follow their own spec so 3rd parties have problems.

 

[deadwalrus]

So all these 3rd party NAS vendors that say they support Macs and Time Machine are either lying or they didn't do enough testing to run into problems?

They technically are compatible. The backups will just fail silently and unpredictably.

And it's not the fault of the NAS makers -- they implement the Apple protocols correctly. It's jsut that Apple doesn't give a **** that they are going out of spec with Time Machine.

The forums are replete with discussions on these topics. Synology, for instance, has had lots of technical discussions with their customers to try to resolve the issues. But in the end there is nothing they can do if Apple won't tell them what they are doing.

 

[ColdCase]

They technically are compatible. The backups will just fail silently and unpredictably.

This is consistent with what I have read and experienced. Even hanging drives off an Apple AirPort extreme can be flacky.

The best way to backup a Mac to a third party NAS is to use something like CarbonCopyCloner, I think. I have had no issues with CCC. Being a belt and suspenders type guy I use TM to backup to either a local drive or time capsule, and CCC to backup to my Synology NAS.

If I had to do it over again I'd just buy a refurbbed mini and run OSX server instead of trying to save a couple $$ using a third party NAS. But thats just me.

 

[slapple]

If there can be issues with using Time Machine and a 3rd-party NAS, what about just reading/writing files manually from Mac OS X to a 3rd-party NAS? Any possible issues with that?

 

[ColdCase]

Haven't heard of any file transfer issues (file by file), its just the quirks of time machine that gets in the way of reliable and predictable time machine backups.

 

[priitv8]

...what about just reading/writing files manually from Mac OS X to a 3rd-party NAS? Any possible issues with that?

The first problem with any manual process is the weakest link - the human. You deliberately allow for human error.
Secondly, if you wish to do incremental backups (as opposed to copying full contents of HDD over, that is a space hog on your backup disk) manually, you are in for lots of time and effort or some special tools.

 

[slapple]

Haven't heard of any file transfer issues (file by file), its just the quirks of time machine that gets in the way of reliable and predictable time machine backups.

I was thinking that if the Time Machine issues are due to AFP, then if you manually copied files over with AFP then you might run into the same issues. I read that with Synology you can tell it to use either SMB or AFP. Probably best to tell it to use SMB to avoid any possible issues with AFP.

The first problem with any manual process is the weakest link - the human. You deliberately allow for human error.
Secondly, if you wish to do incremental backups (as opposed to copying full contents of HDD over, that is a space hog on your backup disk) manually, you are in for lots of time and effort or some special tools.

What if you wanted to use some other backup program, like CarbonCopyCloner that was mentioned? If AFP is the cause of the problems and the NAS uses AFP, then CarbonCopyCloner will suffer from the same problems as TimeMachine.

 

[priitv8]

My answer to both of your statements above is this: give it a try! I have the impression, that TimeMachine works only over AFP. Although recently rumours have been around, that with Mavericks also Apple is slowly abandoning AFP in favour of SMB/CIFS. Haven't felt the urge to jump the AFP ship yet myself.

Using CCC would be a valid alternative. Esp if using 3rd party NAS as backup target.

PS I am still not convinced, that the problems with TM on unapproved devices (doesn't matter if by Apple or 3rd party), are caused by AFP as file sharing protocol.
As of today, I am even not far from stating that the USB-backup works on 4th Gen AEBS flawlessy. But I will have to let it run a tad longer before I can say this with confidence.