NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
4.2.18 kills Time Machine .sparsebundle
Just a word of warning to all that have updated to RAIDiator 4.2.18 and are using your ReadyNas as a Time Machine network drive.
I had setup my Time Machine-backups using the "old way" of manually creating the sparsebundles (all placed on the same share, "backup") but different user-accounts for each computers to access the share so that they couldn't access anything but their own sparsebundle. It all worked very well until this week..
After the update to 4.2.18 ALL three sparsebundles became corrupted and I've so far not been able to repair or extract any data from them!
My clients are one Power Mac G5 with Leopard ( 10.5.8 ) and two Snow Leopard MacBook Pro's ( 10.6.8 ).
I don't think I have anything special about my setup other than perhaps that I've setup all accounts on the ReadyNas (and all computers) with synced UID's.
(Legacy reasons since I also have a linux server that's serving shares over NFS).
The error that I got when I later tried to manually connect the backup share using the different tm-users that I have is "Something wrong with the volume's CNID DB, using temporary CNID DB instead.Check server messages for details. Switching to read-only mode.". At this point I downgraded to 4.2.17 but the damage was done :( :cry:
The weirdest thing though is that it all seemed to worked well (just after the update to 4.2.18) but before I had rebooted the computers.
ps. Before anyone remind me of the importance of (off-site) backups, well I'm using rsync that runs every night so by the time I noticed what had happened the corruption had been synced to my backup.
I had setup my Time Machine-backups using the "old way" of manually creating the sparsebundles (all placed on the same share, "backup") but different user-accounts for each computers to access the share so that they couldn't access anything but their own sparsebundle. It all worked very well until this week..
After the update to 4.2.18 ALL three sparsebundles became corrupted and I've so far not been able to repair or extract any data from them!
My clients are one Power Mac G5 with Leopard ( 10.5.8 ) and two Snow Leopard MacBook Pro's ( 10.6.8 ).
I don't think I have anything special about my setup other than perhaps that I've setup all accounts on the ReadyNas (and all computers) with synced UID's.
(Legacy reasons since I also have a linux server that's serving shares over NFS).
The error that I got when I later tried to manually connect the backup share using the different tm-users that I have is "Something wrong with the volume's CNID DB, using temporary CNID DB instead.Check server messages for details. Switching to read-only mode.". At this point I downgraded to 4.2.17 but the damage was done :( :cry:
The weirdest thing though is that it all seemed to worked well (just after the update to 4.2.18) but before I had rebooted the computers.
ps. Before anyone remind me of the importance of (off-site) backups, well I'm using rsync that runs every night so by the time I noticed what had happened the corruption had been synced to my backup.
4 Replies
- Could you please try 4.2.19-T4 beta (http://www.readynas.com/forum/viewtopic.php?f=51&t=55394)and see if this fixes the problem? There is a fix relevant to using the same UID on your NAS and on your Mac
Please also note that updating to 4.2.18+ involves an update to the CNID database. If you have lots of files this can take a long time. Please be patient and wait for this to complete.
Also has guest access been enabled on your AFP shares due to bug in 4.2.18 (since corrected in 4.2.19)? mdgm wrote: Could you please try 4.2.19-T4 beta (http://www.readynas.com/forum/viewtopic.php?f=51&t=55394)and see if this fixes the problem? There is a fix relevant to using the same UID on your NAS and on your Mac
Please also note that updating to 4.2.18+ involves an update to the CNID database. If you have lots of files this can take a long time. Please be patient and wait for this to complete.
Also has guest access been enabled on your AFP shares due to bug in 4.2.18 (since corrected in 4.2.19)?
Didn't notice if there was any change when it came to guest access as I reverted down to 4.2.17 in hopes that it was just some freak issue with netatalk that prevented the sparsebundles from working correctly and now went strait to 4.2.19-T4
So now I'm at 4.2.19-T4 but I still get the "no mountable file systems" warning when I try to open the sparsebundles so I guess that I'll just have to accept that all my Time Machine backups are now gone :(.- So you didn't disable the schedule for you backup job so that you have your backup from before the downgrade still? It would've been nice if you could've worked from that.
Nightly backups are good, but it can be good to maintain an older backup as well (e.g. a monthly backup).
You didn't mention a "no mountable filesystems" warning when you try to open the sparsebundles. You mentioned a line about the "CNID DB"
I'd suggest waiting a few hours and see if the situation changes, maybe even a day from that.
I also just noticed that you mentioned using multiple TM users.
The only method of using Time Machine to backup to the ReadyNAS that is supported is documented here: http://www.readynas.com/TimeMachine mdgm wrote: So you didn't disable the schedule for you backup job so that you have your backup from before the downgrade still? It would've been nice if you could've worked from that.
Nightly backups are good, but it can be good to maintain an older backup as well (e.g. a monthly backup).
You didn't mention a "no mountable filesystems" warning when you try to open the sparsebundles. You mentioned a line about the "CNID DB"
I'd suggest waiting a few hours and see if the situation changes, maybe even a day from that.
I also just noticed that you mentioned using multiple TM users.
The only method of using Time Machine to backup to the ReadyNAS that is supported is documented here: http://www.readynas.com/TimeMachine
You're right, I just said that the sparsebundles seemed to be corrupted in my first post, sorry about the lack of details, it was late and I just wanted to warn others about what had happened to me, perhaps get a few good hits that might help recover something, so I'm very grateful for your time.
So for completeness sake I'll list in what order things went down..
1. Updated to RAIDiator 4.2.18 and did a initial check that I could still connect my shares as usual, use all Time Machine bundles to backup the computers for the night and it worked just like before, no CNID DB problems at this point.
2. Shutdown my computers for the night.
3. In the morning I got out to work in the yard but the kids and my wife fired up the computers and when I got in to eat lunch they complained that Time Machine was annoying them with messages about not being able to access the target disk "all the time".
4. I turn off Time Machine on all computers and try to connect to the my "backup" share (where all TM-sparsebundles are stored) and at this point I got the CNID DB message and the sparsebundles all give the "no mountable file systems" error (if they'd still been ok at this point I guess that they should have mounted read-only as the share was read-only due to the CNID DB problem).
5. Read up on CNID DB online and find that it might be some issues with the latest netatalk version so I choose to downgrade to RAIDiator 4.2.17 at this point.
6. I can now connect to all my shares over afp again without the CNID DB message but the sparsebundles behavior stays the same, "no mountable file systems".
7. I've also now moved the old sparsebundles to the side and started over with clean sparsebundles.
As for daily/weekly/monthly backups goes, I'd love to have more of them but with three sparsebundles at about 1 TB apiece having more than one backup on other media/servers would simply cost to much for home use.
Work wise I keep all our clients websites (I work part time as a Managed Service Specialist managing a datacenter with web-/db-hosting amongst other things), backup'd daily and date-stamp each backup and then keep each file for a month, except for the first daily backup each month, those are kept for 6 months so it's not that I don't know how to do the backups ;)
Since I didn't really loose anything other than the possibility to recover older files that might have been deleted (in error or otherwise) and I'm already backing up again, just like before, I'm not about to spend too much time trying to recover these old backups any more, if someone finds something worth testing I'd be more than happy to see if there is a way to recover at least one of the sparsebundles.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
