View Full Version : Backing up a partition to disk image unmounts that partition
02-15-2005, 09:34 PM
I've been trying out SuperDuper! as a backup solution for our lab (server/client network). I've been trying to back up to the (empty) second disk on our server machine (we'll use external storage as soon as it arrives).
The main server disk has two partitions, one stores the OS and the other has the user accounts on a 'Home' partition. If I make two corresponding backup partitions on the second disk I find that I can easily backup to them using a simple volume to volume copy.
However, when I backup to a disk image I have noticed that all the users get thrown off the network and lose their home accounts. It would seem that the Home partition is being unmounted towards the end of the copying process. When everything is finished copying, 'Home' appears to mount again.
Is this the case, and if so will this always be the case? I thought it might be easier to have one backup partition which would store several backup disk images rather than having lots of separate backup partitions (allowing us to keep separate nightly and weekly backups etc.). If our 'Home' partition will always be unmounted though I may have to make several partitions.
02-16-2005, 08:46 AM
It sounds to me like you're using the 'imaging' option in the Options page rather than saving to an image by choosing it in the 2nd pop-up. They're quite different (and the one in Options is device-specific) -- I suggest not doing that, and I think you'll be OK.
Also: rather than using *either*, I'd suggest using the method detailed in "How do I update an image?" in the FAQ. By using a sparse image that way, you'll be able to update it with Smart Update, rather than having to create the whole thing from scratch every time. (There's more on this topic on p21 of the User's Guide -- take a look!)
02-17-2005, 01:35 AM
Ok, I've double checked and I'm not using the 'imaging' option in the Options page. I'm just copying our 'Home' partition to a disk image using the 'Backup - all files' script and choosing a disk image from the the 'to' drop-down window and then selecting the 'Disk Image...' option (I selected a disk image 'home_backup.dmg' on the Desktop).
Our 'Home' partition is about 14 Gb. After the copying process begins a home_backup.dmg.sparse_image icon appears on the Desktop. I've also now noticed that a Volume icon called 'Home' also appears on the Desktop (in addition to the main disk icon for the 'Home' partition).
~40 minutes later, the SuperDuper! window changes to say 'Finalizing home_backup.dmg session. At this point an icon for home_backup.dmg appears on the Desktop. However, this is also the point at which our 'Home' disk partition becomes unmounted and any logged in users find that they can't really do anything.
~20 minutes later and the SuperDuper! window changes to say 'Pre-scanning home_backup.dmg to support fast block copy restore'.
~15 minutes later and the copying finishes, leaving just a home_backup.dmg disk image on the Desktop.
Until I stop and restart the servers AFP service, users cannot access the Home partition.
This 'bug' is reproducible, I've done this about four times now (it still surprises me it takes 75 minutes to copy 14 Gb!). I can only imagine that after 40 minutes, when the 'Home' volume icon is unmounted, it is somehow unmounting the main 'Home' disk partition too. I'm still not sure why copying the Home partition necessitates creating a volume of the same name.
Hope this information helps you trace what might be happening.
02-17-2005, 07:31 AM
OK. This really sounds like a bug in AFP, which is not properly dealing with the unmount of the sparse image.
As I mentioned before, the User's Guide describes what's going on during the 'direct imaging' process. Multiple steps are required to ensure the backup is of minimal size, and to allow it to be restored, using ASR, to any device (it's device-independent). Instead, though, I'd strongly recommend using the technique in the FAQ, as I suggested before. I think this will get you past this strangeness while we try to determine what, exactly, is happening. (It really sounds like AFP is erroneously marking the volume as unavailable even though it's not unmounted.)
02-17-2005, 12:54 PM
Drop a note to support; we've worked up a transcript that does one thing slightly differently (it doesn't show the volume in the Finder), and this might work around the bug in the AFP server.
You had asked one other thing about the name of the volume: we need to name it the same because when restored with ASR, this is the name that would be used for the restored volume...
02-17-2005, 02:15 PM
I've tried your alternative suggestion of first creating a disk image via Disk Utility and this method works exactly as you described and I can use Smart Update without causing our Home partition to be unmounted.
The minor problem I have with this method is that to properly automate this approach you have to first mount the disk image which is just another step to do.
Thanks for looking into this.
02-17-2005, 03:58 PM
Actually, SuperDuper! will automatically re-mount the image when invoked... glad that the alternate method works...
I've sent the alternate transcript via support for you to try.
02-17-2005, 06:11 PM
I just found out that SuperDuper automounts the disk image as you have just said so that's cool.
I'll try to try the script that you sent me later.
Thanks again for all the help.
02-17-2005, 07:42 PM
No problem. I'll await your test results.
vBulletin® v3.8.6, Copyright ©2000-2013, Jelsoft Enterprises Ltd.