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:
- Tar compatible (unless compression is used, but see below)
- Bare metal restore - can recreate system on bare disks from last backup
See Supertars for more details of the base features.
I tested this on two of my own machines: a RedHat ES system with an
IOMEGA REV drive and an older 2.4 system with an ide DVD-RAM drive.
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
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
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
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
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
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.
How do I know it's really encrypted?
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
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
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.
URL's and Filesystem Resources
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
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
Please enter the segment number, letter, or I# for info.
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
%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
* 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.
Got something to add? Send me email.
Increase ad revenue 50-250% with Ezoic
More Articles by Tony Lawrence
Find me on Google+
© 2012-07-12 Tony Lawrence