[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[cobalt-developers] The trouble with trib^H^H^H^HIncremental backups
- Subject: [cobalt-developers] The trouble with trib^H^H^H^HIncremental backups
- From: Jeff Lasman <jblists@xxxxxxxxxxxxx>
- Date: Sun Jan 26 23:12:00 2003
- Organization: nobaloney.net
- List-id: Discussion Forum for developers on Sun Cobalt Networks products <cobalt-developers.list.cobalt.com>
A lot has been written lately about rsync and incremental backups. I'm
going to preach against both of them.
Yes, a few years ago, when drives were expensive (iirc, my first one
gigabyte drive, back in '95, cost me about $600) and connections were
slow, some of us had to exercise the tradeoff between incremental
backups and full backups.
However, if you make incremental backups, for example, from the first of
the month, and your system gets hacked on the 29th, you have to restore
all backups from the first before your system is operational again.
If you use rsync, it's even worse; you probably don't have unifected
files.
May I suggest:
Sunday 2 am (the Internet isn't too busy then) back up your entire
system and save it to the Sunday directory, overwriting last Sunday's
backup.
Monday 2 am back up your entire system and save it to the daily
directory, overwriting Saturday's backup.
Tuesday 2 am back up your entire system and save it to the daily
directory, overwriting Monday's backup.
Wednesday 2 am back up your entire system and save it to the daily
directory, overwriting Tuesday's backup.
Thursday 2 am back up your entire system and save it to the daily
directory, overwriting Wednesday's backup.
Friday 2 am back up your entire system and save it to the daily
directory, overwriting Thursday's backup.
Saturday 2 am back up your entire system and save it to the daily
directory, overwriting Friday's backup.
That's a lot of storage, but considering the options, it's certainly
affordable. And it should give you enough time to find out you need a
backup and still have a reasonably recent one you can restore quickly.
On RaQ3 and RaQ4 systems we maintain our systems as closely to each
other as possible, and use CMU for our backup, adding mySQL and dns
before we tar the resulting directory structure. On other systems, or
for more granular control, you may decide to back up differently.
And oh, always test your strategy... there's nothing quite as bad as
having backups you can't restore from.
Jeff
--
Jeff Lasman, nobaloney.net, P. O. Box 52672, Riverside, CA 92517 US
Internet & Unix/Linux/Sun/Cobalt Consulting +1 909 778-9980
Our jblists address used on lists is for list email only
To contact us offlist: "http://www.nobaloney.net/contactus.html"