I need to organize automated backup for databases, websites, ftp, email, etc. at Ubuntu 9.04 and since I've never done it before, I'm looking for places to learn. What needs to be done, what (free) software I could use, tips&tricks, best practices and so on. If you could point me to relevant articles for beginners, I'd most appreciate that
There are many options out there depending on your goals, infrastructure, and media preferences.
First you'll probably need to figure out how to setup cron jobs no matter what solution you end up going with. It's what runs scheduled tasks on *nix.
As for the backup itself I tend to go with rsnapshot as it's simple enough to setup and does what I need. Amanda and Bacula are both great solutions but involve databases and other things which complicate the backup and recovery. I tend to avoid complicated things when I need something reliable such as in the case of backup. Rsnapshot uses rsync over ssh to transfer the data between systems so it's secure and efficient. It then uses hardlinks so that you have many point in time snapshots of the filesystem you're backing up.
Databases have to be treated a bit special b/c you either need to lock the tables while you're running your backup job or dump the database tables to another location where you then backup using what ever method you choose. This can be done with a tool like mysqldump if you're using MySQL. This dump is normally automated using a cron job.
Most folks I know use Bacula for this purpose.
They have pretty decent documentation, but here's an article that walks you through some basics.
Amanda is a centralised backup solution.
I'd say that your data is the important thing, to back up, use more than one means e.g. rsync to a remote box + cpio to a usb stick. Everything else can be rebuilt you can switch from ubuntu to Fedora and take your data with you, it just takes more work, you can never get back lost data so make doubly sure that you have the data covered.
Whatever you choose. Do some restores and get comfortable doing them. There is nothing worse than having to restore a system in the middle of the night and then finding out the hard way that you got something wrong and your backups are mince!
Backups are always hard to tune properly; especially because people have different needs, and such needs are usually a mix between data 'snapshot' backup, data archiving, server (config) backup, reliable service, etc).
3dinfluence and davey are both right: it's important to try the restore operation (as Joel says), and a set of cron scripts is usually the first things to do; but additional actions have to be done depending on how much data you can "accept to loose", and which level of reliability you need.
So the questions you have to ask yourself are:
Depending on the answer to those questions, you'll see if daily backups are enough, or if you need a warm standby server staying in a different geographical location.
I'm not guru at all on this field, but maybe my example can gives you some idea.
I'm managing a small (debian) server, providing databases (postgresql), subversion repositories, trac sites and some others similar functions; the server is mainly used by our R&D group, so few people (~20 clients for the subversion), and some instruments (~50 clients for the database), but they are working almost 24/24h, 7/7days (especially the instruments, which feed the database with measures).
In case of average issue (like main hardware failure), a downtime of 2 to 4 hours is acceptable (instruments can work locally for a while). So I didn't have (yet) warn standby server, but only a set of local and distant backup and dumps.
So the requirements are not drastic at all: about hundred gigs of data, and less than hundred clients to serve.
The first "line of defense" is provided by the disk redundancy and partitioning (which not only help in case of disk crashes, but also for further backup or server upgrade) The machine is equipped with 4 disks (500Gb each).
The second defensive line is the regular backups: they are made from cron scripts, essentially launched every days (eg. hotbackup for svn, trac sites, copy of the db files, etc.) or every week (database dump, svn dump, etc.) Exact ways of doing each backup depends on the services; for example, subversion provides tools for the (fast) hot backup (using hard links, etc) and textual dump, but a simple rsync is used for the database, made from a lvm snapshot.
All those backups goes on the (local!) /backup partition (to be fast); this partition is usually mounted in read-only; two sudoeable scripts are used to re-bind it in rw mode (beginning of a backup), and back to ro (at the end). A semaphore made upon lockfiles is used to take care of concurrent backups.
Each time that the /backup is switched to ro (and also every 4 hours), a mirroring action is scheduled (using 'at' with a small delay to concatenates changes from the third line). The mirroring is made (using rsync) to a different server, from which data are archived on tapes (every day, with only one year of retention) and, over the network, to a set of distant terra stations.
To avoid the risk of loosing an entire day of work, at minimal bandwidth cost, a third line is also in place, which consist in doing incremental backup - where it's possible.
These increments are saved using the same concept as for the daily and weekly copy (to the local backup partition first, and with a small delay, on the second host). Of course, the daily copy and weekly dump scripts have to take care of the rotation of the increments.
Notice that this third line is really close to a warn standby server (well, it's a necessary step toward this concept).
Finally, the config of the server itself (to monimize the work if a new one has to be setup). As I wasn't convince by the ghosting solution (new machine will have different hardware, disk config, etc.), I'd setup a dedicated subversion repository, on which I put every script or config file that I've manually edited (directly, or indirectly via a user-interface). So the root of the filesystem (/) is a working copy. In addition, a cron task scheduled daily is responsible to save the list of installed packages (dpkg), the partitions tables (fdisk), raid and lvm setup and so on.
BTW, it's certainly the weakest point: the server config is on a subversion repos, served by the "same" host. Anyway, it's fairly easy to use one of the repository backup (either a fast backup or the dump) from a different machine (even a windows one), if needed.
In addition, I also try to conscientiously make lvm snapshots before touching any script (or package upgrade) on the main system. But the lifetime of those lvm snapshot should be as short as possible, due to the big penalty introduced on the other services.
Well, I hope it can help, or at least gives ideas...
Good answers on backup policies already. I've come to love a simple backup tool: Backup Manager.
Backup Manager is very lightweight (just some scripts, really), and easy to configure. It knows how to backup SVN repositories, MySQL databases and can run specific commands to backup other systems that you can't just copy files to backup. It stores backup data in standard file formats (tar, zip, etc) and can save them to many different storage areas: local disks, FTP servers, scp, Amazon S3... possibly encrypting them using a GPG key on the way. Another important point is that it's already packaged in Debian and Ubuntu.
Definitely a simple and efficient way to start out, although you may want something more advanced in the end.
It's very good to save backups on Amazon S3.
For backups I recommend use duplicity and DT-S3-Backup bash script.
DT-S3-Backup was designed to automate and simplify the remote backup process using duplicity and Amazon S3. After the script is configured, you can easily backup, restore, verify and clean without having to remember lots of different command options.