Backing up is easy, right?
There’s nothing more important than to make sure that your valuable data is backed up in the right way so that, when disaster strikes, you’re covered and get back to where you left off as soon as possible.
While that may sound simple, it really isn’t. There’s a wealth of different backup solutions out there, but in order to succeed with any of them you must have done some planning first which usually boils down to the following steps:
- What data to back up
- Whether there are secret/sensitive data to consider
- How often to backup
- The retention time of your backups – how long to keep them
I’ll cover these in a number of posts – lets get started with …
Backing up the right amount of data
Take a moment to think on what pieces of information stored on the disk of the system in front of you that you really, really must keep safe.
Many people instinctively will answer “everything!”, but that will waste precious backup storage as much of the data being backed up actually always will be recreated when reinstalling the operating system.
Let’s say that your primary workstation is running Debian. There will be a few user accounts – yours and those of your family or co-workers and they will live under the /home directory structure. So this is obviously the most important location to backup to make sure that your documents, pictures, Git repositories etc are included.
When faced with the utter destruction of your hard disk you can then simply replace it, install Debian from scratch, add your personal user and finish up with restoring the /home directory from where you left off and you should be all set.
Now consider the scenario that your system is also used by a few friends that can login to your system remotely. Recreating their user accounts and asking them to reset their passwords will be extra work, so let’s make sure to include the password and shadow files from /etc/passwd and /etc/shadow. Actually, since most of the configuration data for system programs and services sits in /etc it is probably worthwhile to add the entire directory to the backup. So the list has grown to /etc and /home at this point.
Let’s assume that your system also is running an Apache web server. The configuration for the different web pages sits in /etc/apache2/sites-available and that’s covered by /etc since before. But that actually content being served usually sits in /var/www. If you’re running a mail server as well (and haven’t transitioned to Maildir), incoming e-mail will be stored in /var/mail. In this case it seems to make good sense to also add /var to the mix!
Finally you may be running a site just like this, having WordPress storing data in a MySQL database. You will find that the files comprising the database are in /var/lib/mysql and we already added /var to the list of locations to backup, so we’re covered already – right? Not really. Backing up the physical database files will in many cases give an inconsistent database state when restored, as the database may change during the process of backing up. To be safe, you either need to shut down MySQL before backing it up or – which is the recommended way as it will cause no service outage – to use the mysqldump tool to extract the database content as a text file and store that, for example, in your home directory
Other locations that you could consider backing up is the home directory of the root user (/root) or the structure for locally installed programs (/usr/local).
What you don’t need to consider if you’re going to reinstall your system from scratch are for example /usr, /sbin, /boot, /media, /proc – they will all be recreated during the install phase.
Stay tuned for the next post, discussing the security considerations when deciding a backup scheme!