No backup project would be complete without considering redundancy. As I mentioned in my first article (Workstation Backup Solutions Pt. 1: Having One), there are situations you have to consider such as hardware failure, natural disasters, theft, and a few others.

Redundancy What?:

When we think of redundancy, we care most about having multiple  replication points in backups (discussed in my second article Workstation Backup Solutions Pt. 2: Methods & Retention), and then about replicating that data to other hardware or even geographically different locations. Let me elaborate in the next section.

Redundancy Where?:

With local redundancy (Raid arrays, replicating to multiple physical hard drives/hardware, etc.) you ensure that the information is copied across multiple pieces of equipment, which should minimize data loss in case of hardware failure. The issue with this is that even if you have 10x replication of a single piece of data, unless you live in a bomb shelter with the ultimate fire/flood suppression setup, you can’t really be sure a natural disaster won’t destroy the hardware.

Geographical redundancy is a little bit harder to implement on a budget because of expense involved in keeping multiple sets of hardware in other locations. If you have a friend who can keep a machine elsewhere in the state/province/country/continent/world, it’s good to be you, and the redundancy world is your oyster. For uncool people like us however, buying/renting or collocating a server elsewhere is the best bet. Of course, there are companies that offer remote backups that you can use instead of hosting your own hardware, but with these services come some amount of risk, and you will need to choose wisely in order to avoid a headache.

Redundancy How?:

Firstly, you will have to determine whether you want to simply use raid arrays or local replication, or go with a remote backup option.

With raid arrays, you have the option of software or hardware raid. Software raid, though somewhat reliable, will crash and burn if anything happens to your OS, whereas hardware raid uses a raid controller and is less prone to operational failures. Using raid brings up the problem of whether an additional point of failure such as software glitch, or a hardware controller is worth it. If you buy a good raid controller, you should be better off when considering both raid options. But keep in mind that raid cards fail too. Ultimately, if choosing to use raid, I’d go with the hardware raid option always.

Local replication is as simple as moving already backed up data to another hard drive or piece of hardware. This can be done using either a drag-drop method, or setting up a script to move it for you. In Windows, simply creating a network share folder and setting up a routine to move the files over works pretty well. In Linux, a cron that runs an rsync or sFTP script works well too. For Mac, a similar procedure can be ran as in Linux environments to move data.

Some backup software may have remote options available for backing things up. It is totally dependent on the awesomeness of the software developers, but this feature is also very often associated with a larger dollar amount for the software. So beware.

For true remote backups, you will need a server or hardware of some sort in a different geographical location to your system. In all honesty, maybe having it at a friend’s house a few lots over isn’t going to be enough space. Think broader. If a natural disaster has the likelihood of hitting both locations around the same time, maybe it’s wise to keep it elsewhere.

A few things to consider when retaining hardware elsewhere is:

1. Uptime/Relative Network Speed
2. Remote hands capabilities
3. Hardware guarantees on rented machines

All three points are there to minimize headache. If you can’t connect to the remote server, replication is going to be difficult and a lot of hand-holding over the process will take place. If you collocate, you will need to maintain your hardware, and having competent remote hands to install new hardware/fix issues will go a long way. If you rent a server, a hardware guarantee of some sort is a wise idea as well. If you need to rely on a backup, and the remote server has failed without you knowing about it, you can kiss sanity goodbye; there is no going back.

I hope these articles help. There are a lot of options I didn’t cover, and in redundancy no two setups are usually exactly alike. Just remember that a backup plan is better than nothing, multiple sets of backups are better than just a single backup, and a geographic redundancy scheme even better still. Also remember that Google is your friend. You can find a lot of backup articles for workstations and servers from other contributors there.

Cheers!

In my last article Workstation Backup Solutions Pt. 1: Having One, I loosely talked about some methods to use for backups, and brought up retention. If you’ve taken into consideration anything I’ve said thus far, you would probably already be considering both. But, for the sake of delving more thoroughly into all the possibilities, let us continue with this premise.

Methods and retention vary from OS to OS, as does retention jargon. In fact, even the software within an OS may use different terminology for retention methods depending on their architecture and marketing prowess. Because it can get so confusing, we will stick with generic terms, and keep it light.

Methods:

Manually – Nothing beats good ol’ fashion drag/drop backups. They’re reliable, you know what you’re moving over to your backup space, and you can do it at your leisure. The issue with this is they’re not automatic (As you’ll find going to the movies instead of moving files, is much more fun.) If you don’t like the movies, and instead like this option, more power to you, I think movies are overpriced anyway. But, this option isn’t for everyone.

Commands/Scripts – This method takes a little bit more know-how. The good thing is, most everything you need in regards to this are available on Google, or other search engines/sites. You don’t have to get out your Shell Scripting for Dummies and learn shell script or DOS to do this. Instead of reinventing the wheel, read about how other people did, and use the extra time to go see that overpriced movie.

Software – Software will do just about the same thing as commands/scripts, as that is pretty much what their back-end is, but it will be presented in jelly buttons, and cool progress bars that aren’t accurate. The good thing about this option is that it makes things easy, and usually encompasses both the method, and has retention policy options. The downside is that software not laced with adware/virus, or advertisements costs money, and sometimes quite a bit of money.

Overall, compression and retention are going to be more involved on the first and second option. The third usually has a compression option built in. When you look for software, or are going to develop your own backup scripts, you will want to take into consideration these things.

Retention:

Yearly/Monthly/Weekly/Daily/Hourly/Minutely – When writing this, I didn’t think minutely was a real word as it sounds silly, but I was wrong. When choosing a method, you will want to think about how long you want to keep your data, and how it is backed up. Some software allows you to backup on the minute basis, others only allow less frequent backups, such as daily, or weekly. This can be a game changer if you need a twice daily solution (Every 12 hours) or need multiple schema, such as a backup daily, and also a backup hourly of say, a highly written to file.

Full – There are two major types of full backups. One that retains the filesystem structure, and the other retains all of the necessary components to restore the entire OS. Whatever the type, it will retain a full backup of all of the files/folders and structure of your system. Most backup software will just retain the filesystem structure, but won’t be able to do a bare-metal restore. This means you will need to reinstall the OS, then restore the files accordingly. Keep in mind that you most likely will lose your installed applications, though the files for them will still be intact.

Incremental/Differential – When we talk about incremental and differential ,there are very technical differences between the two. Know however, that typically differential are backing up only files that have changed since the last full backup. Incrementals are files changing since the last backup, whether it be full, or the last incremental. Both are designed to save time and diskspace when backing up and restoring, but are also difficult to construct without very in-depth knowledge of the OS you’re trying to backup. In other words, it’s easier to use software that has this option than try to create a backup scheme from coding yourself, that is, unless you’re a super-supremo-awesome coder. In that case, go for it, let’s team up and market that. I could always use more money…

Continuous – If this wasn’t self explanatory enough by the name, I really can’t help you understand it better than talking about its technical aspects. A continuous backup basically backs up your data…well…continuously, but references your first full backup the same as incremental/differentials do to determine what has changed. Some are as specific as will backup even a draft save on your latest Word document, others wait until you’ve saved a copy and a write to the hard drive is made. Either way, it can be very beneficial to have this in case a revision to a file was a mistake, and you need the previous version.

In conclusion, as your backup needs change, you can evaluate these options more. Always weigh out the benefits of going for a more feature filled software first instead of having to buy whole new software later on. If you think you will grow into it, and the price point isn’t that much higher, well….I don’t even need to tell you. Just use logical judgment. As for making your own schema, the same rule applies. A little more work while creating the setup will go a long way in terms of you not needing to touch it for awhile. Grow as necessary though, and project slightly into the future.