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?

Comments

Easy.

[torpor]

If you were forced off of tar, cpio and dump, what would you use as a replacement?

I'd use dd of course...

Re:Easy.

[Anonymous Coward]

Microlite Recover/Backup EDGE is really
good. I have used that for SCO and Linux.
It's got a fairly nice gui too for setting up stuff
and the cli interface is just as good,
you can even create a bootable DVD recovery cd
and rebuild your entire system (repartition and reinstall) from that.
Its not too expensive either.
http://www.microlite.com

Re:Easy.

[dasunt]

I was actually thinking, what happened to pax? Supports both cpio and tar formats, worked great last time I tried it.

taper

[I am Jack's username]

9 out of 10 tape monkeys prefer taper!

9 out of 10 network admins smack their tape monkeys when they forget about modprobe zftape after reboots.

Re:taper

[The Troll Catcher]

Why should you need to modprobe it at all? Don't you have it set up in /etc/modules to auto-install the module at boot?

Re:taper

[JayBat]

Ummm, "4gb" maximum? It's a toy, and the author doesn't know the difference between bytes and bits.

Re:taper

[Anonymous Coward]

yeah, my DDS-4 drive uses 20gb tapes. I guess this program can only write to 1/5 of a tape.

Re:taper

[Tracy Reed]

Every year or so I give taper another try and every time it segfaults on me. Even across different systems and tape drives. This has been going on since around 96 when I first tried it. I emailed the author and got a reply but he just couldn't reproduce it and I couldn't find anything in particular that caused it. I just have zero confidence that I will be able to restore a backup with it after all of the troubles. I currently use tar. I've heard good things about Mondo. Search freshmeat for it.

Snapshotting

[Froggie]

Do none of the decent filesystems have a snapshotting facility? That's the best solution to coherent backups...

Re:Snapshotting

[danamania]

This is exactly what I'd like to be doing on my system. I've had a couple of drive failures kill my web/mail server - due to my insistence on using hardware made the same time as the 68k it's installed on. It's a showpiece for ancient tech as much as a usable machine, and with only a single half-filled 700mb drive, It seems I'd be better served by a rather quick occasional snapshot of the system, rather than having a rebuilt drive ready before each failure. that'd be cool.

Re:Snapshotting

[Anonymous Coward]

Foundation Suite from Veritas Software allows for both filesystem and mirror based snapshots if that is the way you want to go.

They also offer two commercial backup products. Backup Exec runs on Windows systems but can back up Linux and Unix machines and NetBackup which can run on Linux.

Foundation Suite - http://www.veritas.com/products/category/ProductDe tail.jhtml;vrtsid=UZBC4XBXWAXMPQFIYBTCFEQ?productI d=foundation

dump on solaris...

[Polo]

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...

Re:dump on solaris...

[root 66]

FreeBSD 5.x has fs snapshot capabilities. See http://www.freebsd.org/releases/5.0R/relnotes-i386 .html#AEN1150 for more details.

Re:dump on solaris...

[AlexA]

Yes there is. It's called LVM. I've used its snapshot capabilities before on my Linux server, it's very nice.

Re:dump on solaris...

[Anonymous Coward]

But LVM does snapshots at the block device level, not file system like Solaris fssnap. The LVM HOWTO says the for XFS, you should "freeze" the file system (with xfs_freeze tool) before taking the snapshot, and unfreeze it afterwards (I guess this "freezing" is something like turning it into read-only mode for couple of seconds, but without unmounting it).

Does anyone have more information about this? What about other filesystems than XFS?

Re:dump on solaris...

[sql*kitten]

I found out that solaris has a very interesting command: fssnap

If you are using EMC Symmetrix storage, you can use the TimeFinder product to create a "Business Continuence Volume", or BCV. It deltas against your last backup (at the track level, not files or blocks), applies changes to a copy of the last backup to create a consistent image, then you can dump that to tape.

I wonder if there's something like this for linux...

So long as you have one host (Solaris, NT, whatever) to run the TimeFinder client on, you can use the Symmetrix to provide storage to as many Linux boxes as you want.

Re:dump on solaris...

[Anonymous Coward]

This is only required for XFS.

Re:dump on solaris...

[larien]

So do Netapp filers & IBM Sharks. It's not a unique feature (despite what the vendors would like you to believe), but it is damned useful.

One thing to beware: a lot of vendors ship the snapshot capabilities as an added cost option; if you intend to use it, make sure of your costings.

Re:dump on solaris...

[adolf]

Sounds remarkably similar to FreeBSD 5's snapshot feature. I've used it with dump, with good results.

I started wondering if there's something like this for Linux, but then realized that there's just way too many different filesystems to add the feature in any meaningful, practical way.

Re:dump on solaris...

[Polo]

Hey, you're right, and the wonderful LVM documentation even has a Recipe for performing the backup. I assume that since the snapshot is read-only, dump should work fine without the issues Linus mentioned.

The snapshot partition just has to contain enough space to hold the changes made to the original volume while the snapshot exists.

Re:dump on solaris...

[Anonymous Coward]

Here we are using a mirrored configuration for all our importants filesystems. Usually our backups are run on the mounted filesystem, with Legato's Networker (I'm still hoping that the upcoming version 7 of networker will be a little bit more userfriendly that the 6 precedents versions ;).

Occasionnally, we do an ufsdump to the tapes. To dump a coherent filesystem, we detach one of the mirror, from the metaset and ufsdump the offlined mirror.

As soon as the backup is done (ie waaaayyy too much hours laters) we reattach the mirror in the metaset and let DiskSuite doing the dirty work of resyncing the mirrors.

Re:dump on solaris...

[Roelof]

Sure, but the README clearly states that it is definitely alpha-test code and NOT yet ready for production use. (CVSup a week ago)

At the end it also gave an URL about snapshots and stuff, http://www.mckusick.com/softdep/

Anyway it is a two step approach. First you make a snapshot in the filesystem being snapshotted, then you can use dump to safeguard it.

Roelof (Rulof almost as in the reindeer ;)

Roll Your Own

[JimR]

I wrote my own (Perl) script, that copies all my "important" files (basically stuff in my home directory that can't be reconstructed by other means and all the system config files) to a new directory tree (using cpio) it then burns the copied tree to CD-RW and verifies the CD against the copied tree.

I operate a 4 disc system, so I always have the last four backups on CD and I keep the copied trees around (uncompressed) for as long as I have disk space. So far I've not needed the CDs (I store 2 of them offsite in case of disaster) but the copied filesystem trees have come in useful a couple of times.

The only drawback of this is it's not appropriate for backing up huge quantites of data (like lots of audio or video files) as the CD media is quite limited in size - but when rewritable holographic storage comes along I'll be able to just change my function that decides which files are "important".

Re:Roll Your Own

[chrestomanci]

I wrote my own (Perl) script, that copies all my "important" files (basically stuff in my home directory that can't be reconstructed by other means and all the system config files) to a new directory tree (using cpio) it then burns the copied tree to CD-RW and verifies the CD against the copied tree.

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.

Re:Roll Your Own

[JohnFluxx]

I do something similiar, but use rsync.
I rsync my entire drive to another drive.

Re:Roll Your Own

[ichimunki]

Agh. CD-R(W). For those of us who have a lot of, uh, "data" those just won't do. I'm not going to try and back up my mp3 collection on CD-RW... at 30gbs and growing that's just not feasible. The organization alone is a nightmare. Not to mention the time involved in burning all those CDs.

I've just bought me some removable IDE trays and some additional IDE HDs like these here. What I want to know is: besides `cp -a` from a mounted NFS share or `scp -r` is there a good way to do backups for other systems on my LAN? Any dangers in doing those things? I know they aren't efficient (so I'll be checking out rsync) and that they aren't a snapshot per se... but anything else I should be aware of?

Re:Roll Your Own

[Anonymous Coward]

tar -cpvf - | (ssh otherhost tar -xvpf -)

No good answer

[Yonder Way]

Amanda comes up a lot. They can't span tapes.

Veritas also comes up a lot. Aside from cost, did you know Veritas can't back up single files larger than 2GB in size on Linux clients?

On paper, BRU looks pretty darned good. I haven't yet put that theory into practice.

Re:No good answer

[nbvb]

That's not true, there *is* a good answer.

If you really, truly need your data, no matter what, go with Tivoli Storage Manager

http://www-3.ibm.com/software/tivoli/solutions/s to rage/

Sure, you have to pay for it, but it's really no more expensive than Veritas NetBackup, and certainly a better product!

Cross-platform (everything from Wintendo to OS/390, Solaris, Mac OS X, Linux ...)

TSM is more of a hierarchical storage manager than more "traditional" backup programs.... but with things like Portable Backup Sets and multiple storage pools, you can replicate your data for both onsite and offsite copies with minimum fuss (automated, even, with the Disaster Recovery Manager), so this way your data is _ALWAYS_ available!

TSM probably isn't for your home Linux user, but it's definitely a great product for the data center!

--NBVB

Re:No good answer

[TheFRC]

we use veritas netbackup, it's incredibly expensive, kludgy, and at it's base, uses tar.

i will admit, it does a good job using tar, and it's not prone to failure, but like you mentioned.

2GB on linux max. they said the "new version" will be better, blah blah blah.

i've also used BRU for what it's worth, and it sucks nads. hard nads. this was 2 years ago, but still. i'm angry and biased. :)

Re:No good answer

[tcopeland]

We use BRU on a couple Linux servers here; seems to work well. Backups are quick and restoring isn't too much of a pain...

Tom

Re:No good answer

[gr]

And Legato! Legato! It looks just swell! So far, anyway. (I'm not done playing.) Then there's SyncSort BackupExpress. Sync who? Yeah, so they start their daemons out of /etc/inittab... And there's always Schily tar (for when you finally wake up and notice that GNU tar's performance sucks balls).

BackupEDGE vs. Taper

[mindslip]

I think the 2 above are both excellent, Taper for the less demanding environment, BUpEdge for a system with multiple drives.

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 /var/squid) instead of just simply skipping that directory.

mindslip

HP Omniback

[Anonymous Coward]

This Slashdot user('s IT) is using HP Omniback and was happy to do it more than once.

Linux Software RAID

[Tux2000]

I plan to use Linux' Software RAID to mirror all my data to one or two harddisk in an exchangeable frame. A RAID restore took only two thirds of the time for a file-by-file copy on my old machine. It is already using two disks in a Software RAID mirror. So the next step is to threw in another disk, and make linux mirror the data to the third drive. Should run nicely in background.

Sure, this is a home solution, not a professional solution, but it should be simpler than fiddling with tapes that don't have enough capacity for all my data.

Re:Linux Software RAID

[Anonymous Coward]

A buggy kernel or bad DRAM can wipe out a software RAID in 10 microseconds flat. I've had bad RAM and had it eat the filesystem numerous times. And if you do your software raid on the same controller (basically you have to have two seperate PCI cards, don't just use the other channel on your IDE controller). You'll run the risk of a bad controller eating the system. Things get even worse if you use SCSI for software RAID (if you can believe that).

If you want a cheap/simple home backup solution have rsync or something copy the data over to a totally seperate machine, perhaps at a remote location. I've actually done this for semi-professional systems for backing up websites remotely. Of course if rsync fails you backup is broken, and if your master fails then you trash your backup data unless you monitor the health of the master or use a two-tier backup. (which is what I prefer, even if it uses a lot of disk space).

rsync

[Isomer]

we use rsync for backup over ssh onto another machine at a remote location. This works really well, especially if you do a cp with hardlinks each night. rsync will download just the changes since yesterday, and files that are the same just end up being hard links to the same data. This also makes restores reasonably trivial. (just ssh onto the backup machine, cd into the directory for the date you want, cd into the directory and grab the file -- done.)

Re:rsync

[Colitis]

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!

Re:rsync

[cei]

I second the use of rsync & ssh, at least for particular directories. (Also makes a handy replacement to FTP or CVS in a pinch... I used to devlop in BBEdit on my Mac OS X box and rsync the files to our RedHat server...)

Re:rsync

[GigsVT]

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.

Re:rsync

[Nathaniel]

I've been happy with daily rsync backups to a second local harddrive with the same partition setup (one rsync command per partiion, with the -a -x --delete flags).

This makes rebuilding the system fairly trivial if the first hard drive fails.

It also means I can recover from mistakes if I notice them the same day.

Re:rsync

[jwbozzy]

I also use rsync. I let it sync with a directory on my backup server, which in turn dumps to tape. I have 5 machines backing up to a single server this way.

Re:rsync

[dubl-u]

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!

Re:rsync

[mbyte]

if you use rsync, have a look at rdiff. It works similar to rsync, but can produce incremental "backups", i.e. it can have a master version of 2 weeks ago and 2 weeks full of diffs. You can restore any version from the diffs, which makes it very nice compared to rsync. rsync is good for basic desaster recovery and stupid users that "accidently" delete some folders, but rdiff can protect you from more subtile changes (do we still have that version from last week ? .. and no, media designers don't use cvs ;)

Re:rsync

[buttahead]

I do very much the same thing. I wrote a script that will do parallel rsyncs to pull backups off of any number of servers. You can find it here.

Making it parallel really cuts the time to complete down because much of rsync's time is spent doing checksumming, and not high traffic.

Re:rsync

[buttahead]

One note of concern:

having the on-line backup by using rsync is great... speedy to run, speedy to restore, and more reliable than tape. OTOH, you still need to backup to tapes, as someday the drive you rsync to is going to fail in a nasty way. please please please, run the rsynced files to tape once in a while!

Re:rsync

[dubl-u]

as someday the drive you rsync to is going to fail in a nasty way.

Oops! I should have mentioned that my backups are stored on RAID arrays, so I'm not worried about that. But even if I were backing up to a single disk, I probably wouldn't sweat it too much. My biggest reason for having the backups is catastrophe prevention. For that, even a single remote copy strikes me as better than local tapes.

Why not fix dump and/or Linux?

[Dahan]

Dump has been the standard Unix backup program for decades... I don't use Linux, but if I did, I'd consider it a bug that dump didn't work properly.

Seems to me that Linus (or another kernel hacker) should fix the ext2 race condition reported in that thread, rather than blithely dismiss the problem with, "dump was a stupid program in the first place."

Re:Why not fix dump and/or Linux?

[jmt9581]

It seems to me that somebody who actually wants to use the dump program on Linux should fix it.

On the other hand, is anyone who wants to take a dump on Linux likely to contribute good code?

Re:Why not fix dump and/or Linux?

[ferringb]

Read Linus's explanation of why this isn't viable- basically paraphrasing, the kernel (specifically vfs) tries to cache as much inode information in memory as possible to improve performance.

This isn't a bug on ext2 (or ext3 or all other supported fs's), this is a failing of how dump works.

Kludging the vfs to enable this older method of backup doesn't seem quite viable considering the performance benefits you get from the caching.

Re:Why not fix dump and/or Linux?

[Anonymous Coward]

I think the "filesystem maintanance interface" mentioned in the post is a good idea... It's been awhile, has anybody worked towards this since then? Somehow I doubt it...

Re:Why not fix dump and/or Linux?

[lobotomy]

Exactly! Anyone who thinks tar is a substitute for dump has never actually had to restore user files. Tar works fine when the user actually remembers the exact path and filename. Most of the time, they don't remember exactly. That is where the interactive option of restore comes in handy. You can cd around until you find what it is they actually wanted.

Dump is broken and needs to be fixed. Anything less than that is not acceptable!

I have to go now and put another 10 110GB tapes in my tape changer.

Re:Why not fix dump and/or Linux?

[kasperd]

Tar works fine when the user actually remembers the exact path and filename.

It shouldn't be any major problem to build indexes over your tar files. What Linus argues that dump does incorrectly and tar does correctly is the reading of the filesystem. The way to read a live filesystem is through the filesystem API, not by blockwise reading of the device. All your arguments against tar and in favor of dump is about the output produced by the program. If you want output like dump produces it, then write a tool to read the filesystem in the way tar does and write output in the way dump does.

Re:Why not fix dump and/or Linux?

[that _evil _gleek]

Dump is supposed to be better than say: dd if=/dev/hda1 bs=1k | gzip -9 > rootfs.dd.gz , because you can do it while the system is mounted rw. What it takes to implement that is like making an incrementel fsck, debugfs, tar, gzip all it one; it becomes, more and more difficult as the filesystem becomes more and more complex. And I'd venture, it's more than simply proportionally more difficult.
UNIX filesystem was once simple: Superblock, Inode blocks, Datablocks in that order on the disk, now its not.
For myself, I either use tar, cpio, sometimes lharc, or I umount or remount readonly and use dd, which provided I have the diskspace I can use mount -loop to browse. Something like -loopbz on a bz2 file, or some new blockcompessor maybe based on the blocksize of the filesystem would be good.

Actually, was the dump of a rw filesystem ever 100% guaranteed usable?
I remember using dump on sunos...about 10 years ago, and ocassionally
it simply could not read a few directories or files, and that was taken as simply part as choosing to use dump that way....

Disk ARchive

[DancingSword]

DAR's what I use:

only 25 blank CD-R's to backup my home dir

*cough*

( yeah, OK, so I should stop trying different distros and settle on one, or two, .. alright, three, then, and I'd be able to wipe all that stuff I keep for installing-from-disk, but .. Oh, Later. )

rsync

[heikkile]

We have a dedicated backup machine, into which we rsync all the important stuff. We are a smallish shop, so it only has a couple of 120G disks.

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.

cdrtools

[Masa]

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.

Amanda

[martin]

www.amanda.org

nice - can use tar or dump as the back end system. Works on *nix/ MaxOSX/windows via samba or cygwin.

cdbkup

[bLanark]

cdbkup is a little more sophisticated - multiple levels, multiple disks.

"CDBKUP is a professional-grade open-source package for backing up filesystems onto CD-Rs or CD-RWs."

Snapshots

[bartjan]

Just use your favorite volume managment system to create a snapshot of whatever volume you would like to backup and use dump, tar or whatever to write that snapshot to tape. This way you'll have a consistent backup of the filesystem.

I'm using LVM as a wrapper around Amanda to create and remove snapshots of every filesystem I'd like to backup.

Amanda!

[nathanh]

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.

Re:Amanda!

[larien]

Other downsides:

• No support for spanning tapes with a dump; i.e. if you need to dump 4GB on a 2GB and you can't compress it down, you're stuffed.
• Restoring files is fiddly

Yup, Amanda is great for small setups (I use it myself at home) but it lacks certain features to make it really usable. For example, I had to restore some files in Legato Networker; I was able to open up a GUI, navigate to the file and set the restore path (i.e. where it will restore to). With that done, it worked out which tapes the file was on and restored.

Re:Amanda!

[riffraff]

Yes, and with amanda I was able to open up the command line client, navigate to the file and set the restore path. With that done, it worked out which tapes the file was on and restored.

Amanda does the same thing, it's no problem. Yes, spanning tapes is a problem, but people might be working on it now. You can get around it by just backing up files, or directories, under the filesystem, in increments that are less than the tape size. I use it at a couple of different work locations, and it has worked really well.

Re:Amanda!

[Fafhrd]

Amanda is a great package! However, it's only a backup manager; it still needs dump and tar (and uses them automatically) to generate the backups before sending them to tape or the holding disk.

When I set up an Amanda environment a few jobs back, the place had Linux and FreeBSD servers; the FreeBSD servers used dump, and the Linux servers used tar, and it all worked like charm. However, the Linux backups were a lot slower, because of tar; if I had to do it again, I'd probably use SGI xfs on the Linux servers, as it has xfsdump, a working version of dump.

the real question..

[Spudley]

To dump dump, or not to dump dump. That is the question.

Easy.

[Anonymous Coward]

If you were forced off of tar, cpio and dump, what would you use as a replacement?

I'd cvs of course.

Easy.

[Anonymous Coward]

From time to time i burn CD's using follow-symbolic-links from a dir with symbolic links to all important files and directories.

The rest is the default distro installation anyways.

afbackup

[Vairon]

Website URL: http://sourceforge.net/projects/afbackup/
Features:

• Server & Client programs
• Supports multiple clients streaming backups at the same time
• Webmin module for easy configuration
• Support for many tape drives and autoloaders
• SSL and DES encryption support
• Remote or local start of backups
• Compatible with most *NIX systems (personally used it with Linux, Solaris & FreeBSD)
• Non-root users can restore their own files
• Unlike AMANDA:afbackup can actually append to tapes

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. html

Re:afbackup

[martin]

amanda doesn't append to tapes so there is not possibility of blowing away that tape. This is a problem I've experienced with other commercial software that appends to a tape each run - tape write error and it marks the entire tape bad. which means you have to scrap the entire entire tape and start again.

Also tisk of appending is loss of tape or drive due to environmental factors - fire/flood (plane being driven into data centre).

Re:afbackup

[Vairon]

It would seem like this itself would cause more wear on the tape. It's my understanding that the hardest thing on tapes is rewinding them. Everytime it runs into the beginning or the end of the tape it "pulls" at the tape. Which is why smart tape backup units slow down the speed of the drive as they near the beginning or the end, during a rewind. If your backup program causes a rewind every-single-day, that would seem (IMO) to cause more ware.

In addition, unless you own a autoloader/robot unit, using a backup program that makes you change tapes every day would cost you more money due to having a person there to change tapes 7 days out of the week. The only alternative is to allow your backup program to overwrite the previous day's backup, which sort of defeats the purpose of having a backup on the weekend.

Re:afbackup

[AlexA]

If you overwrite the previous day's backup, what happens if the server crashes and loses all its data while the backup is in progress? It seems to me that you'd lose up to a week's worth of data if you switch tapes once a week, unless you actually append data to the end of the tape instead of overwriting it. But, as mentioned in the link you posted, appending data to the end of the tape isn't all so great either, plus you increase the chances of running out of tape, in which case you have to switch tapes anyway.

Re:afbackup

[mwr]

So, if you want backups every day, you must have a tape for every day.

Sure, but it doesn't have to be a unique tape each day. Since amanda normally uses a holding area to spool to tape rather than spooling directly from the source directories, I just back up the holding area daily (to tapes HOLDING001 or HOLDING002), and when either of my two holding tapes almost fill up, I flush the holding disk to another tape set (DAILY001, DAILY002, etc).

Sometimes a single daily tape might end up holding 10 days worth of backups.

Arkeia

[Khopesh]

Arkeia is a powerful one, but not free software. there are two versions, a free one for small offices and a more powerful costly one. ...quick browse of the site does not reveal the free version, i don't think it exists anymore for 5.x (maybe i am not recalling correctly).

anyway, arkeia can back up windows, linux, unix, and mac osx.

Re:Arkeia

[GoRK]

I second the Arkeia vote!

It's proprietary software, but has proven exceedingly reliable for backing up my entire network onto a tape library. Basically, it's cheap for what it does, and depending on how you use it -- it may be available at no cost.

~GoRK

Re:Arkeia

[SpaFF]

You can get a restricted demo license key for the full version of Arkeia if you email their sales people.

I evaluated this product and really liked it. I would be using it now except that I found out our Windows guy was using Veritas and had already had it paid for, so I installed the free Veritas Linux clients and pawned the backup job off on him ;)

Re:Arkeia

[nottestuser]

Actually the single server, 2 client version is availible in 5.0 for free. They've got a quite nice statement about why they're giving it away on their site too. Basically they appreciate everything hobbists have done so they're giving their work back gratis.

We use it at our office to backup the /home partition of our development server and it works flawlessly. I've never tried to restore an actual bootable system partition with it though. I just reinstall, match up the RPM list, and restore the config files.

Re:Arkeia

[Anonymous Coward]

Arkeia is alright if your backing up a small amount of data/servers (10?).

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 .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:

"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.

Re:Arkeia

[pbaker]

- 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!!

It hasn't behaved this way in my experience. I have installed the client on more machines than I have licenses for and they show up in the navigator, you just can't navigate their file system or add them to your savepacks. Existing backups are unaffected.

- 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.

It would seem to me that you have poorly configured machines. Every machine on your network should report something unique when you run hostname. If they don't, I would blame your network administrator, not Arkeia for the problem.

- 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

I am backing up 3 machines making up over 60GB of data and I don't run into any inode problems on the ext2 partition which happens to be the / partition for the machine. Perhaps you allocated too few number of inodes when you formatted your partition.

Also I don't seem to have the speed problems you complain of. We have several machines acting as backup servers ranging in power from P2-500 to Dual P3-866 all backing up between 40-60GB. None take more than 3 hours to do a full backup. What media are you backup up too and how much data are you backing up?

Re:Arkeia

[Anonymous Coward]

- "It would seem to me that you have poorly configured machines. Every machine on your network should report something unique when you run hostname. If they don't, I would blame your network administrator, not Arkeia for the problem."

We offer backup services to our customers who colocate with us. Therefore we do not administer there boxes, or even have access to them. Regardless, if we have two servers, www.domain1.com and www.domain2.com, Arkeia by default tries to strip off the domain, and call them both "www". Your trying to tell me this is a network administrator problem? You can get around this by following Arkeia's FAQ, but you need access to the clients, (which we don't have) and its a very manual process.

- "I am backing up 3 machines making up over 60GB of data and I don't run into any inode problems on the ext2 partition which happens to be the / partition for the machine. Perhaps you allocated too few number of inodes when you formatted your partition.

Also I don't seem to have the speed problems you complain of. We have several machines acting as backup servers ranging in power from P2-500 to Dual P3-866 all backing up between 40-60GB. None take more than 3 hours to do a full backup. What media are you backup up too and how much data are you backing up?"

The amount of data actually isn't the problem, its the amount of files/directories. Since we're a web hosting company, we have _many_ files, on very few servers:

"19190834" files, "963046" MB, compressed at "1.4", "105829" seconds, "433" MB/mn

This is what kills Arkeia. A single server with 900Gb in 100 files wouldn't be a problem at all, and would backup much, much faster.

We have 3 Sony AIT2 tape drives, two of which we use for backups, running at the same time. However they are much faster then Arkeia, as you can see from the above, Arkeia can only handle about 433MB/mn.

Arkeia's text "database" uses over 600,000 files just for one of our servers. We have about 10 servers in that range. So how many inodes do you have available? 6million? Even with 512byte inodes, you do the calculations and let me know when you find a drive that big.

Re:Arkeia

[murashkin]

Arkeia can not verify tapes after a backup. Some time ago they had on their web site a statement that "real" people did not backup to a tape drive without hardware verify support (read head after write head). If you think that such a drive will keep you safe, think again. It works until the drive is broken (read head broken, more specifically). I had bad expirience with Arkeia and VXA-1 drive. I ran backups sucessfully for a long time. As soon as I tried to restore deleted data it failed. After some hardware diagnostic I found the read head on VXA-1 was defective.

Then your computer catches fire...

[Anonymous Coward]

...and your RAID backup seems kind of comical.

Kinda like that "Offsite backup? Yeah, it's in the other tower!" .sig that's floating around...

Re:Then your computer catches fire...

[Anonymous Coward]

When he said RAID in an exchangeable frame ... I think he meant using hot-swappable drives.

Plug a drive in ... let raid mirror data. Unplug the drive and store the drive in a safe location.

Not sure HDDs are the best for continual physical transport - but a RAID mirror would backup data rather quickly (compared to tape).

Mondo/Mindi

[Strike]

Not really my cup of tea, but for the home user I hear Mondo Rescue mentioned a lot as a good solution (for backing things up to CD-R(W) for example, though I think it handles most typical backup media). But that's not to say that it's not for "big iron" users as well, as their "About" page states:

Mondo is reliable. It backs up your GNU/Linux server or workstation to tape, CD-R, CD-RW or NFS partition. In the event of catastrophic data loss, you will be able to restore all of your data [or as much as you want], from bare metal if necessary. Mondo is in use by Nortel Networks, Siemens, HP (US and France), IBM, NASA's JPL, dozens of smaller companies, and tens of thousands of users.

It seemed very nice when I tried it, but I just don't think I had the patience to set it up properly. Definitely worth a shot.

Re:Mondo/Mindi

[Anonymous Coward]

Except for taking about 16 hours to backup and verify the 800/900 mhz workstation machines to CD, I _DID_ have Mondo working. Now there seems to be some Red Hat glibc "thing" that the author "can't do anything about." I _guess_ that is the problem from their sparse words. I was using up2date regularly as rpms came up and Mondo just quit working from one backup to the next. No log errors and no upgrading or hours of twiddling seem to do anything.

Looking into mkcdrec.

Re:Mondo/Mindi

[ka6wke]

I wouldn't use Mondo/Mindi to back up an entire system, but the ability to restore the OS, partitions, and regular backup software on a bootable CD is a great idea. Just boot, follow the screens, and go with it. Once all the partitions rebuilt, system is up and running, then you could use your other backup software to restore data, user files, etc.

I'm fighting that right now with Arkeia. If the backup server takes a dive, you will be in a world of hurt, even if you have the on-disk dbtree saved somewhere. No matter what, that on-disk dbtree will always be out of sync with the backup on tape. You'll have to read the tape via arkrstrdb to rebuild the dbtree from all the files on the tape. If for some reason you can't use the Arkeia gui, you'll have to rely on readarkeia to dump the contents of the tape to disk. The problem with this is, all the rights/permissions will be whatever user runs the readarkeia.

I'm taking this from the trenches, on a system with 1TB of data. It's been a royal pain with Arkeia these last few days. The thoughts of a two pass backup system shows promise. The steroid based Arkeia to handle all the other servers in my mixed environment, and Monda/Mindi to handle quick recovery of *nix boxes, then finish restoring with Arkeia..

Re:Mondo/Mindi

[Medieval_Thinker]

I have been really pleased with the Mondo/Mindi combo. It has worked well for me.

You can create an image of a machine and restore it to a test machine for development. Literally you can boot with the CD, type "nuke" and come back in 15 minutes.

When you want to move an image to a production machine, you create a disk, and type "interactive" at the boot prompt. You can change partition sizes, file system types, etc. When you boot the new machine, it finds the new HW, and you are ready to roll.

YMMV of course, and I have installations small enough to fit on a single CD with compression. All my systems are based on RH 7.2 or RH 7.3.

The mailing list is a great source of help.

BRU

[vasqzr]

It's not free, but that's probably why it's only been mentioned once so far.

BRU

Re:BRU

[Anonymous Coward]

works like a champ & multi-platform, too!

We've used it for stand-alone backups of important systems, although we use other tools (Legato Networker) for network/oracle backups.

mysqlhotcopy, samba, tar, gzip, scp

[polyphemus-blinder]

I don't use tapes because I hate them. Granted in order not to use them, you need lots of spare hard drives, which I do.

First, I use mysqlhotcopy to get all sql data. Then, my backup server uses samba to tar and gzip up all data from various servers, Windows and Linux, into one place. Then it uses scp to send it all across the WAN to another backup server which keeps a business week rotation, and one month rotation. The other site does the same, and so far no problems at all.

This way you don't have to *hope* that your tapes aren't corrupt and jump through ugly hoops to retrieve your data. I would *not* recommend bzip, however; too damn slow and processor intensive, even with a dedicated backup server. Simply not scalable.

Re:mysqlhotcopy, samba, tar, gzip, scp

[Wolfrider]

> I would *not* recommend bzip, however; too damn slow and processor intensive, even with a dedicated backup server. Simply not scalable.

--I'll second that. bzip2 gives good compression, but ' gzip -9 ' does it FASTER.

Not Free, but does work nicely.

[Neck_of_the_Woods]

Veritas Bare Metal Restore 4.5

Works for windows and Unix(AIX, Solaris, HP-Ux) but I don't see support for Linux but I would guess that if you can get it to work on the above there is a tweak to get it working.

Just anouther option, I know it is not going to be the flavor of the month because it is not free or OSS.

Enjoy,

Backup2L

[JLester]

We use the backup2l script from Sourceforge to backup about a dozen servers each night to a remote NAS server. It keeps multiple generations (not sure how many, but we can restore files from several months or even years later) and has worked great for us. It is tar based, but that hasn't caused any problems and we're backing up about 150 gigs with it.

Jason

Question on restoring .bxf files.

[compwizrd]

On topic, but adrift at sea a bit:

what tools will restore a backup done with Windows 2000/XP under Linux?

Under win95/win98, you can smbtar the entire remote drive into a compressed tarball. To restore, fdisk a new drive, format it, and tar -xjpf tarball.tar.bz2, and possibly sys C: it once it's back in the windows machine. Windows takes care of anything else that needs to be done.

Under Win2000/XP, obviously this won't work, so you need to use Windows's backup or other tools. But if you want to restore a file that a user deleted, you need to find a windows machine(difficult if you're not onsite), and restore the file using windows backup.

Under the Win95/98 method, just untar the backup, and copy it back to the client's pc while they continue to work on other things.

Re:Question on restoring .bxf files.

[toast0]

i dont' see why you can't do the same thing with win2k/xp?

you can connect to win2k/xp with smb just as easily as win95/98

what is the problem?

Re:Question on restoring .bxf files.

[compwizrd]

Because when you restore the files, how are you going to maintain security permissions, how are you going to do the sys c: equivalent, and how are you going to make sure it's bootable?

W2k/XP filesystems are far more complicated than Win95/98.

Even if you stayed with FAT32 on the W2k/XP system, you still have to figure out a method to get around the different method of booting and file layout.

With win95/98, the filesystem is so simple, and the system files are trivial to create, if nothing else, format C:/u/us from a bootdisk gets the disk ready to have the files restored.

The whole point of the central backup server is that I can restore any lost file in about 2 minutes, and restore an entire computer in about 10 minutes, in the event of a complete system failure. Can't do that with Win2000/XP, I have to install 2000/xP on a new disk, reinstall all the apps, and then copy all the data files back from the backup.

If i used the windows backup, I could restore a system back to full operation, but that won't let me dig out individual damaged files without having a windows machine (vmware/wine?)
Too much work.

Re:Question on restoring .bxf files.

[toast0]

for the sys c: equivilent, go to a recovery console, and do fixmbr ...

you're still stuck w/ the permissions thing, maybe you can convince tar to store permissions info, and use one of the ntfs's thats writable from linux to restore. Depending on your available network resources, you might consider having the user directores be remoately mounted (for ease of backup), so then you would only need to restore the os and installed programs if the hard drive fails.

I cannot be forced off tar

[mnmn]

They say tar has its limitations. I really dont understand.

Ive worked with different unixen and Linux distros, so I just dont want to be dependant on something that isnt installed by default everywhere. tar already has a VERY well known format and execution parameters.

Ive lost my fair share of data to buggy harddrives and dumb mistakes like pulling off the ide cable while the system is running. So cron does daily backups using tar cfj using a file that has a list of other files to be backed up. This way I dont have to backup the whole partition. To restore a certain file, just tar xvfj backup2.tar.bz2 /pathtofile --root=/

The cron setup renames backup.bz2 to backup2.bz2 and removes backup2.bz2 so I have the data for the past two days. Beside incremental backup which I dont need due to this setup, what else could I need? And by the way the backup.bz2 is copied off onto an NFS share elsewhere incase my whole RAID setup crashes, or the XFS filesystem bombs out. This setup can be replicated onto FreeBSD Solaris and many others.

Re:I cannot be forced off tar

[cdrudge]

I beleive that there are two downfalls to tar. One was long file name support. I think I read once it was long file names and the other was backing up devices in the /dev/ directory. I don't know if either of these are currently an issue with recent versions.

Also, if tar encounters a bad spot on a tape, it usually bombs out. cpio can be told to skip over the bad sector.

There are advantages and disadvantages to all the backup programs. I don't think that there is one program that is "perfect" for everyone. If you are only going to backup a data directory, then tar will probably work fine. If you want to do the whole system, I'd go with cpio or a commercial backup program like BackupExec or Lone-Tar.

Re:I cannot be forced off tar

[mcelrath]

The horrible problem with linux right now though is that because the memory management is so braindead, that backup will swap out everything in memory in favor of caching your multi-gigabyte backup file. Thus your method brings the machine to a standstill while the backup is occuring (which can take hours to days depending on the size of your filesystem).

Not a criticism of your method (in fact, I use this), just a rant that the Linux MM system NEEDS TO BE FIXED. I'm sick of watching as some trivial process that will only read or write once gets the whole filesystem cached for it while programs I'm using interactively get swapped to disk. Video recording and playing programs (mplayer, ogle) have the same problem.

Let's hope 2.6 is better than 2.4. Can any kernel hackers comment on this? In 2.5 will tar cvjf /home /mnt/backup/home.tar.bz2 bring my system to its knees?

-- Bob

Re:I cannot be forced off tar

[Hubert_Shrump]

as a temporary and ugly solution - why not just nice the jobs you don't want hogging the system?

Re:I cannot be forced off tar

[Harik]

To demonstrate his complete stupidity, Hubert_Shrump writes:

as a temporary and ugly solution - why not just nice the jobs you don't want hogging the system?

Perhaps because the NICE level dosn't impact anything but CPU timeshare? So a nice 19 tar -czvf /tmp/totape.tgz /home will still thrash the hell out of your system.

The semantics are fairly trivial: This process is generating a lot of disk cache that's only being hit once, so let's bound how much memory it uses.

The reality is much trickier. It's not an intractable problem, though.

Not too long ago (early 2.4) mke2fs would completely devistate a system when the filesystem/ram ratio was above a certain point. (I'm thinking 8gig FS on a 128 meg box, but it's been a while)

Installs were DOG SLOW due to the massive dirty-writes going on. It's much much better now, so hopefully the 2.5 VM dev cycle takes care of the read-once page problem.

--Dan

Re:I cannot be forced off tar

[mcelrath]

It is not CPU usage that hogs the system, it is disk I/O. tar (for a large file) forces all running programs onto disk, so that all memory is being used as a cache for this huge file. Then whenever you try to do something with an interactive program it must swap the entire thing back into memory. It then stays in memory for about 5s until tar provides some more memory pressure and puts it back on disk.

It is the constant swapping-in and swapping-out that make the system unusable. Nice has absolutely no effect on this.

-- Bob

Re:I cannot be forced off tar

[Anonymous Coward]

I used to run BSD/OS systems, so I cut my teeth on dump. Now I run Slackware, and these developments with dump forced me to look for alternatives.

I tried tar. It was horribly slow. Try timing a dump, then time a tar. Use the same hardware, filesystems, CPU load, and so on. tar was 5 or 6 times slower for me.

I found something called star ("S tar" - after the author's name) that is essentially tar, but it implements a FIFO. It basically goes out and keeps the buffer full so the tape drive streams continuously. GNU tar wasn't able to do that for me.

The best part is that star runs just about as fast as dump, even though it has to run through the filesystem like any other program. It's not a great solution like being able to take a snapshot, but it's better than nothing.

Re:I cannot be forced off tar

[mnmn]

Umm, I use 2.5 myself and I dont know if the 50MB file brings it down. Its a pentium200 with 64MB ram, 256mb swap, and all backups occur at 4am. I remember testing it some time ago I think it finished the job clean while on the same lousy system I was running X and reading hotmail email using opera and twm. Maybe because its 2.5...

Re:I cannot be forced off tar

[dubl-u]

It seems reasonable, but AFAIK nice only helps when the issue is CPU contention. When your problem is related to IO (e.g., seeking, caching, or transfer) then nice doesn't help.

Re:I cannot be forced off tar

[Hubert_Shrump]

Thanks for clearing that up.

Thinking like a bonehead, indeed. I got all focussed on keeping your interactivity up... and probably never finished the manpage to nice in the first place.

Hey, good thing I phrased that as a question, so that I'd get an intelligent answer as to why, rather than get my ass flamed off.

Off to blithely trash my system because I'm too retarded to boot it without pouring hot coffee in the power supply vents.

Re:I cannot be forced off tar

[arvindn]

This problem happens even during updatedb (locate's database). Perhaps there is a way of specifying the maximum number of memory pages that can be used for caching disk blocks?

Re:I cannot be forced off tar

[Sloppy]

It's a good intuitive idea, though. Wouldn't it be nice, if niced processes had their VM and data cached on their behalf, treated as "less important" than other processes'?

Re:I cannot be forced off tar

[Anonymous Coward]

> I beleive that there are two downfalls to tar. One was long file name support. I think I read once it was long file names and the other was backing up devices in the /dev/ directory. I don't know if either of these are currently an issue with recent versions.

I can't say about the long filename issue, but /dev files do get handled correctly by the tar shipped with Linux systems.

CD's and harddisks

[tsa]

I use mkisofs and cdrecord to copy all my data to a CD-RW. I have two of those; the oldest data gets overwritten. At work I use cp to copy all data to an extra harddisk that is removed after the copy is made. And I keep my backup for home at work and vice-versa. Very important in case your building burns down.

Re:CD's and harddisks

[coyote-san]

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?

Use dump.

[TilJ]

Just because it's broken on Linux doesn't mean that:

* it's not better on other platforms
* the other tools aren't worse

Elizabeth Zwicky's classic Torture-testing Backup and Archive Programs will give a whole list of reasons why you should be suspicious of tar or cpio.

Heck, the FreeBSD Handbook answers the question "Which backup program is best?" by saying "dump(8). Period."

mkisofs OR cp -ax

[redelm]

Very simple. Big stuff gets backed up with cp -ax across NFS to other disks. I have never liked tape -- restores are dicey.

Small, important or irretrievable stuff gets mkisofs [even -J!] to CD-R.

Lonetar and rsync

[bzant]

I use Lonetar locally to tape and rsync/ssh over DSL to my house, works great, I have not had to go to a tape for months to recover a file, just ssh into my home server and copy to the office network. I have saved many an ass this way. But I leave the tape running just to have a couple layers of bckup. We are also adding a new office in another city, I will rsync/ssh to that location too.

Re:Lonetar and rsync

[lobotomy]

Great! Now tell me how I can back up 12000 GB to my home over DSL? Some of us work at places with multiple users and real data. Doing an rsync to my house is just not an option. Face it: dump must be fixed!

Re:Lonetar and rsync

[cymen]

If you have "real data" why don't you have something like a netapp or a tape silo?

Re:Lonetar and rsync

[lobotomy]

Why don't we use netapp or a tape silo? That's easy -- cost. I looked into getting a Network Appliance filer about two years ago. A 500GB demo unit (i.e. used) would have cost us $80000. Sorry, but a university department cannot afford that. We now have 18 TB of disk storage on Linux systems and a 10-tape SDLT changer for less than the cost of a netapp filer.

I don't have the capacity to back up all 18TB, but we do take care of the most critical data. How much of that could I back up over DSL to my house? A few GB at most? That just is not very feasible.

Re:Lonetar and rsync

[Anonymous Coward]

why ur house? if ur a uni why not just across campus - still off site

Re:Lonetar and rsync

[cymen]

You'd be able to backup 33Gb (128k/sec inbound limit), 66Gb (256k/sec inbound limit), etc... Definately not feasible for you but in the original posters defense, they never claimed it would work for everyone.

After mulling this over for a bit I'm sitting here thinking that ISPs should go into the backup market if they can work it to their advantage by keeping the backup traffic within their network and increasing subscriber speeds to the backup systems. Realistically everyone seems to still be on the outsource kick so it would be implemented in some inefficient and nonsensical manner.

In regards to your problem--shouldn't the school itself look at purchasing some large backup system and share the costs among other departments that will buy in? Or is administration screwed up enough to make such things not happen? Here is an interesting tape silo page at tamu.edu:
http://sc.tamu.edu/emass/EMASSFlier.html

Re:Lonetar and rsync

[Anonymous Coward]

>Sorry, but a university department cannot afford that. [$80k]

You're kidding me, right?

$10k * 3000 students = $30,000,000 tax free. And that's a really tiny university, or a large department.

$80,000 invested in a backup solution that should be good for about 5 years costs $16,000 a year using straight line depreciation.

That's .0533% of your total university fees. Or, that's $5 per student. Here's an idea: Tell the students that there is a $10 per year fee if they want their data backed up. Then you'll end up with a surplus, assuming the majority of the students want their work backed up (I would assume so).

Adjust the figure as necessary to work with your department. Better yet, stop the whole "departments" thing with the computers and do what my college does: Leave it to computer services. A $250,000 massive robotic tape changer is cheap compared to 20 departments buying $80,000 "cheapie" units, and will be a hell of a lot more flexible, _and_ take much less manpower to run.

Try star by J�rg Schilling

[Corporate Gadfly]

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

Hotswap IDE

[N8w8]

For backing up my FreeBSD home server I use a second (identical) HDD in a swappable IDE bracket on a standard plain ole onboard IDE controller (the 2nd channel to be precise). Though hotswapping isn't really supported on these controllers, it does seem to work :)

Making a backup is easy. I just plug in the bracket and start a homebrew script which:
- enables and inits the hotswap IDE channel
- mounts the partitions on the hotswap HDD
- removes system immutable flags on files on the hotswap HDD (so that they can be overwritten)
- copies over all new files (/sbin, /home, just everything) to the hotswap HDD, using the "ssync" tool
- resets the system immutable flags to their original state
- umounts the partitions
- disables the IDE channel
- logs the above to /var/log/backup
- mails the log to me

A whole backup takes about 25 minutes on an almost full 30GB disk in a P200 (it only copies the new/changed files), and compared to tape it's very cheap. If the master drive fails, I swap HDDs and the whole server works again, without any configuration whatsoever.

Re:Hotswap IDE

[Anonymous Coward]

I'd thought about this too, but for my money, I prefer a firewire card ($10, near my place), a firewire cable ($2, likewise), a few IDE sleds ($3 ea, again), and a couple 5.25'' external firewire enclosures to accept the sleds (~$70, ebay).

Fast, portable, and I can stick any bare IDE drive in a $3 sled and make it effectively a firewire drive for saves or restores, or sneakernet.

dump isn't broken

[Anonymous Coward]

dump isn't broken; Linux is broken.

The question of how to perform backups on linux remains perfectly valid, of course, but recognizing where the problem lies makes other solutions more obvious.

BackupPC

[dissy]

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.

Re:BackupPC

[agw]

If you only use online disk space for backup. Where do you get your backup from, when all the online disk space is accidently deleted or destroyed?

Re:BackupPC

[dissy]

I dont think i understand your question.

If a machine's disk is distroyed, i restore from the backup server.
If the backup server failed, the machines it backsup are still there with their data.

All of the systems are RAID, so it would take an abnormal amount of disks to fail all at once (Over 60% of the disks accrost atleast two machines) to actually lose data.

I dont think anything will be happening to cause that, which also wouldnt distroy your tapes or whatever other medium you use for backups...

We rolled our own...

[MrIcee]

Part of my job is maintaining game servers as well as servers for web hosts and web clients. We wanted to keep 'mirrored' servers that reflected twice a day any changes that might occur in the live servers. We tried a number of commercial products and found that all of them lacked - mainly, they were hogs and would drive system load up to the point where I felt uncomfortable. So we buckled down and designed our own system which we call "MakeItSo". A daemon runs on the server to be backed up to, and a client is launched by CRON on the server which we wish to backup. A config file instructs the client as well as the server what directories can be backed up, and allows filtering of filenames and directories (e.g., we don't necessairly want to back up server logs, etc). When a new directory is added the client provides a checksum and a signature to the daemon. The next backup will only send files which have changed (incremental backup). We use 'gzip' to compress the file and transmit it.

MakeItSo has a very small footprint (daemon is about 1.4 meg) and it spikes load about .5 while running - very tollerable (some of the commercial packages were spiking load over 4.0!! we use SUN servers). The nice thing is that because we wrote it ourselves (all C) we can tweak it and do just about anything we wish to improve it's performance.

Re:We rolled our own...

[Anonymous Coward]

Sounds like what you wanted was "rsync".

Re:We rolled our own...

[MrIcee]

we tried rsync... didn't like what it did to load. though i do like to roll my own for just about everything since it removes the 'blackbox' factor and puts it totally under my control

Re:We rolled our own...

[georgewad]

> we tried rsync... didn't like what it did to load.
This might help, it's one of my favorite things about rsync
--bwlimit=KBPS limit I/O bandwidth, KBytes per second

Re:We rolled our own...

[Anonymous Coward]

ever heard of nice ?

LoneTar...

[cymen]

We use LoneTar at a couple of different clients. Not much to dislike except slow file restore seeks on tape but apparently this has been fixed within the last year.

TSM

[duffbeer703]

Tivoli Storage Manager is the only "backup solution" that I have ever seen that truly works well without alot of tweaking and twiddling.

I've worked at places using Legato and Amanda, where restoring from backup was an unreliable and error-prone process more likely to be a waste of time than anything else.

TSM is not cheap, but is worth every penny. We have one full time and one part time employee handle the backup/restore jobs for about 2000 servers. Try that with Legato or Amanda.

Re:TSM

[beaner]

Perhaps you can clear up a possible misconception of mine here --

I've always been under the impression that TSM essentially does one full backup for each system, and from that point all backups all incremental. Meaning that performing a full restore involves touching many, many tapes. If this is truly the case, I don't see how TSM can even be considered anything close to a real enterprise backup solution..

Re:TSM

[jayspec462]

It's true, yes, but how often do you do full restores? The vast majority of restores we get (and I'm sure this isn't unique to TSM) is "I just screwed up this one file, can you get it for me?"

If you do have a server that you think you'll want to do a full restore on, then do a GENERATE BACKUPSET and you'll have all the data in one place, on the media of your choice. Yank that media offsite and you won't even need to touch the TSM server to get the data back. You can also do data colocation, if you have the tapes and the drives to burn. It depends if you want to optimize backups or restores. TSM gives you that flexibility.

TSM is a tough nut to crack, but once you do, the power is amazing.

Yosemite tapeware

[michelg]

We use tapeware here, simply because it's what came with the tape drive and it supports network backups from windows machines to the backup server running on linux. It has a curses, X11 and windows interfaces that are all quite similar (X11 and win32 interfaces being identical). I was wondering if anyone else uses this software and what your comments are on it.

Re:Yosemite tapeware

[murashkin]

Tapeware 6.3 (and NovaStor NovaNet 8.5 that is exactly the same product) does not restore special files (devices, fifo, sockets, etc) under Linux. You can not use it to backup/restore whole machine. Pathnames are shown as \a\b\c\d. It does not display file type (regular, symbolic link, etc).

The dangers of backing up live systems

[mpechner]

Dump isn't the problem. It is the fact that you are bakcup of a live system. Short of running everyone on a raid 1, cutting the mirrors, backing up the mirror,and reconnecting, UNIX file systems are not meant to be backed up while in use.

Companies with money can get a netapp box for critical data. Here you can absolutly use dump, tar or cpio. They create a "snapshot" of a file before backing it up.

Unfortunately we are talking a minimum of $40k for this type of solution.

If the snapshot comcept could be written into ext4, then dumps would be great.

I always put a caveat into my backup policies to cover this issue.

Anybody out there know if Bru does any better?

Veritas have a work arund to this?

Amanda is just a wrapper around dump.

Re:The dangers of backing up live systems

[mph]

Unfortunately we are talking a minimum of $40k for this type of solution.

In FreeBSD 5.0, you can dump(8) a snapshot. I'm not sure if we're using snapshot in exactly the same way, but the point is that you're backing up a static "picture" of the filesystem, while the real filesystem can still be used read/write.

The best part is the FreeBSD costs considerably less than $40k.

Re:The dangers of backing up live systems

[mpechner]

You are absolutely right.

I was not away that this was in 5.0. I spend my time in Linux. I need to make a bigger commitment to BSD. It seem to be a jump ahead of linux most of the time.

Re:The dangers of backing up live systems

[TheLink]

I heard Linux LVM does snapshots too. So FreeBSD is actually behind Linux in this.

Re:The dangers of backing up live systems

[afidel]

For significantly less than $40K you can get Veritas file system and do snapshot's =) VFS is available for every platform under the sun (all commercial Unice's, Linux, VMS, S/390, Windows, etc). Of course even if you have snapshots you still need a backup program, my personal best experience is with Veritas's Netbackup product, restores are easy and straightforward, and the command line makes for easy scripting =)

Re:The dangers of backing up live systems

[drift factor]

I heard Linux LVM does snapshots too. So FreeBSD is actually behind Linux in this.

This is a prime example of what's wrong with slashdot today. Whoever modded this up is a fucking idiot. Let's break it down:

You heard linux LVM does snapshots. So basically, you have no idea. Shot in the dark. I don't know why you used your karma bonus on such an obvious gem of wisdom. But hey, you were right at least.

"So FreeBSD is actually behind Linux in this." I like how you made an assumption, and then stated a fact based on that. Karmaworthy indeed. The thing is, YOU'RE WRONG. But nevermind that, I knew you were an idiot already.

What really bothers me is, I know I'm not the only who followed this exact same train of thought, but here two days later I'm the only one replying to smack this guy down. So instead of the majority of people who read this then remembering the real facts, they're going to remember what this guy said and probably go around quoting it in a smug manner thinking they're oh-so-leet.

Until they meet me, and I kill them.

Re:The dangers of backing up live systems

[TheLink]

So where's your proof that FreeBSD filesystem snapshots came before (or exact same time as) Linux filesystem snapshots?

You say I'm wrong and point to a document that shows FreeBSD 5.0 has filesystem snapshots, and you call me an idiot.

Pax itself...

[runswithd6s]

Although S tar is a nice utility, as mentioned by previous posters. You can get pax directly from the OpenBSD people. Debian also packages pax, if you run Linux.

Re:Timefinder on EMC

[phamlen]

At our dotCom company, we bought EMC boxes and I was REALLY excited about the TimeFinder concept. But then I found out that it doesn't really find time, it just makes backups.

I had thought we had found the answer to getting a six-month project done in 3 months - use "TimeFinder" by EMC. :)

-Peter

Backup Exec

[digerata]

We use Backup Exec coupled with a StorageTek L80 (tape robot). This is reponsible for doing nightly backups of between 3-6 TBs of data on Novell and Linux boxes.

For linux we create a SMB share with samba that the backup server has access to. All files are either tar-gzip'd or just copied over to the directory. Everything in the directory is backed-up.

tar does not do incremental backups

[wotevah]

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.

Re:tar does not do incremental backups

[dissy]

> 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.

Re:tar does not do incremental backups

[wotevah]

Heh, you're right, GNU tar does do that...

But, seriously. If you back up Gb of data and millions of files with tar periodically, I bow to you. Don't get me wrong, I like this tool (I happen to use it every day), it's just that the incremental backup support you mentioned is fairly primitive (it almost always needs custom helper scripts) and not at all adequate at that scale.

tar lacks things related to data management, which I kind of expect when it comes to periodic backup software. An example is file archival history and tape mapping, without which you'd have to search scores of tapes sequentially to find all the versions of a given file (yeah you can store the index somewhere else and cut and grep at it but somehow that does not seem all that exciting).

Also, for incremental backups running for hours (or continuously!), you need to know the actual time a file has been backed up as opposed to when you started or stopped the entire process to determine whether the file needs a new backup or not.

Re:tar does not do incremental backups

[Just Some Guy]

tar lacks things related to data management, which I kind of expect when it comes to periodic backup software.

I wouldn't want to use tar (or dump, for that matter) as a stand-alone backup program. However, tar makes a great backend to Amanda, and Amanda takes care of all of your indexing needs automatically.

Linux is about the only...

[devphil]

...major OS that doesn't have some kind of filesystem-snapshot support.

And this, more than any marketspeak CTO buzzwords, is what prevents Linux's entry into really mainstream server usage. Every sysadmin senior enough to make the decision of "do we use Linux for " knows that backing up a live filesystem is simply stupid. Right now -- and for the foreseeable future, since nobody seems to be working on it -- you have to unmount a filesystem and then use a program that speaks raw devices. And there went your 24/7 customer uptime.

(The alternative solution is usually something like "run a mirrored RAID, then take one of the mirrors offline, back it up, and bring it back online." That only works when the RAID implementation isn't constantly being rewritten between every kernel release.)

Re:Linux is about the only...

[toast0]

if you're looking for 24/7 customer uptime, why are you updating to every kernel release?

Unless the new kernel offers something you or your customers need; theres no need.

Re:Linux is about the only...

[nathanh]

Linux is about the only... major OS that doesn't have some kind of filesystem-snapshot support.

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:

When running ufsdump, the file system must be inactive; otherwise, the output of ufsdump may be inconsistent and restoring files correctly may be impossible.

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.

Re:Linux is about the only...

[Anonymous Coward]

"Linux is about the only... major OS that doesn't have some kind of filesystem-snapshot support."

"You do realise that dump doesn't give you a filesystem snapshot ... "

This person never said dump was a filesystem snapshot. He said fssnap was a filesystem snapshot.

Re:Linux is about the only...

[nathanh]

Oh, fair enough. The question mentioned the dumping of dump so I misunderstood. He's still wrong though.

Re:Linux is about the only...

[Anonymous Coward]

Because many of the kernel releases fix major security flaws.

Re:Linux is about the only...

[toast0]

looking at debian's security alert list, they've had no more than one security update to the kernel in a year. I wouldn't run a linux server that needs to be stable on anything but debian stable. I'm not about to look through the last several years of kernel security issues and see if they just didn't lead to a security update in debian, but I'm willing to bet that the slow uptake of kernels in debian means most of the security issues in a given kernel version are caught before that version enters stable.

Re:Linux is about the only...

[Anonymous Coward]

Blah blah blah -- has nothing to do with the RAID format changing (if in fact it does).

Napster is my backup...

[anthony_dipierro]

I don't really have all that much on my home computer that I couldn't afford to lose. I use IMAP for email, so that's stored in two places already. I use CVS for software I right, so that's backed up too. The very few commercial programs I've bought I have CDs for. Same thing with the mp3s I have (plus I do back those up to a separate hard drive every once in a while using handy dandy cp -R). Any passwords or receipts I've saved would be lost, but I could get the passwords back by filling out lost password requests, and hopefully the receipts wouldn't be necessary. I see no reason to back up my entire drive, because 99% of it is already backed up in one way or another.

ARCserve, unfortunately

[Anonymous Coward]

subject says it all :-( ARCserve sucks!

Re:ARCserve, unfortunately

[FreeLinux]

Agreed, and yet Arcserve is still the best all-round backup solution for small to mid-sized systems. Arcserve backs up and restores several Unixes including Linux, Windows Netware and who knows what else. It has excellent scheduling and tape management as well as options(sold separately) for open files, databases including MS Exchange, disaster recovery, virus scanning, automated tape libraries and more.

For large scale systems Legato would be my choice but, the cost of Legato rules it out for anything but the largest setups.

Take a look at Arkeia

[sobiloff]

Yes, Arkeia is commercial, but sometimes you get what you pay for. Arkeia has a decent UI (but you can do everything from the command prompt, too), and it can backup just about any flavor of UNIX (including OS X) and Windows. It works with any SCSI tape device, including tape libraries. It embraces the standard full/incremental backup paradigm, so its pretty straight-forward to migrate to Arkeia from dump, etc. It has features that expedite disaster recovery (full-box rebuild), and can do on-line backups of MySQL, Oracle, PostgreSQL, DB2, etc.

Note that Arkeia offers a free Linux version if you only need to backup the local machine and a couple of clients--perfect for the SOHO user.

And, no, I don't work for them--I just used the software for a couple of years when I was responsible for a tiny server farm. Arkeia always worked, unlike some of the tempermental WinNT boxes I had to support...

Problems...

[hafree]

The problem with most suggestions here is that it seems the average slashdot reader is a linux hobbyist or works as the IT manager for a small office that happens to run linux. What happens when you need to backup 6TB/night and don't want to pay someone to sit around swapping tapes all night. Sometimes it just isn't practical to purchase another SAN solution to facilitate an rsync. Or what if you have a collection of high capacity LTO tape drives at your disposal, but don't have the budget for something larger and automated, or smaller with an autoloader. I think automation and efficiency is almost as important as reliability and cost. Not everyone can afford a Storagetek Powderhorn Silo, or needs the versatility of expensive products such as Veritas Netbackup. Then again, sometimes tar or rsync just don't cut it in an enterprise environment where data is mission critical.

Re:Problems...

[jbolden]

Well if its data then most likely its in a database and the database backup is what is mission critical. Things like Oracle have excellent live backup solutions where you are effectively backed up every 3 seconds.

Re:Problems...

[Anonymous Coward]

My shop uses AFS - www.openafs.org - for a central filesystem; you can create RO and backup images of your data, which are dumped to tape (or disk if you prefer).

OpenSource, so you can see what's in it, and server and client are available for most popular *nix's, including Linux.

Enjoy.

I've got my own set of scripts

[vadim_t]

First, I have a Perl file list maker. I make a file, say "stuff.conf":

#!/usr/bin/perl -w
use Backup;

add_path("/home/vadim");
del_path("/ho me/vadim/.kde");

There are other functions to filter the files to add, and it can also include other files. If running as root it will switch to the user that owns the included file, and not allow including any files not owned by the file's owner. I use this to let people with an account on my system configure how their stuff gets backed up.

This simply generates a file list that's piped to afio. I generate many small afio files, one per home folder for example. Then another Perl script takes those files and figures out how to distribute them so that the CDs are as full as possible (currently takes 2).

Finally, a bash script that runs from cron calls xmessage to make windows pop up requesting me to insert CD-RWs. It marks CDs, so that if I insert the wrong CD-RW I get a warning. Once this is set, it all happens automatically, I only need to insert the CD when it asks for it.

It doesn't do incremental backups, but I don't need them for now. If anybody is interested in this stuff I could try to make a few changes to make it more customizable and upload it somewhere.

Re:I've got my own set of scripts

[drake50]

I'd be very interested in the script that lumps all of the backup file together so that they can be burned.

Currently I have a script to do backups that pipes into split. It works great but when everything is finished I have to create various groups of files to be included on burned cds if their size is smaller than 700MB.

It would be nice to have a script organise the various files together in folders which max out at 700.

How can download the script?

Re:I've got my own set of scripts

[vadim_t]

I uploaded it here. The file you're looking for is 'makelist'.

If you have any suggestions or want to ask something about it, you can send a mail to vadim@(server name in that link)

Combination - CVS, rsync, afio

[muleboy]

I haven't found a single good solution. I use a combination approach:

For daily work, I use CVS. This is nice because I can access it at home or work or laptop, and backup is not needed if you don't care about revision history.

rsync over ssh

afio using bzip2 with 100k blocks. With tar -cz, if you have a single bad bit, the whole archive is bad. You're screwed. With the afio approach, you lose the file where the corruption occurred, and if you're lucky, you only lose the 100k block where the corruption occurred.

Incremental backups with rsync

[Bishop]

Rsync can also be used to make some very nice incremental "snapshot" backups.

rsync

[g4dget]

I do rsync to a dedicated backup server at a different location. As a fallback, I backup portions regularly to CD-ROM.

rsync

[Anonymous Coward]

I use rsync. my script then for offline backup I use BRU (*not* BRU pro but regular BRU). This backs the data up to my DAT.

quick way to lose files

[coyote-san]

That isn't reliable. ISO9660 directories can only have ~1024 entries, any more are dropped on the floor. There are also limitations on the length of a filename with Rock Ridge extensions, possibly 32 characters.

Then there's the other things that don't translate well. Do you deference symbolic links? What about fifos and special devices?

If you want to be safe, you need to either check the directory tree first or put everything into a container without these restrictions. I've been developing some tools for this, but keep flipping back and forth between compressed tar files and zipfiles. The former can be read with standard tools, but requires an explicit index (for performance when seeking single files) and doesn't scale to multiple discs. The latter has an index and supports multiple discs, but isn't widely used in the Unix world.

Re:quick way to lose files

[Wolfrider]

> I've been developing some tools for this, but keep flipping back and forth between compressed tar files and zipfiles. The former can be read with standard tools, but requires an explicit index (for performance when seeking single files) and doesn't scale to multiple discs. The latter has an index and supports multiple discs, but isn't widely used in the Unix world.

--You should check out Joerg Schily's "star" program (he's the author of the fabulous and immortal cdrecord.)

ftp://ftp.berlios.de/pub/star/

http://www.fokus.gmd.de/research/cc/glone/employ ee s/joerg.schilling/private/cdrecord.html

Taper limitations

[Webmoth]

Taper has a limitation in that the archive can not be greater than 4GB. If larger, it will appear to write OK, but it'll segfault when you go to try and read the archive.

Wrong: EVMS

[Vairon]

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.

Good coding practices

[coyote-san]

A lot of the problems backing up live systems are because of poor coding practices. (The other problem is people attempting to back up things that shouldn't be backed up at the filesystem level. A classic example of this is relational databases - they should usually be dumped and restored with their own tools.)

Specifically, how many programmers routinely get advisory write locks on files they plan to update? How many home-brewed or ad-hoc backup solutions bother to get advisory read locks?

I've written some backup utilities that do the open()/flock()/mmap() dance, and while it's mildly annoying to get a couple error messages per run, I greatly prefer having no file to having a corrupted one in the archive.

Arcserve is okay ...

[zonix]

ARCserve sucks!

Well, at work I use Arcserve to backup files from some Red Hat servers via the Unix agent. While I'm not jumping up and down and waving my hands, this solution works, it's easy to setup and it's not that expensive, actually.

Another note. Arcserve used to crash my NetWare servers time and again, but so far the Unix agent has been running without problems on Red Hat 7.3 - at least for me. :-)

z

Re:Use dump and lose data

[coyote-san]

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.

Symantec Ghost or VMWare

[RevRagnarok]

I have two identically sized drives (80GB). Every weekend, I take down the machine for about an hour and Ghost disk 1 to disk 2 (60GB used takes 50 minutes). Then I hide disk 2 in the BIOS (disable the controller). An EXACT backup of the OS. People ask why I don't just do RAID - well, I trust the hardware not to fail more than myself - if I f* it up, with RAID, yippee I have to copies of crap.

Another option I did in the past is to have a very basic host OS and a virtual machine with all the important stuff. You take down the virtual machine, copy the file that is its "hard drive" to somewhere else, and boot it back up. Now you can split that file across CD-R, move to another PC, etc. This solution is also very nice if you have catastrophic failure, you can recover much faster with new hardware and not worry about the right drivers, etc, because your important system always has the same peripherals - the VM ones. Kernel just boots right up.

- RR

Re:Symantec Ghost or VMWare

[Anonymous Coward]

I have two identically sized drives (80GB). Every weekend, I take down the machine for about an hour and Ghost disk 1 to disk 2 (60GB used takes 50 minutes). Then I hide disk 2 in the BIOS (disable the controller). An EXACT backup of the OS. People ask why I don't just do RAID - well, I trust the hardware not to fail more than myself - if I f* it up, with RAID, yippee I have to copies of crap.

And then your house burns down, or the machine is stolen, or lightning strikes (you keep the disk connected to the power supply???) and yippee - you have copies of nothing.

Tapes are horrible, but the main reason to use them (or DVDs) is that they can easily be moved to your work/home/second building/fireproof safe.

My Solution

[BlueSkyResearch]

Prayerware(TM)2.0 http://www.prayerware.com/

You mean the old ADSM

[HBI]

ADSM Rocks.

God, I love this backup system. I've used it in three different places for various cross-platform backups.

Novell, NT/2k, Unices, etc etc. It just works. Of course, to truly use it right, you need a huge tape library. Huge = 5000 tapes, at one bank I was at. We had one in Manhattan and one in Jersey and a 100mbps link between. We'd backup to Jersey at night for instant disaster recovery preparation, and copy back to NYC during the day. We were even setting up a third automated tape library in Brooklyn for added redundancy.

ADSM client configs were a pain until you understood the software. It ISN'T a backup program like you are thinking. It's really a snapshot storage system, with configurable numbers of file copies kept in buffer, we had it set to 5 unique copies of each file. You can restore snapshots based on file dates, which is a nice feature, though you'd need to extend it beyond 5 copies to really gain the benefit.

Loved the stuff. Wish I could get it back - using crappy Veritas here.

Strongly recommended, the parent poster hit it on the head.

Yes! rsync!

[metamatic]

Yes, rsync is the dog's.

On the Mac, I use RsyncX, which knows about resource forks, even when transferring them to systems which don't have them.

And on Windows, I use rsync again.

I've tried every damn sync program for the Mac. I've tried tar and dump on UNIX. I've tried fancy network backup tools. I've not found anything that compares with rsync.

I hate the complexity of the command-line syntax, but it has the required functionality:

1. Automatically incremental.
2. Works locally from disk to disk or across a network.
3. Works via secure VPN or SSH.
4. Works between any two platforms I happen to be using, so I can back up to wherever the spare disk space is.
5. Easily scriptable, easily scheduled.
6. More efficient at using network bandwidth than any other protocol I've found.
7. Doesn't fail over on systems with incorrect system clocks or bad timestamps.
8. Data ends up in original native format, not some format that needs a special program to read.
9. Partial restore is trivial.
10. Works great with large capacity but slow-to-write backup media like DVD-RAM.
11. It has never damaged my data.

The only downside I've noticed is that the rsync ports to Windows tend to be comparatively CPU-intensive for some reason. Turning off compression helps.

I also use rsync for maintaining my web site, sharing my iCal calendar, syncing my browser bookmarks...

Moderators on drugs again?

[Anonymous Coward]

Standard tar does *not* support incremental backups. Look at page 127 of O'Reilly's _Unix_Backup_&_Recovery_. Are you claiming that Curtis Preston doesn't know what he's talking about? I guess O'Reilly's technical editors don't either. Also, the Posix standard says they don't. I guess you're also going to claim they're all wrong.

Just because you have some tar that someone jammed a cheap hack into, doesn't mean that tar supports incremental backup. Hey, the world doesn't revolve around you kid. Get over it.

Hey moderators, thanks yet again for making slashdot a little less useful to clueful people.

Re:Moderators on drugs again?

[david duncan scott]

Well, it looks like GNU jammed on that cheap hack around 1997. Maybe there's a case to be made for updating.

While we're at it, President Clinton is out of office now, Puff Daddy has changed his name two or three times, and the Florida Marlins are no longer the World Champions.

Who would take it away from me? And where do I ...

[digital photo]

Before I start looking for new backup tools, I would look for the one responsible for removing my tools in the first place.

A possible(read: theoretical) form of backup would be to use the various online search engines as distributed backup mediums. Ie, convert your data into various web pages which are encoded. Since webcrawlers will crawl a site and attempt to store/cache te data(google, the wayback machine, etc), your data is, in theory, cached on those crawler databases.

The only problem with this idea is the fact that you can't really determine the time and place of the backup. Only hope that they cache it in a reasonable way. ;)

The corollary of that would be to encode it as DNS with LONG LONG expire times so that people can serve your domain and by extension your data.

Seriously though, the utilities mentioned in the original post represents functions which, after a fashion and some long hours tinkering, could be simulated so that you can perform your backups in a half-way reasonable way. (Read: custom code your own backup tool)

There is, of course, the good old tried and true backup a hard drive with another hard drive... but that get's a wee bit expensive and hard when you start talking terabytes of data...

Backups under Ninnle

[Anonymous Coward]

Why use taper or tar or whatever? Ninnle, as usual, comes with an excellent backup package: Ninnle Backup, of course!

Backup Express

[StevisF]

I use Backup Express made by SyncSort. I've been pretty happy with it overall. It's designed with very large libraries in mind though, which can be semi-annoying if you don't have a very large library, like me. You have to define media before the backup begins, i.e. if you put in blank tape, the software won't automatically use the tape if the software needs a blank tape. You have to define each tape to be in a certain media pool. If you have a very large library, you'd define everything once and let it go at it. It's not a major inconvenience, but it is my one complaint.

It has most of the features of more expensive packages for quite a bit less money. They have good, responsive tech support, with technicians you can actually understand, unlike some other companies, *cough* CA. They also offer a demo period, a month or more, when you have an unrestricted copy of the software and full access to their technical support staff, so you can get a good idea if it will work for you.

For our environment, 15 Windows clients, 5 Solaris clients, 3 Linux clients, a 2 drive 14 slot library, and a 1 drive 10 slot library, including a year of support and upgrades for about $18,000.

Snapshot-Style Backups with Linux and Rsync

[Anonymous Coward]

Snapshot-Style Backups with Linux and Rsync:

This document describes a method for generating automatic rotating "snapshot"-style backups on a Unix-based system, with specific examples drawn from the author's GNU/Linux experience. Snapshot backups are a feature of some high-end industrial file servers; they create the illusion of multiple full (up to ownership/permission) backups per day without the space or processing overhead. All of the snapshots are read-only, and are accessible directly by users as special system directories. It is often possible to store several hours, days, and even weeks' worth of snapshots with slightly more than 2x storage. This method, while not as space-efficient as some of the proprietary technologies (which, using special copy-on-write filesystems, can operate on slightly more than 1x storage), makes use of only standard file utilities and the common rsync program, which is installed by default on most Linux distributions. Properly configured, the method can also protect against hard disk failure, root compromises, or even back up a network of heterogeneous desktops automatically.

Single user mode

[rf0]

I've always been taught that if you want to have a reliable backup of your OS do it in single user mode (if possible, although normally not really practicle). For real world backup one nice way I found of doing a *full* backup is the following, Some might say it is risky but it does works

Have a backend storage system which has redundancy. Say two NetApps that replicate each other. When you want to do you backup of data take one of the machines out of the cluster so that there is no I/O. Back it up using your favourite software. (Amanda, Veritas, dd, cpio,tar...). Put it back in the cluster and let it sync up and there you go.

Now I would like a beowolf of those :)

Rus

Samba and Backup Exec here...

[KC7GR]

What I did, since Amanda doesn't have very good robotic library support, was to set up our NT server with an old version of Backup Exec (it was available used, from another company that upgraded, and it was cheap). Then I added a surplus Exabyte 8mm library (an EXB210, if I recall correctly) that I got for about $50 at the local used computer place.

Next, I installed Samba on our NetBSD boxes, set up the shares and permissions, and viola! Centralized backup with minimal hassle and cost.

Granted, this was done with older software and surplus components. While the exact hardware, and specific backup software I used may not be suitable for "enterprise" environments, the same principle applies. Samba is a lot more useful than I think some folks give it credit for. Thank you, Andrew Tridgell!

Arkeia, but what about Bacula

[Anonymous Coward]

We're currently using the free Arkeia version as we have all stuff mirrored on one machine (rsync).
I recently looked at Bacula (www.bacula.org), it looks promising I think, I'm curious why nobody mentioned it sofar.

Re:Arkeia, but what about Bacula

[motasinc]

I have been using Bacula for a month or two now with a couple of Linux boxes and 2 Windows XP machines as clients. I find it to be an excellent open-source alternative to the higher end systems from companies like Seagate and Adstar. The support is excellent as well :) Bacula is still a work in progress, but the author so far appears to be very interested in making this product a viable option for large scale backup and the current release is certainly stable enough for everyday use.

Our Two Linux Boxes...

[eric2hill]

...run RedHat and integrate into our enterprise backup solution with the Linux client agent for ARCServe.

Unfortunately it's not free, but it didn't change our corporate licence by hardly anything.

FTP is my prefered backup utility.

[t-maxx cowboy]

I primarily use FTP (enter favorite ftp software here) to backup data to another system. Though I have not broken down and automated it through scripting/cron. If I need a permanent storage type of backup, then off to CD the items go.

I've used several.

[kcurrie]

At my (large) company we are Veritas Netbackup which works well.

At home until recently I had been using one of those rsync/hard link backup systems with good results (links to that quoted here elsewhere).
I'd been looking for a somewhat simple solution that I could run on a low end linux box at my kids school to backup 1 linux box and 1 NT server. After a bunch searching I finally settled on flexbackup because it is fairly simple, and can use tar in incremental mode, emulating dump's levels. Since I'm just using tar and bzip2, restores can be done just on a Windows box. I have it backup the NT box by using the smbfs to mount it, and then have the backups stored compressed on another harddisk. After the backups are complete, the system uses (http://www.gnupg.org) to encrypt a copy of the files, and puts them in a "pickup" directory. After that, the system sends a signal to a couple of home boxes via http/syslog, upon which the home boxes use rsync to copy those files down over peoples cable modems.
While this solution is obviously only useful for small amounts of data (the downloading to home part), it does allow for secure offsite backups, and even the home backup machines cannot decrypt the data because they don't have the required private key.
The home backup box doesn't have any access to the school server other than the ability to do rsync's, as I'm using a ssh/rsync "forced-command" setup, so even if the home boxes are rooted they cannot get back into the school.

I've started using flexbackup on my home network as well, and it works great, although I wish it had the ability to push the tar files across a SSH connection (it CAN run dump/etc over SSH, but I just want tar backups of files dumped over the ssh connection).

I hadn't see backuppc yet though, and it looks pretty good, and looks like it could easily work in a small replicated environment.

Re:Use dump and lose data

[Anonymous Coward]

Ah Linux, the home of the extended 2 filesystem. The filesystem which still insists that you should fsck it every few reboots or days, whichever comes first. That inspires confidence!

But really, Write Caching is evil, and that's been known for some time. Why is it still an issue for Linux? How can you expect a backup to contain data that the drive doesn't even contain yet? Seems unreasonable to me.

Linux for 24x7 ...

[Anonymous Coward]

Very true - anyone truly competent is running a commercial 24x7 Linux shop using a logical volume manager and doing disk mirroring (RAID) of some sort. A capability such as filesystem snapshot is great - although for performance reasons you'd be best off putting the snapshot image on a disk using a different controller than the filesystem disk you are taking a snapshot of .... Alternatively you could even mirror the filesystem and then split the mirror for backup. Each has its own trade-offs.

(BTW, IBM appears to have discontinued their Linux LVM project - the Sistina Linux LVM is the best way to go. This Linux LVM is quite similar in commands/functionality as the HP-UX LVM. In fact, full-featured LVMs for Linux have been around longer than similar capabilities on Solaris ...)

We use bu

[vince1]

Bu has served us well over the last several years. It is a
filesystem to filesystem backup tool that we normally use to
backup to an NFS server over the network, and it can back up
to multi-volume CDRW's. Although, the CDRW dump feature is
not finished for Linux yet, the rest of the features work on
both Linux and FreeBSD. It is designed for immediate
backups of individual files or directories throughout the
work day as well as full or incremental backups via cron.
It is very configurable, light weight, has include and
exclude lists, nice log files, good documentation, and is
free under the GNU public license.

Re:We use bu

[vince1]

Sorry, It looks like I forgot to post the home page for bu.

The bu home page is at
http://www.hightek.org/bu

Um, no, you missed my point.

[devphil]

I'm not claiming that dump provides the snapshot. The sequence goes like this:

1. Create a snapshot.
2. Dump the unchanging snapshot
3. Release the snapshot

Of course you don't dump a live filesystem. It's just stupid.

Moderators, this person was not informative, they were simply missing the point.

Linus' own backup method

[Anonymous Coward]

"Backups are for wimps. Real men upload their data to an FTP site and have everyone else mirror it."

I'll consider this Linus' guarantee to me that ftp(1) will always work under Linux ...

I vote for ftp over dump, in this case.

spanning tapes (Re:No good answer)

[Anonymous Coward]

If you want to do multi-volume check out Bacula (Google for it).

Tapeware!

[millwood]

Tapeware- for Linux, anyway. Dunno about other Unices.

Re: use a CD like a tape

[greed]

Of course, you don't have to put ISOs on CDs:

tar cf /tmp/backup.tar /whatever && cdrecord /tmp/backup.tar

Then you need to tar x /dev/scd0 or whatever to restore, which under UNIX shouldn't count as special tools.

Re:Use dump and lose data

[Anonymous Coward]

> Ah Linux, the home of the extended 2 filesystem. The filesystem which still insists that you should fsck it every few reboots or days, whichever comes first. That inspires confidence!

Google is your friend: "linux journalling filesystem".

Scripts to back up MP3 collection to CD-R?

[BigBlockMopar]

Before I write my own and reinvent the wheel, does anyone know of any scripts which will create ISO image files of an MP3 collection?

Here's what I want to do. On my home LAN (as opposed to work, where we've already got a good backup strategy), I've got a large (20Gb) MP3 collection. I back up everything else with a little shell script, and that's good enough.

But the MP3 collection is hard to back up, and I've only ever done it twice because of the work involved. The technique thus far has been to simply dump 'em in sequential blocks by filename until I cannot add any more files before I exceed the CD's capacity. This is inefficient, of course, because if the next file is 5 megabytes and I've only got 4 megabytes left, then I go on to the next CD-R and preserve the order (so that I can still keep track of what files I've put in).

What I'd like to do is have a script which automatically sorts them so that I have efficient use of the CDs and tars each file individually to preserve the long filenames. (Why not tar all the files in the CD image? Damage to the CD might make that whole disc unreadable.) For the same reason, I'm not interested in disc spanning.

Of course, such a script would be useful anywhere that a large quantity of relatively big files have to be backed up to CD-R... or, even larger files have to be backed up to DVD.

Anyone know of anything like this, or am I rolling up my sleeves and kludging something together?

Linux does support snapshots

[Anonymous Coward]

If you use LVM (Logical Volume Manger) for your partitions you can use its built-in snapshot feature.

Arcserve

[Anonymous Coward]

Anyone use Arcserve(it)? I use it to backup multiple machines to a tape library off a server. Kind of a poor man's veritas from CA. It supports a lot of OSs through propietary agents or through network shares. It has nice restores, keeps a DB of backup information that you can query. The only problems I have with it are the cost is a ripoff, CA is a horrible company to deal with, and the software crashes and forgets device configurations regularly without reason.

Anyone else out there use it?