Networker

Re: [Networker] VTL/Dedup

2007-06-27 10:55:18
Subject: Re: [Networker] VTL/Dedup
From: Stuart Whitby <swhitby AT DATAPROTECTORS.CO DOT UK>
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Date: Wed, 27 Jun 2007 15:54:19 +0100
No experience of any but the EMC Clariion Disk Library (which I hear is 
Falconstor based), but I'm not keen on VTLs.  If you're looking at a disk based 
solution, then I'd recommend a decent sized disk based Advanced File staging 
area with a physical tape library on the back end.
 
Going on my experience of the CDL, VTLs themselves aren't bad.  There are a 
couple of niggles with the CDL GUI, but it's behaved almost flawlessly with 
7.3.  However, the environment I'm currently working in was set up with a 25TB 
CDL as a 256 slot LTO1 library.  With a basic 256 slot autochanger license, 
this splits the 25TB nicely and uses all the space.  Then we added more disk.
 
Now we need to do media management tasks to move expired tapes into and out of 
the library, since there isn't enough space in the slots to hold the 35TB any 
more.  This is standard practice for a tape library, but shouldn't be necessary 
with a VTL (and wouldn't be if not for NW's slot-based licensing model).  We 
could change to LTO2, but that means having 200GB volumes set up, so we only 
get 175 tapes which won't expire as regularly since they hold more data.  
 
By going purely to a disk based solution, we've also had to move to a 
differential only policy.  To do a full backup on a weekly basis was killing us 
in terms of the disk space used, so we're down to a full once a year to be kept 
for 25 years, L1 once a month to be kept for a year, and L2-8 through the week 
to be kept for a month.  Sounds good until you add a filesystem to one of your 
servers.  Now you have a level 0 backup on your daily pool which will remain 
until all monthlies based on it expire in a year's time, and that's taking up 
200GB of space in your library.  I could put all full backups to the yearly 
pool, but SYSTEM_FILES, SYSTEM_DB and ASR savesets are always full.  This is 
impossible to filter given the pure "OR" logic of pool selection criteria.
 
The other huge problem of going for a pure VTL environment (which you don't 
specify here but I figure I'd throw in anyway) is that the VTL *NEEDS* to be 
based off-site.  Without doing that, you are at massive risk of losing all data 
in the event of datacentre loss.  The plus side is that it's a great get-out if 
the boss needs to start a fire to put paid to your next Enron scandal ;)
 
So if you're going to go down the VTL route, I'd recommend the following:
 
- Size your VTL requirements very carefully and configure appropriately to 
allow plenty of tapes without vaulting.
- 3 pools: Yearly (full), Monthly (L1) and Daily (L2-8).  Maybe a weekly as 
well if you need (L2).  
- Still have a tape library on the back end.  Yearly and monthly (& weekly?) 
data should have 2 tape copies - one clone for the event of RAID failure and 
another in archive for the event of site loss.  The tape library can be a small 
unit given the reliance on the VTL for recoveries.
- Yearly and monthly backups need to be well spaced out to allow the systems to 
use as few tapes as possible.  Or they should be sent across the network to the 
server if possible, allowing it to maintain only 2 part-used tapes for yearly 
backups.  This removes one of the VTL's main benefits of being able to provide 
large numbers of tape drives to multiple systems - unless you DDS it, and 
what's the point in that?  Another option to keep the data available and within 
the VTL is to clone to tape and back to a yearly clone pool with the original 
yearly tapes recycled.  
- Separate Unix, Windows and NDMP pools, with Unix and NDMP daily groups having 
their L0 backups going to the yearly pool.  Can't do this with Windows unless 
there's a directive to skip ASR etc.  
- Set strict savegroup parallelism values to cut down on the number of 
appendable tapes per pool.  If you have 50 tapes in use across a large number 
of servers in a big group, it's going to take a long time for all those tapes 
to fill up and, eventually, expire.
 
Should give you something to think about, at least :)
 
Cheers,
 
Stuart.
 

________________________________

From: EMC NetWorker discussion on behalf of Joel Fisher
Sent: Wed 27/06/2007 14:27
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Subject: [Networker] VTL/Dedup



Hey Guys,

Can anyone comment about their experience good/bad on the below products
in a Networker environment?

Diligent Protectier
Data Domain (any dedup/vtl product)
Copan Revolution(falconstor)
Sun STK VTL(falconstor)
Any other VTL/Dedup solutions

VTLs in general?  Prefer VTL or adv_file?

Thanks!

Joel




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

<Prev in Thread] Current Thread [Next in Thread>