Backups and you
Let’s clear up a few things. You know you should make regular backups of your data, but you don’t, or you think there’s already a solution in place, but when you need it you’ll find out how inadequate it is.
So, how do you know what a good solution is?
A backup must be separate from the system it is backing up. At the very least an external drive. Otherwise a power supply failure can fry your original data and the “backup”. Ideally the backup will be as far away from the original as possible, so that a single event won’t be likely to wipe them both out. This is the most critical thing.
A backup should never delete files. Ever. If someone deletes a Word template today, it should still be in the backup next year, or until you make a conscious choice to remove it. Automated deletion of files will screw you.
The backup should be searchable; one shouldn’t have to dig through it file by file hunting for the file you need, or be forced to restore an entire archive.
A non-critical, but handy, feature is “versioning”. You find this a lot with online services, such as iDrive and Apple’s Time Machine, but it can be implemented locally as well. This sort of thing protects you from overwriting a good file in the archive with a corrupt version of that file.
One of the more common mistakes is to rely upon a RAID. RAID systems are great, but they aren’t backup solutions. They’re good for certain performance gains, and a certain amount of failure tolerance, but just thinking “Well, we’ve got the RAID, so it’s backed up” will lead you astray. First off, all those eggs are one basket. Secondly, while not likely it is quite possible to have two or more disks fail within a short span of each other, especially if they’re operating under the same conditions. Thirdly, there is absolutely no protection from file corruption or deletion.
Remember, if you aren’t sure something is backed up, assume it isn’t.