2008-06-28

snaps, rc.server, and firewire drives

I haven't found out much more, but here are two fairly critical facts.

Prelimaries: I have partioned a 300GB firewire drive with a 50B partition called "Clone" and a 250GB partition called "Snapshots". The plan is for Clone to contain a bootable clone of the main drive, produced by ditto once per week or so, and for Snapshots to contain the snapshots. Obviously, if I put more than 50GB on the main drive (which is a 250GB drive, by the way), this scheme won't work. In fact, I probably need a 1TB drive for this, with Clone equal in size to the main drive and the rest for snapshots. At some point, I will upgrade, but for now, I am using around 30GB on the main drive so this will be good for testing and for use for quite a while.

The first amazing fact; based on my little test with mount, firewire drives are not mounted during the time rc.server is running. So in order to do my firewire backup, I will have to mount and then unmount them. I hope that the necessary driver is available at that time. I wonder what will happen if I leave them mounted read-only...

The second fact, and I should have known this, is that when the system eventually mounts the partitions, it starts running Spotlight on them (well, they are empty so this was sort of a no-op). Once I start putting data on them, I absolutely do not want Spotlight even to see them. In fact, when I'm not actually backing up to them (from rc.server), I want them always to be mounted read-only. So I need to research these two issues: getting Spotlight to skip them, and making sure they are mounted read-only by default (possibly by mounting them read-only in rc.server?).

Hasta mañana.

3 comments:

Greg Shenaut said...

Just a comment--I tried mounting the firewire drive without specifying a special device (mount -r /Volumes/Clone ...) and it failed to mount. Next I tried specifying the special device, and it failed this time because of an incorrect superblock. Next, I added the "-t hfs" flag, and that was the charm. The two file systems were mounted read-only, and they also stayed mounted read-only when the system came up multi-user. So tentatively, the plan now is to mount them within rc.server in-w modebased on the special device they are mounted on when the periodic script runs (if they aren't there, no reboot or backup occurs), and then when the backup is complete, to use the -f -u -r flags to mount them as read-only.

Greg Shenaut said...

One other matter. When the Clone and Snapshots filesystems were mounted, I got a query from Time Machine about whether I wanted to use them. That's strange.

The other issue was that the Finder unmounted (ejected) them fine, in fact, it knew that they were both on the same drive and allowed me to choose to eject the whole drive or any single part of it. But is it OK that an ordinary user was able to unmount them? I guess it is.

So for the moment, I still plan to leave the drive mounted read-only from rc.server in its standard location.

Greg Shenaut said...

OK, here's the deal. The commands to mount and remount the drives are:

/sbin/mount -t hfs -w /dev/disk3s3 /Volumes/Clone
/sbin/mount -t hfs -w /dev/disk3s5 /Volumes/Snapshots
...
/sbin/mount -u -r /dev/disk3s3
/sbin/mount -u -r /dev/disk3s5

Note that it is critical to know which device to use. The way around this is to use the LABEL=Clone mechanism. I don't know if this can be used with the mount command itself.

It also appears that while LABEL= can be used in fstab (but not on the command line(?), the mountpoint must already exist, so it should be in /Volumes, where it could be deleted (remember that the boot drive is read-only so it can't be easily created). To be continued.

About Me

My photo
Ignavis semper feriæ sunt.