In the ancient past, backup strategies were all about setting up a list of tapes, and determining which ones should be used when for full backups, incremental backups, and such, with some evaluation of how quickly tapes degrade such that they need to be turfed out.
That perspective is not "obsolete," but what with disk drives getting cheap and big vastly faster than tape drives, it is common for people not to even have tape drives, thus dictating different approaches.
Note that RAID is neither a backup strategy nor a substitute for a backup strategy.
RAID may make it less likely that you will need to resort to recovering from a backup. But it is not a backup system.
Similarly, journalling filesystems do not represent a backup strategy.
Again, they make it less likely that you will need to recover a filesystem from a backup; their primary advantage is in speeding up boot time when the system is shut down uncleanly.
Some journalling filesystems (typically on "commercial Unixes ) may provide links to help you mirror filesystem contents, which very well may represent a useful part of a backup system.
But the fact that you're using a journalling filesystem does not relieve the need to backup important data.
One approach to doing backups is to synchronize filesystems across a network.
Some good ideas may be gotten from the management of synchronization of PDAs like the PalmComputing platform.
Relational databases tend to require specialized handling; they typically store many records in a single file, and if the database is not shut down while a backup is being performed, the backup can easily be made totally worthless.
Database systems often offer some custom backup scheme whereby a program is run that generates a special backup output format in a "safe" manner.
There may be little sense in backing up software on /usr that may readily be "recovered" by reinstalling packages from an installation CD-ROM.
As a result, a useful approach to a "backup regime" may include pulling data from an RPM or dpkg database and not bothering to backup those files that are totally managed by the packaging system.
In addition to that, it may be useful to collect together the specific RPM RPM or dpkg files that get installed and collect those together to make your own "package install" CD. This is likely to be fairly compact, as packages are compressed, and means that if you have combined some custom packages with "distribution base" packages with third party packages, all reside in one convenient spot.
These days, most of my "backups" are handled via "Source Code Management", specifically via having my files of interest stored in Section 1 repositories, which are more or less regularly pushed and pulled to other hosts.
Tape Archiving Using the Time Capsule File System
The purpose of this MIT project is to build a filing system to provide long term access to research data from older computer systems, particularly where technology changes mean that backup tapes from now-unavailable computer hardware are getting increasingly fragile.
The system they were particularly concerned about in the initial research was ITS; apparently there has been a lot of research data archived on the ITS systems at MIT.
Back In Time is a backup tool that works with Section 7 and Section 8 that is reminiscent of Apple's TimeVault backup system, that does backups via taking snapshots of specified sets of directories.
Restoring a Debian Box
First, save package information dpkg --get-selections * > /mnt/floppy/backup.pkg.lst
Then, to restore it:
Boot a minimal Debian system using root floppies
dpkg --set-selections < /mnt/floppy/backup.pkg.lst
apt-get update
apt-get dist-upgrade
apt-get upgrade
BackupPC is a high-performance, enterprise-grade system for backing up Linux and WinXX PCs and laptops to a server's disk. BackupPC is highly configurable and easy to install and maintain
Google Directory: Virtual Disk Drives
A number of companies offer "virtual disk drives," which essentially provide a way for you to upload a set of files to their site, providing a form of backup.
There were a lot of providers of this service in 2001; many went out of business. Some have survived: many no longer have 'free' offerings.
This should not be your only "line of defense," but it certainly is possible to push compressed, encrypted "tarballs" onto such servers and get a backup that is free, if not of particularly verifiable integrity.
I would strongly urge people using these systems to:
Make sure it's not the only backup.
Compress and encrypt your data using something like PGP before uploading it.
For the "free" offerings, the terms of service usually give the host the right to use your data however they wish to, so if you don't want them publishing your love letters, use strong crypto tools ;
Perhaps use a couple of them for a bit more redundancy.
The amount of data that may be uploaded often tends to be limited, so you surely won't be backing up your whole DVD collection.
I'd suggest building a backup script that takes some set of important files and makes an encrypted tarball, ready for uploading.
Sundry backup and system recovery products.
Interactively back up Linux and W95 machines to a Linux "backup server."
Integrated, configurable, proprietary crash recovery solution for Linux.