Random Geek Stuff

I was about to make a change to a client system a few minutes ago, and the usual thought popped into my head: Do I have a backup?

No.

Before you get all up in arms that a geek like me doesn't have a backup solution in place for this client, I should explain the network.

It's pretty much non-existent. There's no server. Just four workstations, a firewall, and a VoIP server.
The old workstations don't need backups because everything they do is web-based, and stored elsewhere. The firewall doesn't need a backup. It's just pfSense with a static IP, a DHCP pool and the admin password.

In other words, the workstations and firewalls would take more time to backup/restore than it would to just reinstall the OS and tweak a few config files.

The VoIP box is another thing though. The client is a small call center. There are tons of customized rules for routing calls, SIP providers, voicemail, etc... It's fairly critical and needs to be restored quickly if it dies.

The box is running linux.

Since they have no backup hardware on-site, and it would be stupid to back it up to another machine in the same small building, it needs to be off-site. Oh, and since there's a lot of VoIP traffic, the backup needs to not be a huge dump, but a small trickle.

Within 5 seconds, I had the solution in my head. We have a storage server running BackupPC! I connected in, and within 2 minutes had created the configuration for their VoIP box, and told it to launch the rsync command with the --bwlimit flag set. Within 10 minutes the backup was complete. I had everything that was customized backed up. I can restore the machine be reinstalling linux, tossing the ssh key for BackupPC in the authorized_keys file, and telling BackupPC to restore everything.

Awesome.

Then I wondered how I would handle that if I were dealing with a Windows backup server with a windows or linux VoIP server...

...and immediately I could feel the Microsoft Rage building...


For the sake of comparison, let's say this imaginary Windows-based backup server was running on the same make/model of hardware so we can say the hardware costs are equal.

Immediately we run into the issue of having to pay for Microsoft's OS--which is no problem if it gets the job done.

So for additional comparison-sake, let's say the setup of the respective OS', RAID, and related hardware are equal. They are pretty close unless you take into account the time spent searching for RAID drivers for Windows, locating a floppy disk (I know I have one or two buried somewhere), copying the drivers, hitting F6 during install, having Windows tell you something is corrupted, running a chkdsk on the floppy, finding a bad sector, reformatting with bad block checking, copying the files, and finally succeeding. (Happened to me a few weeks back).

So now that I'm considering the server hardware, and OS setup as being equal, we can focus on the backup software and process.

BackupPC. I typed apt-get install backuppc. A few minutes later it was installed and asking me to assign an admin password. Done. Jump into the web interface, type in the address of the remote PC you want to bakup, copy the backuppc ssh key over to the remote machine's authorized_keys, and away you go. You automatically get full backups of the machine interspersed with incrementals, and history. Backup complete. No cost, just a few minutes of my time.

Windows. It comes with ntbackup. So let's see what we can do with the 'free' backup program. Backup remote systems? Meh. Sorta. You can map network drives, or forget the GUI altogether and pass command-line options to backup a network share. Awesome. Seems to work fairly well. Play with the mediocre scheduling ability of Windows and you've got nightly backups. Except that when you back the remote machine up to a local file called 'mybackup' you either have the option of full or incremental. If you choose 'full', every backup will be a full one. Same with incremental. And if you want to choose between overwrite or append, you're gonna need a batch file to figure out the name of your backup file so you don't keep appending to the same file for 3 months and end up with a 500 GB hunk of garbage. Typically your storage space is running low, you can't make another backup, and your only option is to delete the 500 GB file and hope the remote machine doesn't crash before you get a new full backup.

Oh yeah--good luck backing up in-use files. Windows doesn't do that too well unless you use VSS to get a snapshot and then back up the snapshot. Have fun trying to get a remote machine to do a snapshot and then back it up. I'm sure you could write something in vbscript or maybe vb.net to trigger the snapshot and then connect to it using the shadowcopy client... Anyone ever done that before?

So now that you have your ntbackup solution working, how are you going to know about failures? You have to remember to check the windows eventlog every day to make sure backups didn't fail. If they did, you have to go look through the log files and figure out what went wrong. In most cases an in-use file caused the whole backup to abort. No worries. I'm sure you'd rather lose the whole backup rather than just one file.

BackupPC sends me an email when it's done telling me which files failed. It will also tell me if the entire backup fails due to a machine being offline, connectivity, etc...

So the Windows backup solution so far has cost a bunch of time, writing my own batch files and possibly a vbscript or vb.net app to take snapshots. That sucks.

There are other commercial products out there that you can purchase for Windows. Most of them start around $1,000 just so you can install it on one server and backup another server.

Backup solutions on Windows suck, and take way too long to setup.

Although that does remind me of my ultimate linux backup appliance. I'll have to post about that tomorrow. Hopefully someone with a bit more free time and mad PXE skills will read it and decide to build my idea...

Quote:

Despite the high number of possible log format provided with Exchange, none of them is built enough seriously to offer an interseting analyze (missing informations, messy data, no id to join multiple records for same mail, etc...). For this reason, an "exact" log analysis is a joke with Exchange log files. http://awstats.sourceforge.net/docs/awstats_faq.html

Funny.