Hi Cyndi
Personally, I'm queasy about the creation of tapes at all of these remote
sites. Every site must have at least two people (a backup person to cover
sickness, vacation, etc.) who FAITHFULLY load media, unload media, and send
the media to other locations (for disaster recovery). Plus, someone in IT
needs to monitor the backups on a daily basis, to ensure that they complete
normally within their time window. So, I believe that central monitoring is
going to occur anyway; the only decision is how the backup data movement
occurs.
I believe that any solution must cover:
o backup (and restore) - to protect against hardware and software failures
and user errors
o disaster recovery - to protect against site disasters
o archiving - to protect against long-term information loss, to meet
government/financial requirements
I like your list of possible options. Our team has spent quite a bit of
time ruminating about remote backups. May I add another option to your
list:
5. Perform local disk-to-disk backups at the remote sites, followed by
replication to central site.
Advantages:
o no local tape media; therefore, no local involvement in the corporate
backup strategy, other than making sure the power is on;
o disk-to-disk backups are probably faster than tape;
o using newer Serial ATA disks, cost for disk backups does approach tape
(when you figure cost of tape drive, autochanger/tape library or human,
media, etc.);
o disk subsystems routinely provide RAID support, so backups to disk are
safer than tape;
o [near-term future] advanced storage systems (like EMC CLARiiON) provide
features like snapshots, mirrors, and clones that can create a backup in
seconds; these are capabilities that tape can never match. This type of
backup does NOT create a saveset, but creates a replica image. NetWorker
will embrace this type of backup over time; the current integration level is
low, alas, but we're working to change that!;
Once the disk-to-disk backup is complete, it's available for local, rapid
restore; no chance of the backup tape(s) being misplaced.
But, to ensure disaster recovery, some/all of the local data should be sent
offsite. Your two choices are:
o copy the backup saveset to the remote site - this is bandwidth intensive,
but you can lessen the effects by copying, say, a monthly full backup and
daily incremental backups. Copy the savesets to disk at the remote site,
because disks handle very well a possibly slow data stream from the remote
sites; many tape drives would "shoe-shine" and wear out prematurely in this
application. This can be aided by (1) staggering the full backups of the
remote sites, so that 1/28 of the remote sites do their fulls on any night
[1/28 because every month has 28 or more days], (2) using network devices
that perform compression and (3) investigate connecting the remote sites via
low-cost high speed connection (cable modem or DSL) to the Internet and
using a VPN tunnel to connect via the Internet to corporate; this could be
much more cost-effective than leased lines, and could provide the bandwidth
necessary for backups.
o mirror the source disks to a remote site - this is bandwidth un-intensive,
but the link must be available 24 x 7. There are software and
hardware-based solutions that support mirroring. Hardware-based mirroring
solutions, coupled with IP Storage technologies (like FCIP), now support
long distances between source and target.
Another word on IP Storage, if I may. One of the problems with doing
backups over a LAN is that both the backup client and the backup
server/storage node must handle the packetizing/un-packetizing of the backup
data into IP. This is VERY resource intensive. iSCSI, on the other hand,
is implemented such that this IP workload is handled in the iSCSI hardware
by a TOE (TCP/IP offload engine); so, the backup client is not impacted by
this IP work, and can accomplish backups with much less performance impact.
Plus, the backup client can now 'see' and use a SCSI device (disk or tape)
that might be hundreds of miles away.
Finally, archiving must be done. I like the currently-popular mantra of
"Backup to disk, Archive to tape". Archiving the backup savesets to tape is
very practical, and made easy by NetWorker's staging capability. Like
cloning, staging will make a copy of a saveset onto another device; unlike
cloning, staging will delete the source saveset, freeing up the disk space.
Staging also supports knobs that you can set to automate it.
For discussion, how about this solution:
o backup to local disk daily (using a schedule of fulls and incrementals)
[BACKUP]
o clone the backup savesets to disk at the central site daily [DR]
o stage the local savesets directly to a remote tape drive via iSCSI for
connectivity and NetWorker DDS to handle the drive sharing (and to make sure
that data isn't over-written)
Sorry for the many words; I hope they help. I'm VERY interested in this
discussion. Please ask me questions about what I've written.
Thanks
tl
Terry Lemons
CLARiiON Applications Integration Engineering
EMC²
where information lives
4400 Computer Drive, MS D239
Westboro MA 01580
Phone: 508 898 7312
Email: Lemons_Terry AT emc DOT com
-----Original Message-----
From: Cyndi Smith [mailto:Cyndi.Smith AT ASPENTECH DOT COM]
Sent: Monday, March 17, 2003 3:37 PM
To: NETWORKER AT LISTMAIL.TEMPLE DOT EDU
Subject: [Networker] Remote backups using legato
We have some very small (<100GB of data) remote sites. They are backed up
using a variety of methods ranging from not at all, to NT Backup, to local
Legato on a small tape changer.
We would like to standardize methods and also reduce the administration
overhead for backups at these remote sites.
Suggestions have included
1. standardizing on local Legato install (major drawback is need for
local administration of tapes, etc. plus the need to purchase a few more
licenses)
2. using an off-site (outsourced) backup solution such as LiveVault
(major drawback is cost)
3. using remote replication to disk at one of our "major" sites and
backing up that disk using our regular methods (major drawback is necessity
of purchasing and maintaining replication software such as Double-Take)
4. backing up over our WAN using Legato from one of the "major"
sites (major drawback is potential network bandwidth issue)
Option 1 requires remote monitoring of the Legato backups plus an on-site
(non-IS) person willing to change tapes under the direction of a remote IS
person). It would also necessitate purchasing some Legato licenses.
Options 3 and 4 would necessitate purchasing disk space to replicate the
data.
Options 2, 3 and 4 would likely necessitate purchasing more network
bandwidth -- 4 more than 2 or 3 since they do byte level incrementals.
Are there any other issues with option 4? Does this require any sort of
special license from Legato? We have plenty of server and client licenses to
handle this option - as long as no other special license is needed.
Has anyone else gone through this sort of exercise? What did you decide and
why?
Thanks for any input.
Cyndi
---
Cyndi Smith
Senior System Support Engineer - Unix
Aspen Technology, Houston, TX
--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
|
