I have never bothered to set automatic (scheduled) backups, relying instead on a number of different backup systems, and fairly frequent backups. I have several images of my entire hard disk, made over a period of weeks and months, and copies of my data files created over a similar time frame. In addition, I have a real-time backup system for my data files, so I should be disaster proofed against a sudden disk failure. But, what I didn’t take into account was the Supreme User* deleting an entire folder of E-mail messages instead of one specific message.
|* Some may recall (see: Imprecise Pangolin) that the Supreme User (SU) is also known as the Spousal Unit. And, for the case currently under discussion, the deleted item was very important – it was SU’s personal mail folder!|
As it happens this occurred on the very day that an update to Thunderbird 15.0 was provided by Update Manager, and just after I had made a backup image of my complete hard disk prior to installing this update. Consequently, I was able to retrieve the message folder from a point an hour or so before it was deleted, and all that was lost was an individual message (but, even that was “quoted” in a reply that was present in the Sent folder, so actually nothing was lost.)
At his point it’s worth discussing why I choose to create frequent backups of my data partition, given that I have a real-time data backup system. The incident noted above shows the potential problem with the latter. If the hard disk abruptly dies, the real-time backup disk is likely to contain all of the data files to that point in time. But, if I (or the Supreme User) inadvertently deletes a file or a folder from the hard drive, the equivalent file or folder is also instantly removed from the real-time backup. Consequently, one needs an earlier backup of the data disk from which to retrieve such deleted material.
So, as noted above, in the case incident, the solution was simply to mount the disk image made earlier that morning, and copy the subject folder from the backup to the main data partition. Of course, this backup replacement is only as current as the disk image, and an E-mail folder from a week ago might not be quite so useful as one made on the same morning as the “failure”.
So, that got me thinking about setting up a system of regular – and more frequent – backups. Clearly, I could opt to configure my disk imaging utility to create frequent incremental backups of either the full hard disk or just the data partition. The alternative would be to configure my data backup system to run automatically on a given schedule. For now, I have chosen the latter approach and will have Back in Time run daily which will effectively create an incremental backup of all my data files.
The basic process is simple – open Back in Time – select Settings – change Schedule from Disabled to Every Day. But, for me, there is still a problem. By default, “Every Day” means every day at midnight. But, my system is almost never running at midnight, so the daily cron backup job wouldn’t run.
Fortunately, another utility program comes to the rescue. We need to install Gnome Scheduled Tasks using the Ubuntu Software Centre. The Scheduled Tasks program shows up in the Applications – System Tools menu and provides a management tool for cron jobs. Running Scheduled Tasks shows the Back in Time job scheduled for 0000h. Changing this is as simple as editing the scheduled task, clicking on the Edit button for Advanced – Hour and entering 07 (for 7 o’clock). Similarly, one can edit Advanced – Minute and enter 30, so that now the backup will run at 0730h each day.
This would suggest that my system will now be backed up each day at 0730h. So, problem solved? Well, no, there is still a problem. Just as a scheduled cron job won’t run at midnight if the machine is switched off, it will equally not run at 0730h should the computer still be switched off at that time. And, unfortunately, booting the machine at, say 0800h, means that the scheduled backup has been missed and Back in Time will not run automatically until 0730h on the next day (when the machine is powered up).
So, the answer is to set the alarm clock for 0700h, right? Well, no. The Linux gurus have already figured out that cron jobs might not run in the instances described and so another solution awaits. But, it gets complicated, so better set your alarm for 0700h!
Back to the future
Automatic backup with Back in Time? (see comment by Deadlite81)