At 02:17 AM 29/01/2003 +0000, you wrote:
Dear Group,Basically there are three approaches to backing up a Redhat System (I don't consider things like RAID-1 or drbd since they really aren't designed to save you from data corruption or malicious users the way an off-line backup system will), each with their own pros and cons, and the backup-howto doesn't cover the half of it.
I have looked around for some nice backup scripts or console applications for my Redhat 7.3 system. There are some nice scripts around, but most of require a good amount of configuration (I'm looking for the easy way out!). I can't really understand some of the more complicated scripts enough to get through each step and figure it out myself.
1. Archive your files.
This is the "normal" backup approach. Basically you have the system online and you spider through your filesystem with some program that copies to an offline medium. Amanda is probably the most popular industrial-strength solution (it's a client-server based tape archiving program largely intended to backup multiple machines using a tape robot), but it's perfectly reasonably to just use tar or rsync. Rsync does less disk I/O, but it's rather limited in its backup options. With tar it's fairly easy to perform incremental backups (e.g. to a full backup once a month on cd(s) then make incremental updates (on a not-too-busy system these may fit on floppies) every day.
Pros: Dead easy.
Cons: If files are locked or being modified while the script is running (fairly probably if the script takes hours to run) they may not be backed up properly. Also, tar doesn't handle the entries in /dev properly. Recovery can get quite complicated.
2. Raw copy your block devices
This is the approach I normally use when I need to backup a machine before attempting to fix potentially serious filesystem corruption. The easiest way to do this is to boot a separate OS (e.g. a single-floppy Linux distro, a somewhat modified tomsrtbt works well) with access to some sufficiently large block device (e.g. a hard disk or tape drive) not in use by your "main" OS. At this point you can simply use dd (possibly combined with compression or a few other filters) to copy the raw contents of the hard drive.
Pros: Easiest possible restore.
Cons: System goes offline for a long time while backing up, backups are BIG (even with compression the size of the backup can easily be much larger than the amount of actual data stored on your hard drives, dd will backup the contents of empty space too. To be safe your backup medium should be as large as the media you are backing up).
3. Use LVM
This is Linux specific, and very slick if you get it working. The LVM provides a capability called a "snapshot" which allows you to make file system level backups (like #1) but eliminates most locking and file modification issues by having the kernel track all changes made to the filesystem being backed up, and provide copies of the original changes in an image file on another volume (which you access transparently when you read from the device created when you took the snapshot). A much clearer and more detailed explanation is at: http://www.tldp.org/HOWTO/LVM-HOWTO/snapshots_backup.html
LVM snapshots would typically be used in conjunction with something like tar or rsync to actually archive data from the snapshot.
Pros: Backup/Restore has the simplicity and compact backups of #1 and nearly the reliability of #2.
Cons: All filesystems you want to back up must be on LVM volumes. LVM is non-trivial to configure on an already running system (although I believe that recent versions of the Redhat installer allow you to configure LVM at install time. I don't know if your root filesystem can be LVM, but I suspect / can as long as /boot isn't and you have an initial ramdisk).
I would be especially interested in backup methods which have been well tested and are easy to implement. I'll probably do an rsync cron job or something to copy any backup files over the net to an off-site location once the backup .tgz or whatever files are generated from the script.Certainly amanda is the most well-tested method going. Implementing amanda can be fairly complex, and tape devices (especially good tape robots) can be very expensive (the last amanda backup server I was directly involved with cost about $500,000cad). It is probably also possible to configure amanda to backup to media other than tapes, but I've never tried.
Currently my personal preferred backup media is low-end IDE hard disks (for capacities in the 10GB to 1TB range they tend to be rather cheaper than a tape solution). And are easily made hot-pluggable with an external USB (cheap on ebay) or Firewire (less cheap) to ATAPI convertors. Currently IDE hard drives seem to be cheaper per MB than anything else if you're operating in the 10GB to 1TB size range.DVD-{RAM,RW,R} may be even cheaper, but I haven't seen a reasonably-priced large capacity disk changer for DVD yet, and I'm dubious about the reliability of the media (cd-rw was a bit of a disaster for me).
--
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe
https://listman.redhat.com/mailman/listinfo/redhat-list
