Step 6: Conclusion and Final Thoughts
If you're serious about backups, then TEST TEST TEST. Make sure that your backup and restore procedures are flawless. Backups that you can't restore are worthless.
One problem I ran into was setting my cache size too big. This can (basically) DoS your system and cause it to freeze. You're cache should always be a fraction of your RAM to be effective (mine's one-fifth), and should NEVER exceed your swap space size. 32MB is what dump's man page recommends. While this information may be outdated, having a large cachesize won't make much of a difference if you have all night to backup your system.
If you've automated your backups, make sure they're working. It would be a real nightmare for your system to crash and THEN realize that your backup crons quit working 6 months ago due to insufficient disk space. Cron jobs just automate the "complacency" process. If you do backups manually, don't become complacent and forget. Make it a routine. Don't rely on cron jobs either, because they can fail.
Backups are just copies of your files. This means that backups should be secured just as well, if not better than, your live systems. Keep your external harddrive in a secure location (like away from both water AND burglars). Run backup cronjobs as the 'operator' user. This is a limited account that exists for things such as this. Also make sure that normal users cannot run backups. If you feel you could potentially be the target of a sophisticated attack (or even if you don't), always encrypt data transfered during remote backups. Due to the amount of information, as well as regularity of backups (if you're using cronjobs), hackers can take their time in stealing your information. Encryption's easy, so use it. Make sure that normal users can't run backups to their own devices. Also, `scp` requires authentication. I HIGHLY recommend preshared public/private keys. You don't want your password to be transmitted everytime a backup is run.