Ease of Administration
If a person is administering a relatively large backup system, the activities in the
following list are performed all the time. How easy is it to do these things with the product
you are considering? - Making duplicate volumes for off-site storage
-
This feature allows an administrator to make copies of volumes and send the
copies off-site. (Actually, a better method is to send the originals
off-site. Doing the day-to-day restores from the copies is a constant
verification of the copy process. Unfortunately, many products won’t allow copies to
be made this way.) The right way to do this is to copy from volume to volume,
instead of running another backup. The copied volume should have its own identity.
That way, the copied volume can be tracked in the catalog. (Older methods of copying
volumes resulted in two copies of the same exact volume. The second volume never
actually existed in the product’s database; it was just another copy of the first
volume. The same is true of some VTLs that replicate their data.) Some products also
allow an administrator to specify the location of the copy volumes so that he knows
which volumes are on-site and which volumes are off-site. That way, the software
won’t ask for the volume that it knows is off-site, if it knows it has another
volume on-site that has the same data on it. - Copying an individual backup
-
There is a downside to copying volumes. Depending on the level of volatility of
the data and the luck of the draw, the system may or may not fill up a complete
volume each night. If copies are being made and sent off-site every day, what
happens to the volume that is half full? If it is copied and sent off-site, the
software cannot continue to write to the original volume, even though it has more
room available. If it did, it would have to copy the entire volume again. Wouldn’t
it be better if the software knew how to copy last night’s backups, regardless of
which volumes happened to receive them?
Individual backup copying does just that. It is the ability to say, “take all of
the files that got backed up last night (the backups) and put them on these volumes
over here, which I will send off-site.” Depending on the complexity of the software,
last night’s backups may have ended up as 100 MB pieces on 20 volumes. Backup
cloning would take those 20 separate 100 MB backups and put them all on one 2,000 MB
(2 GB) volume. This would be done after the backup, and the data traffic would stay
local to the backup system—so it wouldn’t affect the other CPUs, the network, or the
users. - Simultaneous copying of backups
-
A very new feature that has begun to appear is the ability to copy the backup as
it is being made. If things are set up right, and the software does what it is
supposed to do, you actually can make copies in no more time than it takes to make
the first backup. The better products would allow the two backup volumes to be
different sizes, allowing for differences in compression and different types of
media. (Perhaps you may want to put your on-site backups on one type of media and
your off-site backups on another type of media.) - Consolidating a host’s backup
-
This nifty feature of some backup programs allows for the consolidation of all
of the backups for a given host onto a volume or small set of volumes. This makes
preparing for a disaster much easier. - Consolidating volumes that have very little data on them
-
This is a volume utilization feature. Due to different expiration times of
different backups, there may be a large set of volumes, each of which has only a few
hundred megabytes of data that are still useful. Volume consolidation consolidates
these backups from all of the partially used volumes onto one volume, allowing the
source volumes to be reused. - Filesystem/database discovery
-
Will this product automatically discover all filesystems/drives, or do you have
to specify them manually? The latter requires you to constantly update the list of
filesystems to be backed up—not good. Also see if it supports this feature on any
databases. It sure is nice not to have to maintain the list of SQL Server databases
to be backed up. - Excluding files
-
There are always files that should be excluded from backups: temporary Internet
files, files in /tmp, spool files, core files,
etc. The types of files that need to be excluded vary from site to site. Be aware
that different products have different methods for excluding files. - Interface types
-
Most products have Windows, Java, HTML, Motif, Curses, and/or command-line
interfaces. Only a few have native Mac interfaces. Make sure the product has an
interface that is appropriate for your environment. (I also should state the
importance of an optional command-line interface in almost any environment; you
can’t always count on a graphical display during a disaster recovery, and you also
may wish to do your work over a remote connection.) - Notification
-
How should the administration team be notified when a backup fails or needs
attention? There are a number of different methods. The most common method is email.
Some vendors even allow different email recipients for different types of messages.
Other vendors allow you to write custom interface programs that send reports
wherever you would like. Some backup products can even send alpha pages if there is
a modem available.
Perhaps the most sophisticated notification method is the use of an SNMP trap.
SNMP stands for Simple Network Management Protocol and was originally developed for
network hardware so that routers from different vendors could understand one
another. SNMP has been expanded to include all types of network monitoring, and it
is what most of the commercial network monitoring tools are based on. - Installing
-
Most server installations are fairly automated. The real bear is the
installation of client-side software. There are usually two ways that client-side
software can be installed: manually or automatically. When using the manual method,
you first must get the client software to the machine. This is done either by
ftp, nfs, or
CIFS. Then, run the installation program. Some
products can completely automate client installation under certain
circumstances. - Upgrading
-
The product is installed once, but it will be upgraded once or twice a year.
Therefore, ease of upgrading is another very important feature to consider.
Upgrading also may be performed manually or automatically. However, some products
(once installed) are able to update the software automatically. Since updating the
software on hundreds of clients is the most difficult repetitive task you will do,
this feature is quite handy.
Security
Historically, backups and security have had almost completely opposite
goals. Things such as .rhosts files in Unix systems
were absolutely necessary to gain any type of backup automation, and yet they are a
well-known security problem. Fortunately, most modern backup products have worked around
these problems. Here are some security issues to consider: - Daemon/service communication
-
Any decent product is going to have a secure method of communicating with the
client. They will not require insecure communication methods such as rsh. - System authentication
-
How will the server and client verify each other’s identity? Will they simply
use hostnames and IP addresses? That’s easily faked and should be avoided. Another
method is to use the root password of the client. This requires the backup
administrator to know the root passwords of every client—also not a good idea. Other
systems use sophisticated one-time passwords that are very strong. Investigate how
your backup software authenticates its systems. - User authentication
-
How does the backup software authenticate administrators of the system, or
people who want to perform user-level recoveries? Do they have their own database?
Do they integrate with Active Directory or NIS? - Role-based authorization
-
Once a user is authenticated, are they all-powerful, or can you assign certain
tasks to some people and not others? It would be nice if the person responsible for
monitoring backups is not the same person setting them up. It would be nice to limit
the number of people who can delete or overwrite backups. - Encryption
-
http://www.privacyrights.org maintains a list of privacy
breaches, and as of this writing, it lists over a dozen tape-related privacy
breaches. With all the attention these incidents are getting, more and more people
are asking for encryption. Encryption can be accomplished in one of three ways. The
data can be encrypted in the original filesystem. It can also be encrypted by the
backup software as it’s being transmitted to the server. Finally, it can be
encrypted by a hardware appliance. If you’re considering backup software encryption,
make sure to talk to your backup vendor about it.
|
