Slashdot Mirror
What Software Do You Use for Unix Backups?
jregel asks: "Linus has stated that
dump should not be considered a reliable backup program, and both tar and cpio have their limitations. So what are Slashdot readers doing for backing up Linux servers and workstations? (you do backup, right?)" Given this bit of news, have you used anything other than the standard Unix staple to back up your Linux boxes? If you were forced off of tar, cpio and dump, what would you use as a replacement?
You know, I was thinking about the same thing since I had problems with a recent restore from a compressed dump archive. I was missing some files probably because I ran the dump from an active file system.
I found out that solaris has a very interesting command: fssnap
It creates a read-only snapshot of your filesystem intended for backup operations.
You create a snapshot, dump the snapshot, then delete the snapshot and the dump is consistent.
I wonder if there's something like this for linux...
I think the 2 above are both excellent, Taper for the less demanding environment, BUpEdge for a system with multiple drives.
/var/squid) instead of just simply skipping that directory.
I'm actually doing a 100gb backup as we speak... so good timing on the Ask Slashdot.
My only beef with Taper (and I'd use it otherwise, on my home system) is that when you do an "e"xclude or "i"nclude of a directory, it scans the entire subtree, which can take *forever*, (like when excluding
mindslip
I use rsync over ssh too; I back it up to a machine at work (which I can reach from home). It basically does my whole home directory except for a few excludes for stuff that's a bit sensitive (ssh keys, keychain, ICQ history) which I manually backup to CD now and then. The machine at work is then backed up with TSM.
The rsync over ssh style of backup is so easy it's addictive!
This backup machine keeps seven generations of daily backups on one disk (cp -al, so no duplicating of static data), and a few weekly ones on the other disk. Every night it rsyncs things off-site (to my home). That rsync has turned out to be unreliable (probably my adsl), so I have a script that does it in small bits and pieces. Takes a few hours in the early morning.
In Murphy We Turst
I use "mkisofs /etc /root /home -R -T -o backup.iso && cdrecord dev=0,0,0 speed=4 blank=fast -data backup.iso" to create an ISO image, which will be burned to the CDRW disk. That's all I need to backup my workstation. And restoring the data doesn't require any special tools.
I have been extremely happy with Amanda. Single centralised backup server running amanda-server. Multiple workstations running the amanda-client. Amanda automagically schedules backups based on sensible heuristics. I just tell Amanda how many tapes I have, how many workstations I have, and Amanda does all the hard work of working out how much tape capacity is required and how often it should schedule incrementals/fulls.
The server/client protocol has been designed to avoid reliance on dangerous security holes like rsh. The server sends the client a "send me your dump" message. The client then connects back to the server and delivers it the output from dump or tar. You can configure exclusion lists on the client if you're worried about sending certain files or filesystems. You can also encrypt the data stream and/or use Kerberos for authentication.
If I forget to load a blank tape then Amanda plays it safe. It doesn't overwrite last night's backup: instead it stores incrementals into the "holding disk". Amanda will then flush the held backups to the next blank tape.
Amanda emails me reports after every backup with a neat summary of what went right/wrong. It also gives you several hours advance warning if you forget to load a blank tape or if any of the workstations are offline.
The only downside of Amanda is that it is fiddly to setup. The documentation is poor and the configuration files are cryptic. But if you're willing to invest some time and effort then you can't do much better (for free) than Amanda.
Features:
For those who don't know: AMANDA cannot append to tapes.
Every time you backup with AMANDA it must start from the beginning of the tape.
So, if you want backups every day, you must have a tape for every day.
(http://amanda.sourceforge.net/fom-serve/cache/29
I hear rdiff-backup is good, but I still mainly use rsync with the incremental rsync type scripts that use hardlinks for versioning. We use it here to backup over 2TB of data over a 512kbit link. Since you never need to do a "full" backup, the bandwidth is plenty.
I've had enough abrasive sigs. Kittens are cute and fuzzy.
Jason
"FORMAT C:" - Kills bugs dead!
That's what I used to do, (wrappering tar) but the matanence of the script became a pain and I needed to add support for incremental backups, and exclusion lists.
After some web searching, I on google, freshmeat etc, I came across dobackup.pl, which is very similar in functionality to what I would have written myself. It wrappers AFIO, it supports full, incremental and differential backups to fixed and removable media.
One of its best features is support for exclusion lists. Users can put in any directory they like a .nobackup file, which contains a list of expressions for filenames that should not be backed up, making it easy to exclude all the mp3 of mpeg files from user home directories.
A downside is that the perl source code is a mess. It looks like it was written by someone who is used to programming in shell, but had very little experience in perl. Just reading through the code, I saw a number of potential bugs, where global variables where being trampled. In short it is a good program, but it needs a re-write.
Some people have already mentioned Amanda.
In addition to amanda, I have good luck with star coded by Jörg Schilling. star is very feature-rich, fast, standards compliant and has been around since 1985. Give it a try!
The star-users mailing list is here . You can also look at the man page and finally download it
Corporate Gadfly
Jonathan Archer: the most beaten up Enterprise captain in Star Trek history
http://backuppc.sourceforge.net/
Automated backups to an online disk server, open source, and a really nice web interface as well as command line interface.
It uses samba and ssh to backup and restore to windows and unix machines.
You can have it restore any files/folders in a backup you select, using the same methods (samba or ssh) as well as it can send the restore files to your browser in a tar or zip file.
I recently replaced a machine using amanda and a DLT drive with a fileserver using a raid 5 array and backuppc. Best switch ever.
The best part is the FreeBSD costs considerably less than $40k.
> The problem is tar always archives the entire space which makes it difficult to
> backup, say gigabytes of data, daily.
>
> A decent backup tool (as opposed to an archival tool) must absolutely have
> incremental backup support.
Er?
tar --help
[snip]
Operation modifiers:
-G, --incremental handle old GNU-format incremental backup
-g, --listed-incremental handle new GNU-format incremental backup
[snip]
Local file selection:
-N, --newer=DATE only store files newer than DATE
--newer-mtime compare date and time when data changed only
[snip]
This is in tar (GNU tar) 1.12
(Which is really really old actually.. slackware 3.2 dist)
There are also tons of options to exclude directorys and files, to force it to span disks, and pretty much match in any way you need.
I've been making incremental backups (and even restored a few) for awhile now.
Here's a howto for rsync snapshot backups. I keep daily backups for two weeks, weekly backups for two months, and monthly backups forever. I rolled my own wrappers for this stuff in a few hours.
It is about eight zillion times better than tapes. I have hot, random access to all versions of all my files. Thanks to the hard linking, space used is moderate. Since it backs up to a remote computer, backups are instantly off site. And if I want to verify my backups, I don't have to feed in eight million tapes; I just write a little perl script.
I recommend it highly!
Rsync can also be used to make some very nice incremental "snapshot" backups.
I believe you are wrong. EVMS (which was built by IBM) and is distributed under the GPL license for free, provides software raid (0,1,5), filesystem snapshots, has both GUI and CLI tools for linux.
It's a simple patch you can add to any 2.4 kernel.
Have you even read Linus's comments?
Dump works by reading the raw data partition. That works great with an unmounted partition, or if you have a very limited OS that does not perform any caching.
But Linux is different - it's now using the cached pages as the primary content, usually flushing them to disk only as the pages are dropped. This is the approach used by most mature OSes, but Linux doesn't yet have an interface for "dump" programs to query the OS for updated but unwritten sectors.
So dump is the worst of all possible things now. Not only will you get incomplete live files, you can get incomplete files even if the users have all terminated but the pages haven't been flushed to disk yet. That's non-deterministic, and there's simply no way for you to perform reliable dumps.
On the practical side, dump is specific to the filesystem. When everyone ran ext2, that wasn't a problem. But now people may have a mixture of ext2, ext3, reiserfs, xfs, jfs, and probably even other formats. Each requires their own dump and restore, and that requires a lot more effort.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
The ISO9660 FS has some pretty strict limits on number of files in a directory (~1024) and length of filenames under Rock Ridge extensions (~30s, I think). If you exceed this, you'll be unable to retrieve those "extra" files - I know after being burned by it in the past.
(Obviously I don't like working in directories with thousands of entries, but some tools will produce them, it's easy to accidently hit numbers like that with mail or news spools, etc.)
As for the RW media, you do realize that they have a limited lifetime, right? Are you validating the discs you write, or going on blind faith?
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
You do realise that dump doesn't give you a filesystem snapshot? Even on Solaris - the most venerable of modern UNIX - the manpage for ufsdump clearly states:
There's a good reason why nobody seriously uses dump anymore.
And Linux does support filesystem snapshots. The Linux LVM explicitly lists it as a feature.
Moderators, this person was not informative, they were simply wrong.
Arkeia is alright if your backing up a small amount of data/servers (10?).
.so file to disable fsync, I emailed it to them, and explained it. The next day I recieved an email from their support along the lines of:
However, I would highly recommend against using Arkeia in an "enterprise" enviroment even though they claim it is "enterprise network backup" software.
Where to start:
- Since it isn't free, and of course requires client licenses, (different types, for different OS's too), if you exceed your client license limit, the backup won't run at all. This is expected, but the kicker is anyone on your network can install Arkeia, point it to backup.domain.com and use up one of your licenses without you even knowing!!
- You can't give arbitrary names to clients, and Arkeia defaults to not using a FQDN when naming the clients itself. So you often end up with two or more "www" clients. Renaming these requires changing Arkeia's plain text (more on this later) database, and often results in losing the data for that host. It also defaults to whichever IP address the client decides to send, which is often ends up being 127.0.0.1.
- Plain text database! This is absolutely pathetic. If you need to backup any amount of files, you have to use ReiserFS for the database partition or else you run out of inodes 30mins in to a backup. Arkeia creates approx. 2 files per directory it backs up. Our Arkeia database has about 10 million files in it (find . | wc takes about two hours to run on a Dual 1GZ SCSI160 RAID1), totalling about 20gb. Most of the CPU time used during a backup is in the fopen/fclose calls.
It also calls fsync after each of the changes to these files, which, until we disabled this in the kernel, a full backup job took about 48hrs. Which makes daily backup impossible to run.
- Instability. This database decides to corrupt itself about twice a month, even on rock solid hardware.
- Support. Expensive and useless. I tried contacting them about their fsync issue, and how to get our backup to run within a 24hr window. They couldn't help me. So after we created a
"Another customer sent us this patch to speed up backups, you might want to give it a try"
I sent you the patch, Idiot.
The list goes on, but in short, stay away from Arkeia if you have more than about 10 servers to backup. We attempted 75 servers and 1 terrabyte of data per full backup, but it just can't handle it.