My new backup solution...
Jan. 7th, 2007 01:07 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
nowalmartI wrote a while back about my problems with Backup.app. Now that my FruitCo-provided .Mac subscription has expired, I decided to move on to another backup solution (mostly because Backup.app does not work without a working .Mac subscription).
Being a bit broke at the moment, and not ever wanting to pirate software, I looked around for Free/OSS software, and came across rsyncbackup, a perl script that helps automate backups using rsync.
A few background points:
1) I have two external hard drives, both 160GB. One is dedicated to eyeTV recordings, and one is reserved for movies and backups. Ideally I would get another external and dedicate that exclusively for backups. That should happen with the next decent-paying job.
2) Backups used to be done to both my iDisk and the external. With the loss of my .Mac account, backups will be done exclusively to my external. I plan on manually doing some backups to DVD-R to keep off-site. The external is now also locked down with a Kensington lock, so theft is less of an issue.
Any of my former Fruit Stand coworkers know that I am not one to shy away from a command line. rsyncbackup has no GUI. Configurations are done using text configuration files. I spent about 1.5 hours last night getting everything set up the way I want it to be.
I really like the flexibility and power of rsyncbackup, but I admit that it was not exactly the easiest program in the world to configure.
The manual is pretty good, but still has a long way to go. A few points:
1) As everyone seems to freely admit, the version of rsync that ships with OS X is broken, and you need to install rsyncX. This is a pretty easy step.
2) In config.conf, though, the manual makes no mention of adding a --eahfs tag, the tag rsyncx uses to copy with extended HFS+ attributes. I added it anyway.
3) rsyncbackup looks for its configuration files in ~/backup/. I am not a big fan of having a folder sitting there, so I moved it to ~/Library/backup/. This requires, of course, using a -x option everytime I rsyncbackup. Minor, but I wish the author would find a better place for the configuration files.
4) While the author distributes the example configuration files in one directory, he forgot to mention that you need to create a folder named "logs" in your "backup" folder. Without that folder the program will exit with an error (luckily a descriptive one).
5) In destinations.conf, the examples show several examples of both SSH/remote backups, as well as incremental backups. Since the manual describes incremental backups much later, this can be very confusing. I think even just a link in the manual to the incremental backups section would be sufficient.
6) In backupset.conf, the example file lists that the [daily] set will run at "6:45 11:45 15:45 19:45" (we will not go into the definition of "daily" at this time). All of these are actually set in your crontab, and the example crontab that is given only runs it at 19:30 (a reasonable time, but it means that both daily and nightly are each one once every 24 hours). It would seem that you can name backup sets whatever you want, just as long as you call the correct one with the -s option.
7) This brings me to my next suggestion: While the author lists the different rsync options several times, he neglects to ever list the options for rsyncbackup.
A brief rundown that I have seen:
There might be more, this is just the ones I have found going through the documentation.
8) Sucks that Growl will not work when rsyncbackup is called from cron, but what are you going to do. Getting remotegrowl seemed like more work than I wanted to do.
9) The manual suggests using "crontab -e" for editing your crontab. For anyone not familiar with vi, I would suggest not doing this. The better thing might be to edit the crontab you want in your text editor of choice, saving it somewhere easy to find, and then using "crontab filename" to load it directly in. First, however, run "crontab -l" to make sure you do not already have something in your crontab that you will clobber with your new file.
All in all I really like rsyncbackup. The flexibility is outstanding, and anyone with some UNIX knowledge should find it fairly easy to use. The documentation could be improved a bit more, but I think that sounds about par for the course for any OSS UNIX utility.
Next up: directions for how to automate rsyncbackup to automatically run a backup whenever a drive, such as an iPod, is mounted.
Being a bit broke at the moment, and not ever wanting to pirate software, I looked around for Free/OSS software, and came across rsyncbackup, a perl script that helps automate backups using rsync.
A few background points:
1) I have two external hard drives, both 160GB. One is dedicated to eyeTV recordings, and one is reserved for movies and backups. Ideally I would get another external and dedicate that exclusively for backups. That should happen with the next decent-paying job.
2) Backups used to be done to both my iDisk and the external. With the loss of my .Mac account, backups will be done exclusively to my external. I plan on manually doing some backups to DVD-R to keep off-site. The external is now also locked down with a Kensington lock, so theft is less of an issue.
Any of my former Fruit Stand coworkers know that I am not one to shy away from a command line. rsyncbackup has no GUI. Configurations are done using text configuration files. I spent about 1.5 hours last night getting everything set up the way I want it to be.
I really like the flexibility and power of rsyncbackup, but I admit that it was not exactly the easiest program in the world to configure.
The manual is pretty good, but still has a long way to go. A few points:
1) As everyone seems to freely admit, the version of rsync that ships with OS X is broken, and you need to install rsyncX. This is a pretty easy step.
2) In config.conf, though, the manual makes no mention of adding a --eahfs tag, the tag rsyncx uses to copy with extended HFS+ attributes. I added it anyway.
3) rsyncbackup looks for its configuration files in ~/backup/. I am not a big fan of having a folder sitting there, so I moved it to ~/Library/backup/. This requires, of course, using a -x option everytime I rsyncbackup. Minor, but I wish the author would find a better place for the configuration files.
4) While the author distributes the example configuration files in one directory, he forgot to mention that you need to create a folder named "logs" in your "backup" folder. Without that folder the program will exit with an error (luckily a descriptive one).
5) In destinations.conf, the examples show several examples of both SSH/remote backups, as well as incremental backups. Since the manual describes incremental backups much later, this can be very confusing. I think even just a link in the manual to the incremental backups section would be sufficient.
6) In backupset.conf, the example file lists that the [daily] set will run at "6:45 11:45 15:45 19:45" (we will not go into the definition of "daily" at this time). All of these are actually set in your crontab, and the example crontab that is given only runs it at 19:30 (a reasonable time, but it means that both daily and nightly are each one once every 24 hours). It would seem that you can name backup sets whatever you want, just as long as you call the correct one with the -s option.
7) This brings me to my next suggestion: While the author lists the different rsync options several times, he neglects to ever list the options for rsyncbackup.
A brief rundown that I have seen:
| -b | Preform a backup, the set default is preformed if no -s tag is given | |
| -d | Debug | |
| -e | ||
| --growl | Enable growl notification | |
| --growlnotify | host:port:password | Enable growl notification |
| -s | set | The backup set to be run. Default install gives default, daily, nightly, weekly. Defaults to default if no -s option is listed. |
| -v | Verbose | |
| -vv | Very verbose | |
| -x | directory | Instead of looking for configuration files in ~/backup/, instead look in directory |
There might be more, this is just the ones I have found going through the documentation.
8) Sucks that Growl will not work when rsyncbackup is called from cron, but what are you going to do. Getting remotegrowl seemed like more work than I wanted to do.
9) The manual suggests using "crontab -e" for editing your crontab. For anyone not familiar with vi, I would suggest not doing this. The better thing might be to edit the crontab you want in your text editor of choice, saving it somewhere easy to find, and then using "crontab filename" to load it directly in. First, however, run "crontab -l" to make sure you do not already have something in your crontab that you will clobber with your new file.
All in all I really like rsyncbackup. The flexibility is outstanding, and anyone with some UNIX knowledge should find it fairly easy to use. The documentation could be improved a bit more, but I think that sounds about par for the course for any OSS UNIX utility.
Next up: directions for how to automate rsyncbackup to automatically run a backup whenever a drive, such as an iPod, is mounted.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2007-01-07 05:08 pm (UTC)no subject
Date: 2007-01-07 05:52 pm (UTC)Think about this example:
1) You create a document on Tuesday.
2) You run a full backup Tuesday night.
3) You edit the document on Wednesday.
4) You run a full backup Wednesday night.
5) On Thursday, you suddenly regret the edits you made on Wednesday.
What do you do?
Granted, this is uncommon, but can happen. There are some tricks to getting around that (keeping multiple backups, for example, or not backing up as often).
Situations like that are the reason I prefer something like ChronoSync (http://www.econtechnologies.com/site/Pages/ChronoSync/chrono_overview.html), or rsyncbackup.