There are two reasons that you might not want to turn on compression,
and they don't always apply.
1. Some vendors use software compression and it adds space but slows
down the backup. Yuck. Vendors are starting to do hardware compression
by using the same kind of chip your tape drive uses. Lovely.
2. Integrated VTL configs (where you will eject the virtual tape and
have that copied by the VTL to the physical tape it's presenting to be)
need to match the size of the virtual and physical tape. If they
compress (even with hardware compression), they might use a different
compression algorithm that's more efficient, and store more data on the
virtual tape than what will fit on the physical tape. Very bad if that
happens. The ways around this are:
a. Don't use the integrated model. A lot of people opt for this. Use
your backup software to copy from virtual to physical. The backup s/w
will be happier, too.
b. Set the size of the virtual tape to a very conservative number.
(e.g. real tape is 50 GB native. Set the native size of the virtual
tape to 35 GB. That should deal with most differences in compression.)
The downside to this is that you waste real tape. Bummer. It is what
it is.
c. Don't compress your virtual tape at all. Big waste of disk AND real
tape.
d. Use an integrated vendor that samples the compression ratio and stops
the virtual tape at an appropriate point. (e.g. It knows it's using the
same compression (or less efficient) algorithm than what the tape drive
uses. It then watches the data and sees that it is compressing 2:1, so
it knows to stop the virtual tape right at (or just shy of) 50 GB
native, allowing it to fill more of the real tape.
---
W. Curtis Preston
Backup Blog @ www.backupcentral.com
VP Data Protection, GlassHouse Technologies
-----Original Message-----
From: Conrad Macina [mailto:conrad.macina AT PFIZER DOT COM]
Sent: Thursday, August 23, 2007 3:35 AM
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU; Curtis Preston
Subject: Re: new to Virtual Tape Library - what are the benefits?
Thanks very much, Curtis, for an excellent summary. It will be very
helpful.
You touched on compression, but I still have questions. One vendor told
us
that with most VTLs you can't use compression, because the VTL can't
compress identically the same as the drive will. You could end up with
more
data on a virtual tape than will fit on the correspondnig physical tape
and
therefore, in your words, "badness". The vendor's product, of course,
worked
around this issue. How are real-world users addressing the situation?
Thanks again,
Conrad Macina
Pfizer, Inc.
On Wed, 22 Aug 2007 19:35:38 -0400, Curtis Preston
<cpreston AT GLASSHOUSE DOT COM>
wrote:
>I've read this whole thread now and wanted to comment on it with a
>little more thought...
>
>I in favor of VTLs or other intelligent disk targets (IDTs). It's not
>necessarily whether or not it's pretending to be tape; it's whether or
>not it deals with the issues of using "regular" disk, which are:
>
>1. Difficult to share between multiple storage nodes - must partition
>
>2. When partitioning for multiple SNs, you have to decide how big to
>make each slice.
>
>3. 1:1 relationship between size of backups and size of disk (i.e. no
>compression or de-dupe)
>
>4. Fragmentation: users have reported issues with using filesystems as
>targets for extended periods of time unless they're clearing the
>filesystem every night.
>
>IDTs remove with these issues:
>1. Easy to share - with a VTL, use DDS in NW or just make multiple
VTLs.
>With a NAS IDT (Data Domain, NEC Hydrastor), just point a share at it.
>
>2. Do not have to partition by storage node or even NetWorker server.
>Whatever storage a SN uses, it uses.
>
>3. Some have hardware compression and others have de-dupe. I've seen
>it; it's real. And my opinion is that as long as you're also copying
>everything to tape, I've got no issues with using de-dupe at this
stage.
>
>4. Fragmentation does not seem to be an issue as they use a MUCH larger
>block size that's better suited to backups. Fragmentation issues have
>also not been reported.
>
>Issues:
>
>1. There is the issue with managing migration to tape. With NetWorker,
>there are easy ways and hard ways.
>
>With disk/AFTD, you would use the disk staging facility in NW. It will
>automatically stage backups to tape from disk, and delete de-staged
>backups to make room for new babckups.
>
>With an integrated VTL (like the EMC CDL, IBM, Sun, Falconstor, NetApp,
>et al), you can have the CDL manage the migration. It sits between
your
>networker server and the physical tape library (PTL). It inventories
>the PTL and represents to the NW server virtual tapes with the same
>barcode and capacity as the real tapes. You back up to the fake tapes
>and eject them. It then automatically copies them to physical tape.
>
>If you don't like either of these options, the "hard way" is to script
>your way into happiness. If you like this method, there's not much
>difference between an AFTD and a VTL/IDT from a migration perspective.
>
>2. There's also the issue where you can't expire a tape until all its
>backups expire. This is no different than physical tape. I think this
>is pretty easy to deal with. Either use really small virtual tapes or
>mark your tapes as full with a script after each night's backups. A
400
>GB tape marked full in a VTL won't take up 400 GB, so that's OK. That
>way, each night's backups are on their own set of tapes, causing all of
>them to be expired when those backups expire. (You also need to
>segregate by retention period if this is to work well -- just like with
>real tape.) You don't have this issue with an AFTD as it can expire
>individual savesets, but I think that an AFTD comes with too many other
>problems in large NW environments.
>
>3. If you use an integrated VTL, there is the issue of matching virtual
>to physical size. The big thing is that virtual tape MUST fit on the
>physical tape. Some VTLs allow you to pick the point at which the
>virtual tape is full. If you pick a size that's too big, you won't fit
>onto the physical tape and you've got badness. I like the new feature
>of "right sizing," where the VTL figures out when to stop by sampling
>the data that's coming through and seeing how well it's compressing.
>
>4. The license issue. As long as EMC makes it an option, it's not a
new
>license they're trying to force down your throat. It's an optional
>license that allows you to configure your VTL any way you want (e.g.
>number of slots, etc.). As long as you stick with the "real" license,
>you're limited to what you paid for. Don't forget that AFTD costs
>money, too!
>
>I hope this helps.
>
>---
>W. Curtis Preston
>Backup Blog @ www.backupcentral.com
>VP Data Protection, GlassHouse Technologies
>
>To sign off this list, send email to listserv AT listserv.temple DOT edu and
type
"signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
>via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
>=======================================================================
==
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
|
