I've removed advertising from most of this site and will eventually clean up the few pages where it remains.
While not terribly expensive to maintain, this does cost me something. If I don't get enough donations to cover that expense, I will be shutting the site down in early 2020.
If you found something useful today, please consider a small donation.
See Microlite BackupEDGE 2.03 for a review of the most recent version.
The latest version of Microlite BackupEDGE adds several new features. For those who are not familiar with the product at all, a quick recap is in order:
See Supertars for more details of the base features.
As you would expect, I don't read manuals any more than anyone else does, and that's especially true when it's "just" new features. Hey, I can figure this out, right? Right. Quick skim of the white papers should do me fine. Except I did miss a few important things here and there. Microlite has a pile of downloadable PDF files (if you get the CD, they are all on it also), and I should have read at least some of them. On the other hand, things didn't turn out all that badly even though I was flying partly blind, which says something about intuitive ease of use, doesn't it?
Encryption always makes my head hurt. I can understand public/private key encryption only while I'm thinking about that and nothing else. I have to keep my head down and concentrate, and if anything else distracts me, well, I lose it and get confused. So when I read :
During RSA key generation, one public and two types of private keys are created. Standard Private Keys are protected by UNIX/Linux system privileges. Protected Private Keys are additionally encrypted with a passphrase. After creating and archiving the private keys, the administrator may choose to remove those keys from the system with the following effects during restore: - If a Standard Private Key exists for the archive in question, files are decrypted and restored automatically and transparently. - If only the Protected Private Key exists, the administrator will be prompted for the pass phrase before the files may be decrypted. - If neither private key exists, the user will be prompted to insert the appropriate Key Archive before the files may be decrypted.
.. well, my eyes glazed over. I decide that I'd trust this:
BackupEDGE uses a powerful combination of symmetric and asymmetric algorithms to encrypt and decrypt data. It is completely standards-based, and the methodology will be published on our web site to assure users that standards are being followed and that no back doors or other security holes are in place.
Somebody with a less worn-out brain can watch 'em - I'll just use the darn thing and trust it.
The first step for encryption is to turn it on. Well, no, the first step is to license it. Not everyone needs encryption, so it's an extra cost ($150.00 list) add-on. You'd then choose "Set up Encryption" form the Setup menu. You provide a passphrase (which can be stored on the hard drive for convenience), and the keys will be generated. If this is a single user machine, you'll need to help the process along so that it can generate good random numbers: I just logged into another session and did an "ls -lR /".
If a bell went off when I said "convenience", you aren't thinking about what this encryption is for. It's to encrypt files on backup media. It is to protect that data should the media fall into the wrong hands. If someone has root access to your machine and can read the passphrase stored there, you already have problems. Still, if you prefer to supply the passphrase for restores, you can elect NOT to store it locally.
You aren't going to encrypt the whole archive. That would be dangerous and pointless, and perhaps even counterproductive. As Microlite's white paper explains
Simply encapsulating an entire archive with an encryption filter can be disastrous. For instance, if we had decided to do that in order add encryption to our previous product to get it to market faster, then... o Read-error recovery would be lost. Single byte errors could render an entire archive unrecoverable. There would be no easy way to sync back up with the encryption stream. o Quick File Access / Instant File Access would have been lost. o Standard file restore times would have increased dramatically, as the entire archive would have to be decrypted from beginning all the way to the last file to be restored. o CD/DVD/REV backups couldn't be bootable (the boot tracks would be encrypted). o System performance would suffer greatly as encryption took place. Backup and verification time windows would greatly expand. BackupEDGE integrated encryption encrypts only the data you specify, and avoids all of these problems! o Standard, hardware compressing tape drives would suffer from greatly reduced performance and capacity (unless we also chose to wrap the entire archive in a compressor such as bzip or gzip and disable hardware compression, which would take even more time and make error recovery even less likely). o The archive would actually be less secure! Because much of the data in backup archives is repetitive, dictionary-based attacks are possible even with access only to a single archive. Access to two or more encrypted archives could further enhance the feasibility of this attack. BackupEDGE first compresses data, then inserts random bytes, before encrypting it. Every backup has a new symmetric key that is created by a cryptographically strong random number generator. These features enhance archive security while shrinking the space needed to perform a backup.
So, you'll create a list of the files (wildcards are fine) that you need encrypted. That list is associated with a Domain (a domain is the list of things you want to back up) - each domain can have its own encryption list or none at all. This association also means that encryption lists are NOT applied to manual backups. Only scheduled backups (or backups done with Run Scheduled) pay attention to encryption lists. Again, if that bothers you, consider that anyone with physical access and the root password already has access to the data - this protection is for backup media. Further, anyone with such access could just change the encryption list to avoid using it. Just remember WHY we're encrypting here.
After all this, you'll be asked to create a "Decryption Key Backup". I ran into a slight problem with that: if I made it to a DVD or REV drive, I could use the "Load Decryption Keys" to restore them. But if I used a FS or URL resource (see below), the restore would not work. Microlite Tech support acknowledged that problem, but added:
It seems that Restore Key Backup doesn't deal with URLs well. Use Restore:Restore Entire Archive instead, and select the key backup. It will do the same thing.
If you have the passphrase stored on the system, the restore just transparently restores data. Even if you've removed the local storage, all that happens is that you get asked for the phrase - maybe it's all just a shell game?
Well, no. And there is a way to prove it, though it gets a little complicated. These backups are tar compatible: you CAN read and restore an archive with plain old tar. That's true, but if you also set software data compression, tar will just bring back a compressed file. In the olden days, you could just tack a .Z extension on and uncompress it, but times have changed. Microlite explains:
The 2.x BackupEDGE format was designed to be useful given todays computing environment, with backwards compatibility whenever possible. Given 5,000 character pathnames, encryption, embedded checksums and all of the other features in the product, not everything could be backwards compatible. To get the performance (both from a speed and space standpoint) we wanted, we went to zlib and started "segmenting" files into chunks on the archive (to alleviate the "compress into a pipe" problem). If you restore large compressed files with tar (assuming you have short enough paths), you get zlib-d chunks that could be re-assembled with a short C program. That program is - - - edge. This is not the old days. BackupEDGE is NOT just a tar extension, and copies of BackupEDGE are ALWAYS available on line in an emergency. Although we've kept an amazing amount of compatibility, we had to make changes to get people the features they need.
So, if we are really untrusting and want to prove that encryption really happens, the easy way is to turn OFF software compression, do a domain backup, and restore the file(s) with tar. You will see that encryption really has been used.
The other new features here are related: you can back up to a file system (local or attached) or any ftp server. I put that feature to good use at a site where the tape drive died recently. This is a big, big system and it would take time to get a new tape system and nobody wanted to shut it down anyway. Instead, we reconfigured the backup to go to an NT ftp server instead - that machine has a working tape drive, so BackupEDGE sends its files there. At another site, we did the same thing because a DVD ran out of space - but this time we used a Mac OS X machine that has a REV drive attached. The flexibility of this is simply wonderful.
You can even do bare metal restores from a backup made this way. For my two office machines, I have each configured to use the other for a secondary backup in addition to the DVD and REV backups they do. The REV machine defines a more limited domain because not all of it could fit on the smaller machine (and that machine cannot backup as much with it's DVD-RAM anyway). But the net result is that I can recover from removable media OR the other machine. If I wanted to (and had a good hi-speed link), I could do an FTP backup to a machine on the other side of the world - and do a bare metal restore from it if necessary!.
You don't have to be concerned about any file size limitations on the receiving ftp server: if it can handle a 2 GB file, everything will be fine, because the backup is broken up into segments less than 2GB.
You control the number of distinct backups by assigning a "slot name" to a backup. For example, if Monday's backup had a slot name of "Mon" and Tueday used "Tuesday", you'd only get five backup sets on the ftp server. If you used just two slot names and alternated them. you'd only get two. And of course if your slot name used the actual date for its name, well, you had better have a pretty big ftp server.
When you go to restore from a resource, even if you do it from the command line ("edge xvf rev0", for example), you are presented with a listing of what's available:
# edge tvf net237 Microlite BackupEDGE Enhanced Data Archiving System (c) Copyright 1997-2005 by Microlite Corporation All Rights Reserved BackupEDGE Registered End User: A.P. Lawrence Serial Number: TIF20000053 Please select a segment number to read.  key.mail.2005/01/27 Edge.Nightly 02.01.00+ Decryption Key Backup mail.aplawrence.org 2005/01/27 06:07:28  ftp237_master.4 Edgemenu 02.01.00+ Master mail.aplawrence.org 2005/01/27 06:15:00  ftp237_master.5 Edgemenu 02.01.00+ Master mail.aplawrence.org 2005/01/28 06:15:00  ftp237_master.6 Edgemenu 02.01.00+ Master mail.aplawrence.org 2005/01/29 06:15:00  ftp237_master.0 Edgemenu 02.01.00+ Master mail.aplawrence.org 2005/01/30 06:15:00  ftp237_master.1 Edgemenu 02.01.00+ Master mail.aplawrence.org 2005/01/31 06:15:00 [Q] Quit Please enter the segment number, letter, or I# for info. Selection?
That uses slot names of "%N.%w", which is the name "ftp237_master" and the day of the week:
%n: machine hostname (no domain name is included) %N: name of scheduled job %S: second %M: minute (00-59) %H: hour (00-23) %w: day of the week (0 is Sunday, 6 is Saturday) %d: day of the month (01..31) %j: day of the year (000..365) %m: month of the year (01..12) %Y: year (CCYY) %y: year (YY)
If you have the encryption supplement, and if your FTP server supports it, you can use ftps instead of ftp. Confusingly, the current version offers this as "sftp" - it is not sftp, it's ftps, ftp over SSL. I think it would be nice if they added actual sftp as a choice here also: that's much more commonly available nowadays..
Filesystem backups and attached filesystems use the same concept of under 2GB segments and slot names. The difference is that attached file systems ask you to specify mount and unmount command. Neither of these backups can be used for bare metal restores - use ftp backups for that.
One minor annoyance with this is the old concept of a default backup resource. This makes far less sense now that we have so many more possible resources. Unfortunately, certain operations require setting the default resource, and backups don't let you easily change it for a one time operation. I hope that's changed in a future version. But that's a minor nit-pick; overall these are wonderful new features.
An important notice just out with this:
Information about 2.6 Linux Kernel Support BackupEDGE 02.01.01 now supports 2.6 Linux kernels. RecoverEDGE currently does not support LVM or md software raid. Disaster recovery of systems using LVM or md will not function. This release also adds support for Fedora Core 3, with the following limitations: * Remember that FC3 has been described by Red Hat as not a supported distribution of Linux. * Because of the frequency of updates to FC3, support is on a "best effort" basis. While we will make every effort to keep up with the latest patches to it, we cannot guarantee that they will not be introduced faster than we can qualify them.
If you found something useful today, please consider a small donation.
Got something to add? Send me email.
More Articles by Tony Lawrence © 2012-07-12 Tony Lawrence
Random numbers should not be generated with a method chosen at random (Donald Knuth)