Hey Stuart!
Thanks for the time spent in replying!
We have an unlimited autochanger license just sitting around doing
nothing, so that would probably alleviate some of the growth issues you
mentioned.
We do currently have 30TB on adv_file devices, but I less then thrilled
with them to be honest. I basically have to keep then less than 80%
full otherwise I run into problems. In my current environment, that is
~6tb wasted... as it grows that amount of wasted space will continue to
grow. That in part is why I was thinking VTL. What has your capacity
utilization been with your VTL? Another thought was to use adv_file on
ZFS then I could add incremental amounts of space to the device as
needed.
So do you keep all your levels in the VTL? Unless we go with dedup, I
would have to dump fulls to a silo, otherwise I was have to have a
massive vtl.
If I go with a VTL, and choose one that backends to a real silo, then
I'll just emulate the same type of drives I have now. If I chose one
that has to clone through networker, then I'll probably set it up to
emulate dlt7000s or something else small. My thinking is that then the
vtapes won't be tied up as much so their will be fewer conflicts.
Why do you say to separate the client types?
How much data do you backup a month?
Anyone else have any experience to share about these technologies?
Thanks!
Joel
________________________________
From: Stuart Whitby [mailto:swhitby AT dataprotectors.co DOT uk]
Sent: Wednesday, June 27, 2007 10:54 AM
To: EMC NetWorker discussion; Joel Fisher
Subject: RE: [Networker] VTL/Dedup
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
|
