Incremental backup solution. was: What logs etc do I need tocheckfrequently?
This solution sounds nice, I can even imagine setting up an additional machine (on the same location though) to have a somewhat galvanic isolation between the disks. Only fire, earthquake and a neutronbomb would affect such a backup solution. However, I could use a push in the right direction when it comes to how to configure and what software to use for achieving the incremental backup tasks. Could you hint me in how your system is doing this in a more detailed way? Cheers, Joachim --- | On Sun, 2003-12-28 at 10:27, Robert Huff wrote: | There are systems that will put 160 GB (uncompressed) on a | single tape ... they'll just run you $3000-3500. | If, on the other hand, you think of it as a yearly full dump | (split over multiple tapes) plus monthly incrementals then a DLT | 8000 ($1000 ??) at 40 GB (uncompressed) will do just fine. | | | Robert Huff | | I'd like to throw in my (home) solution here. | | I have had a dedicated file server on my home network for years. It | serves out files to clients on the network via SMB and HTTP. This | machine stores all of my permanent (and not so permanent) data and has | two large identical disks. Only the first is used. The other is used | strictly to back up the information on the first. A cron job runs a | script at 7AM every morning which powers up the backup disk, mounts it, | performs an incremental backup and then powers down the backup disk | again until the next morning. | | The moral: Buy double the amount of disk space that you think you'll | need or settle for half of what you can afford. Then force yourself to | use one half only to back up the other half. Disk-to-disk backup is | probably the best way to go for the home user. It's cheap and it's easy, | but it won't break the bank. Reliability is probably significantly less | than a $3k tape solution, but careful monitoring of the system and quick | response to potential problems can mitigate this to a large degree. | | Pretty soon I plan to move the backup disk to a separate machine on the | network that gets powered up each day by some kind of external timer. | The machine will power up, contact the file server, do an incremental | backup, then shut itself off. This would put me just one step short of a | complete daily off-site backup, all with hardware that is considered by | most to be obsolete. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Incremental backup solution. was: What logs etc do I need tocheckfrequently?
On Mon, Dec 29, 2003 at 10:35:49AM +0100, Joachim Dagerot wrote: This solution sounds nice, I can even imagine setting up an additional machine (on the same location though) to have a somewhat galvanic isolation between the disks. Only fire, earthquake and a neutronbomb would affect such a backup solution. Before certain events in New York, we used to talk about hypothetical jumbo jets when considering our disaster plans. Secure off-site backups are a necessity. Take care thought that the off-site location really is secure. I did hear that some of the businesses in the World Trade Center had considered the other tower as a suitable location for their off-site backups. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way PGP: http://www.infracaninophile.co.uk/pgpkey Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK pgp0.pgp Description: PGP signature
Re: Incremental backup solution. was: What logs etc do I need tocheckfrequently?
| Before certain events in New York, we used to talk about hypothetical | jumbo jets when considering our disaster plans. Secure off-site | backups are a necessity. Take care thought that the off-site location | really is secure. I did hear that some of the businesses in the World | Trade Center had considered the other tower as a suitable location | for their off-site backups. I know a company whom's(?) office burned down to the ground. They where saved by the secretary who forgot to put the backup-tape in the safety box, instead she brought it in her handbag. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Incremental backup solution. was: What logs etc do I need tocheckfrequently?
On Mon, 2003-12-29 at 04:35, Joachim Dagerot wrote: This solution sounds nice, I can even imagine setting up an additional machine (on the same location though) to have a somewhat galvanic isolation between the disks. Only fire, earthquake and a neutronbomb would affect such a backup solution. However, I could use a push in the right direction when it comes to how to configure and what software to use for achieving the incremental backup tasks. Could you hint me in how your system is doing this in a more detailed way? Cheers, Joachim I'd be glad to. First, it's actually a Linux system, though there's nothing particularly Linux-specific about it except the device names and the method of spinning down the backup disk after the job. The cornerstone of the solution is the rdiff-backup program (http://rdiff-backup.stanford.edu/ or in ports at /sysutils/rdiff-backup). rdiff-backup is a python script that mirrors one directory to another. It can do incremental backups and it can do them either locally or remotely. It's really a slick piece of software and I'm continually surprised that it doesn't get more publicity. First, there's the (trivial) script /usr/local/sbin/backup-share.sh. This is run by a daily cron job to backup directories on the disk that contain Important Data. Mine is very specific to my system. It is *not* pretty and I plan to overhaul it sometime soon to include error handling and an external config file. #!/bin/bash # script to automatically back up the important stuff on /nfs/share prog=/usr/local/bin/rdiff-backup src=/nfs/share dst=/backup/share budirs=code emu images media music school software text webpage mount /backup for dir in $budirs do $prog $src/$dir $dst/$dir done umount /backup # put backup drive in sleep mode since we won't be needing # it again for the next 24 hours or so hdparm -qY /dev/hdd A note about the last line: it appears that FreeBSD can only spin-down SCSI disks on command. (See camcontrol(8).) The best way to power down IDE disks seems to be just setting a suspend timeout in the power management section of your BIOS. Once the disk is unmounted, FreeBSD won't touch it thereafter and the system should put it in suspend mode automatically. The crontab entry looks like this: # backup selected dirs in /nfs/share @ 0730 daily 30 07 * * * sh /usr/local/sbin/backup-share.sh That's really about it. Like I said before, moving the backup disk to a separate machine would be trivial. If there are any questions, I'd be glad to answer them. Charles Ulrich -- http://bityard.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
