///BackupEDGE 2.1

BackupEDGE 2.1

BackupEDGE 2.1

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.

New 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

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…

1. 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.

2. Quick File Access / Instant File Access would have been lost.

3. 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.

4. CD/DVD/REV backups couldn’t be bootable (the boot tracks would be encrypted).

5. 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!

6. 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).

7. 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.

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
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.

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 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.

[1] key.mail.2005/01/27 Edge.Nightly 02.01.00+ Decryption Key Backup mail.aplawrence.org 2005/01/27 06:07:28
[2] ftp237_master.4 Edgemenu 02.01.00+ Master mail.aplawrence.org 2005/01/27 06:15:00
[4] ftp237_master.5 Edgemenu 02.01.00+ Master mail.aplawrence.org 2005/01/28 06:15:00
[6] ftp237_master.6 Edgemenu 02.01.00+ Master mail.aplawrence.org 2005/01/29 06:15:00
[8] ftp237_master.0 Edgemenu 02.01.00+ Master mail.aplawrence.org 2005/01/30 06:15:00
[10] 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.

Dislikes

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.
2010-05-26T11:24:43+00:00 May 3rd, 2005|Linux|0 Comments

About the Author:

Leave A Comment