Re: backup strategy questions
Hi Joe, I've used the Disk Utility and created a copy that boots. Thank you it was fun. I haven't done the cron thing yet or the psync over it. One question, it appears like everything on the restore copy is exactly the same, however the total file size and the total number of files is off by about 1%. Maybe Disk Utility is smart enough not to copy items in the Trash Can or maybe there is something else going on? Good question: I've had a bit of a trawl through my different copies and it does seem that there are some portions of the system that Disk Utility doesn't copy. For example, the swap files and associated guff (in /private/var/vm). That accounted for about a gig of the size difference on my machine. There's also some other contents of the / private/var/tmp that seems to escape copying, though I haven't looked closely enough to sort out what's taken and what's left. Similarly, it looks like the some of the caches (/System/Library/ Caches) might also escape the copying. I tried hunting down a page detailing the process, which is really asr (ie, Apple Software Restore, see man asr), but didn't have a lot of luck. Cheers, Paul
Re: backup strategy questions
Hi Paul, I've used the Disk Utility and created a copy that boots. Thank you it was fun. I haven't done the cron thing yet or the psync over it. One question, it appears like everything on the restore copy is exactly the same, however the total file size and the total number of files is off by about 1%. Maybe Disk Utility is smart enough not to copy items in the Trash Can or maybe there is something else going on? Joe. On Aug 10, 2005, at 2:27 AM, Paul McCann wrote: Hi Joe, ... I wrote a little program that creates a new directory each time (ie, 2005-08-09) and does a full backup using psync to the directory. My question: In the event of a hard disk failure, will I be able to boot from a full copy in a directory? How would I be able to recover? Probably not, but it's not too hard to make bootable copies. Just partition your backup drive so that you have a partition for each backup copy that you'd like to keep (I tend to roll three, so that at any time I have the last 2-3 days of live backups). Then use the Disk Utility to clone a copy of your live system onto as many copies as you wish to keep. It takes about 30 minutes to clone mine, but it's obviously pretty sensitive to the size of your live system. This process will produce bootable copies, but you probably don't want to be doing this all the time. My strategy is to get psync to synchronise each of the backups in turn, instituted via a cron job. Anyway, in more detail: (1) Make some appropriately sized partitions, so that each will be capable of taking a full copy of your live system. Allow some room for expansion. Disk Utility makes this easy. (2) For each partition: firstly erase the existing contents (takes about 5 seconds in Disk Utility), in the Erase tab. I think you can also click a button in the Restore tab (see below), but I've never gone that route. In any case, erasing any existing stuff is crucial to success. (3) Go to the restore tab and drag your live system into the Source text field and your first clean partition into the second (destination) source field. Click restore, enter admin password, and wait! Repeat as you will. You might like to test the bootability at this point: I've not had a problem with this technique. That done you can just set psync to consecutively roll through synchronising with the backups in turn. The entries in the crontab (/etc/crontab) should be something like # minutehourmdaymonth wdaywho command 15 4 * * 3,5 root/usr/local/bin/ psync -q -d / /Volumes/backup2 /Users/pmccann/psync_output_2 21 15 4 * * 2,4,6 root/usr/local/bin/ psync -q -d / /Volumes/backup3 /Users/pmccann/psync_output_3 21 Obviously that's for a rolling pair of backups on the imaginatively named /Volumes/backup2 and /Volumes/backup3. Iterate as necessary and adjust the wday fields. The files psync_output_2 etc will contain anything to STDOUT or STDERR from the process. In practice I just check that things have run OK by tailing those files and/or checking their modification date. Anyway, the upshot of this is that the backups always maintain their bootability. I've even --inadvertantly-- bumped the system version of the backups (10.3 = 10.4) using this synchonization technique; didn't cause any difficulties, and bootability remains. Best wishes, Paul
Re: backup strategy questions
Hi Joe, ... I wrote a little program that creates a new directory each time (ie, 2005-08-09) and does a full backup using psync to the directory. My question: In the event of a hard disk failure, will I be able to boot from a full copy in a directory? How would I be able to recover? Probably not, but it's not too hard to make bootable copies. Just partition your backup drive so that you have a partition for each backup copy that you'd like to keep (I tend to roll three, so that at any time I have the last 2-3 days of live backups). Then use the Disk Utility to clone a copy of your live system onto as many copies as you wish to keep. It takes about 30 minutes to clone mine, but it's obviously pretty sensitive to the size of your live system. This process will produce bootable copies, but you probably don't want to be doing this all the time. My strategy is to get psync to synchronise each of the backups in turn, instituted via a cron job. Anyway, in more detail: (1) Make some appropriately sized partitions, so that each will be capable of taking a full copy of your live system. Allow some room for expansion. Disk Utility makes this easy. (2) For each partition: firstly erase the existing contents (takes about 5 seconds in Disk Utility), in the Erase tab. I think you can also click a button in the Restore tab (see below), but I've never gone that route. In any case, erasing any existing stuff is crucial to success. (3) Go to the restore tab and drag your live system into the Source text field and your first clean partition into the second (destination) source field. Click restore, enter admin password, and wait! Repeat as you will. You might like to test the bootability at this point: I've not had a problem with this technique. That done you can just set psync to consecutively roll through synchronising with the backups in turn. The entries in the crontab (/ etc/crontab) should be something like # minutehourmdaymonth wdaywho command 15 4 * * 3,5 root/usr/local/bin/psync - q -d / /Volumes/backup2 /Users/pmccann/psync_output_2 21 15 4 * * 2,4,6 root/usr/local/bin/ psync -q -d / /Volumes/backup3 /Users/pmccann/psync_output_3 21 Obviously that's for a rolling pair of backups on the imaginatively named /Volumes/backup2 and /Volumes/backup3. Iterate as necessary and adjust the wday fields. The files psync_output_2 etc will contain anything to STDOUT or STDERR from the process. In practice I just check that things have run OK by tailing those files and/or checking their modification date. Anyway, the upshot of this is that the backups always maintain their bootability. I've even --inadvertantly-- bumped the system version of the backups (10.3 = 10.4) using this synchonization technique; didn't cause any difficulties, and bootability remains. Best wishes, Paul
Re: backup strategy questions
On 平成 17/08/10, at 1:29, Joseph Alotta wrote: Greetings Everyone, I have been using psync to back up my entire disk (about 20GB) to a local hard drive (300GB). Previously, I had been updating the backup drive with changes, but I was concerned that all history was unrecoverable. So I wrote a little program that creates a new directory each time (ie, 2005-08-09) and does a full backup using psync to the directory. My question: In the event of a hard disk failure, will I be able to boot from a full copy in a directory? How would I be able to recover? Full copy of your boot volume? My impression is that it's very difficult to successfully make a bootable image of a bootable volume. (I've booted an image, but have not done any really rigorous testing, and that was v 10.0.) There are ways to make images that can be restored, and there are ways to replicate but my understanding is that even the command-line ditto (and CpMac) may not succeed perfectly. Joel Rees [EMAIL PROTECTED] digitcom, inc. 株式会社デジコム Kobe, Japan +81-78-672-8800 ** http://www.ddcom.co.jp **