Skip Ribbon Commands
Skip to main content

Cory's Blog


Quick Launch

Stenoweb Home Page > Cory's Blog > Posts > Revisiting TECT Backups
February 13
Revisiting TECT Backups

Backups for TECT are kind of difficult, but a recent reorganization has made it cognitively a little bit easier. At the moment, it has a C:\ volume with a capacity of 2TB and just shy of 100TB used, and a D:\ volume with a capacity of 10TB and just shy of 2TB are being used. Once I recognized that these volumes were separate and had different types of content, I started thinking about backup of these datasets separately.

In this configuration, the C:\ volume really is more important. It contains the machine's operating system, Exchange database, SharePoint database, and the WSUS database. Ideally, I'd like to have backups of this volume on a pretty regular basis, and I'd like them to be shipped of-site fairly regularly too. The D:\ volume is less important, but much larger, and probably easier to back up, if only because the contents therein aren't necessarily being used. I would like to have this data off-site, but it's not going to be the end of the world if I don't have a backup off-site that's quite as updated as the stuff on the C:\ volume.

Because of this separation, I've started backing up the contents of the C:\ volume onto a pair of 750GB external disks, which I'm rotating each week on Monday or Tuesday. This backup runs at midnight and at 11 a.m. This means that I'm always protected within a few hours of some kind of catastrophic failure of TECT's disks, software, or the main system. One of the advantages of the dataset on the C:\ disk being so small is some different options for backup and archiving come into play if I'm willing not to have daily (or twice-daily, as I'm currently doing) backups of the larger D:\ dataset. I can make daily backups of C:\ onto disks or cartridges that are available today inexpensively. Then, I can make weekly (or even monthly) backups to carry off-site on the weekend when I have time to switch cartridges manually.

This means that I can save money on cartridges and host-bus adapters, save time on swapping cartridges, doing inventory of backups and of cartridges I can't really see, and of course I can spend money on backup hardware in a much more incremental fashion.

Initially, I wanted to make full backups each week with daily incremental backups to the whole server either to another disk array and then to tapes, or directly to tapes. Unfortunately, there are a few problems with this method, for an environment like mine. The first big problem is that tape drives are expensive. A DAT320 drive will start somewhere around $700, and an LTO5 mechanism starts about $2000, before you buy a SCSI or SAS card to connect it to. LTO6 mechanisms cost significantly more, and there isn't such a thing as a tape loader for less than $3,000. (There also aren't DAT320 loaders, even though I think you could probably make a DAT320 loader in a more compact form factor for less, but that's a different issue altogether.) An RDX dock might start below $100, and they're simple enough that it's not hard to trust one that comes from eBay.

The biggest problem with RDX is that the big cost moves from mechanisms to media. A 1.5TB LTO5 cartridge costs about $40, but a 1.5TB RDX cartridge (now the biggest size) costs no less than $260. How, then, is somebody supposed to use RDX to store a lot of data? I think the biggest thing to remember is that even if I buy four 1.5TB RDX cartridges, (to cover my 2.0TB of total data on D:\) then I'm still spending half what an LTO5 drive costs, and I haven't had to buy any new cards for the server. Archiving may still end up being a problem, but rewriteable and write-once BluRay media is available, and I can use that to make archival copies of certain datasets, or I can look at services such as Amazon Glacier.

The next biggest problem I personally have had with RDX is that I don't know how much I trust it. I've had a lot of spinning hard disks die over the years and it would be completely unsurprising for me to find out that carrying a set of backup cartridges around in my backpack on my way to or from work (my chosen off-site location) each week may cause problems. It is worth giving it a shot though, RDX has been around since 2006 or so and as per sources, a lot of small businesses are finding it to be successful for them.

One of the things that worried me initially about RDX was being unable to upgrade to a setup that uses automation, but I think what I would end up finding is that automating onto RDX cartridges may cost less than converting a stand-alone tape drive to an automated setup, especially given that you usually can't buy tape loaders or libraries without the drive.

Physical environment is another thing to consider. When I first started with TECT, it lived in my bedroom and never suffered extreme temperatures or humidity. Now that TECT lives in the garage (a somewhat poorly designed one at that) it suffers extreme temperatures as well pretty intense humidity. I don't personally believe that tapes would last very long in the garage. I could bring TECT inside, but part of the reason I have it out there is that all the various parts of the house that might otherwise have TECT are so very quiet. In an ideal universe, I might even have deployed thin clients by now. I could deploy a tape drive connected to Topham, or use an iscsi tape drive or loader, but it sounds like tape loaders are fairly loud.

I'm still researching of course, but I think the big news here is that RDX is looking more and more like something I could get started with, especially because I can start with an RDX starter kit for fairly cheap and have a more rugged version of my current backup solution, which involves two rotating consumer-grade portable hard disks. Then, I can buy additional cartridges for archive, data shuttling, or to build up to the point where I can do a full backup of D:\ onto two alternating sets of cartridges. (D:\ doesn't necessarily change often enough to merit daily incremental backups.)


There are no comments for this post.