How do I compare cloud based back ups to server based back ups?

Question

I habe been asked to research back up systems for our software and files. We have Windows 7 on most of our computers and XP on the others. We're looking at getting new industry specific software in the near future as well. How do I figure out whether or not a software is compatible with a back up system, or if there will be issues doing back ups?

Answer 1

It depends. On a lot of things. A backup system has to know enough about what you're trying to backup in order to be efficient, to back up everything, and to guarantee integrity.

There are several approaches to backup that I've seen deployed in production systems:

1. Everything is a file -- In this approach, treat the core unit of backup significance as the individual file. The backup utility does a differential backup -- meaning that each day, only the changes from previous backups are written -- on a daily or hourly basis and saves it to a device suitable for long-term storage, such as magnetic tape drives. This is best-suited for networked filesystems where applications store their data as "plain old files". Extended attributes required by programs (permissions, etc.) may or may not be copied over to the backed up media; if you think you have programs that need to care about extended attributes, then make sure they're copied over correctly.

2. Blocks -- In this approach, the backup software backs up a disk block at a time. Disk blocks are a very generic "chunk" of data that is a layer of abstraction beneath the filesystem. So all metadata related to the filesystem, including journals, backup master file tables, scratch areas, extended file attributes, streams (NTFS), and so on, are captured. This is a great way to capture truly everything about a system. The downside is that most block-layer backup solutions require the system to be taken offline so that a consistent image can be taken, because without knowledge of the filesystem, it isn't possible to know what is considered a "good" image (a file could be in the middle of being written to disk and if you take a backup at that moment, the data could be corrupted).

3. Application-layer -- In this approach, the backup software knows about your specific applications, whether it's IIS or an FTP server or a file server or what have you. The backup software, by knowing about your specific use case, can have optimized processes for more efficient backup and storage, and can even do this while "online", so services don't have to be brought down to backup. In this case, the responsibility is on the software to understand what pieces of your filesystem are relevant and only take backups of those. If you need to backup data on system disks (disks containing a copy of the operating system), this is recommended, because it is very difficult or impossible to backup data on a running (online) system disk, due to file locks, open files, temp files, etc. Of course, you can also take partial backups of just a few pre-determined directories if you go with the first option, but that requires detailed knowledge of what to backup, and you may miss something useful like a config setting or registry value sitting on the operating system disk.

As a general point of advice, "backup" should almost never be associated with data on the system volume of a running server. So if you're on Windows, you don't want to be taking backups from C: (assuming that disk has your WINDOWS directory). In an enterprise environment, valuable, non-replaceable data should be on a separate volume altogether for clear separation between "the operating system image which contains executable code, binaries, and third-party software from Microsoft and other vendors", and "data that our applications and our personnel have created during the course of their work". This also makes it MUCH easier to simply say, backup the entire drive letter D: instead of having to worry about individual files and folders.

Another point of advice: in an enterprise environment, individual workstations are not normally backed up. Users are instead educated that they should store valuable company data and files on a networked share drive (shared over a Windows Domain controller), and the shared volume is backed up usually using the differential backup-to-tape method (on a file level) that I mentioned.

To me, the hallmarks of an ideal enterprise backup system are the following:

1. During backup, system performance is not negatively affected.

2. Backups can be taken quickly and frequently, and the storage cost of each backup is not significantly higher than the cost of new data that has been added since previous backups.

3. Backups are written to reliable, long-term storage media over a very fast link, such as SAS or SATA or iSCSI, and generally not through something slower like ethernet (backing up any large quantity of data over the public internet is insanity; don't do that!).

4. Backups are stored off-site, and are kept under controlled conditions to protect them from physical threats such as fire, human malice, espionage, water damage, strong magnetic forces, and so on (there are contractors/vendors who do this for you).

5. The number of logical places where contain sensitive, valuable, or non-replaceable data is stored is kept to a bare minimum, so that it is easy to keep track of a "central repository" of data that needs to be backed up. Trying to back up a dozen different systems really stinks because you have to make sure each one is successful.

6. Multiple separate copies of the backups should be kept, even if some of the tertiary backup systems are not refreshed as frequently as some of the front-line backups. The tertiary backups should be stored in a separate location, and any access controls to them should be separate, so that a security breach involving malice or an act of God (such as a destructive earthquake) only affects one copy of the backups and does not make the data permanently lost.

7. Backups should have a regular destruction schedule or "lifetime" so that they don't pile up forever. An excessive amount of extraneous backups can make it very cumbersome to retrieve a consistent and current copy of the data, and can prove a liability in the future as expenses for storage space continue to mount. They can also be bad if you run into legal trouble and need to destroy evidence, but that's a separate topic...