ADSM-L

[ADSM-L] Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] vtl versus file systems for pirmary pool

2011-09-28 09:16:24
Subject: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] vtl versus file systems for pirmary pool
From: Daniel Sparrman <daniel.sparrman AT EXIST DOT SE>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 28 Sep 2011 14:13:04 +0200
It's not so much the amount of data as the amount of clients though Dave. I 
dont mind having a few nodes backing up straightly to the VTL (my database 
servers are doing just that), but having 1000 nodes mounting 1000 virtual tapes 
in the VTL is what I'm trying to avoid with having a small random pool infront. 
Especially if you're using resourceutil on your nodes.
 
Regards
 
Daniel


Daniel Sparrman
Exist i Stockholm AB
Växel: 08-754 98 00
Fax: 08-754 97 30
daniel.sparrman AT exist DOT se
http://www.existgruppen.se
Posthusgatan 1 761 30 NORRTÄLJE



-----"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> skrev: -----


Till: ADSM-L AT VM.MARIST DOT EDU
Från: "Ehresman,David E." <deehre01 AT LOUISVILLE DOT EDU>
Sänt av: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Datum: 09/28/2011 14:46
Ärende: Re: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] vtl versus file 
systems for pirmary pool

I guess it just goes to show 'that your mileage may vary'.  We've been happily 
backing up 3-5 TB a night to VTL as primary storage with no random disk 
frontend for four years now.

David

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Daniel Sparrman
Sent: Tuesday, September 27, 2011 2:45 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] Ang: Re: [ADSM-L] Ang: Re: [ADSM-L] vtl versus file systems 
for pirmary pool

Just to put an end to this discussion, we're kinda running out of limits here:
 
a) No VTL solution, neither DD, neither Sepaton, neither anyone, is a 
replacement for random diskpools. Doesnt matter if you can configure 50 drives, 
500 drives or 5000 drives, the way TSM works, you're gonna make the system go 
bad since the system is made from having random pools infront, sequential pools 
in the back.  A sequential device is not gonna replace that, independent being 
a sequential file pool or a VTL (or, for that question, a tape library).
 
b) VTL's where invented because most backup software (I've only worked with 
TSM, Legato & Veritas aka Symantec) is used to working with sequential devices. 
That havent changed, and wont change in the near future. VTL's (and the file 
device option) is just a replacement. Performance wise, VTL's are gonna win all 
the time compared to a file device, question you need to ask yourself is, do I 
need the VTL, or can I go along with using file devices. According to the TSM 
manual (dont have the link , but if you want i'll find it) the maximum 
supported file device pool for deduplication is 6TB... so if you're thinking of 
replacing a VTL with a seq. file pool, keep that in mind. The limit is because 
the amount of resources needed by TSM to do the file deduplication is limited, 
or as the manual says, "until new technologies are available".
 
The discussion here where people are actually planning on just having a 
sequential pool (since noone is actually discussing that there's a random pool 
infront) is plain scary. No sequential device is gonna have their time of the 
life having a fileserver serving 50K blocks at a time.
 
So my last 50 cents worth is:
 
a) Have a random pool infront
 
b) Depending on the size of your environment, you're either gonna go with a 
filepool and use de-dup (limit is 6TB for each pool, you might not want to 
de-dup everything), or you're gonna go with a fullscale VTL. Choice here is 
size vs costs.
 
I've seen alot of posts here lately about the disadvantages with VTL's .. well, 
I havent seen one this far with mine. I have a colleague who bought a XXXX VTL 
and found out he needed another VTL just todo the de-dup, since one VTL wasnt a 
supported configuration to do de-dup. I have another colleague who bought a 
very cheap VTL solution (from a very mentioned name around here) and ended up 
with having same hashes, but different data, leaving him with unrestorable data.
 
Comparing eggs to apples just isnt fair.  Different manufactures of VTL's do 
different things, meaning both performance and availability is completely 
different.
 
Just to sum up, we've had both 3584's and (back in the days) 3575, and I've 
never been happier with our VTL (and yes, we do restore tests).
 
Best Regards
 
Daniel



Daniel Sparrman
Exist i Stockholm AB
Växel: 08-754 98 00
Fax: 08-754 97 30
daniel.sparrman AT exist DOT se
http://www.existgruppen.se
Posthusgatan 1 761 30 NORRTÄLJE



-----"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> skrev: -----


Till: ADSM-L AT VM.MARIST DOT EDU
Från: Rick Adamson <RickAdamson AT WINN-DIXIE DOT COM> Sänt av: "ADSM: Dist 
Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Datum: 09/27/2011 18:02
Ärende: Re: [ADSM-L] Ang: Re: [ADSM-L] vtl versus file systems for pirmary pool

Interesting. Every VTL based solution, including data domain, that I looked at 
had limits on the amount of drives that could be emulated which were nowhere 
near a hundred let alone a thousand. Perhaps it's time to revisit this.

The license is a data domain fee, and a hefty one at that. 

The bigger question I have is since the file based storage is native to TSM why 
exactly is using a file based storage not supported?

~Rick


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Daniel Sparrman
Sent: Tuesday, September 27, 2011 10:30 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] Ang: Re: [ADSM-L] vtl versus file systems for pirmary pool

Not really sure where the general idea that a VTL will limit the number of 
available mount points.

I'm not familiar with Data Domain, but generally speaking, the number of 
virtual tape drives configured within a VTL is usually thousands. Not sure why 
you'd want that many though, I always prefer having a small diskpool infront of 
whatever sequential pool I have, and let the bigger files pass the diskpoool 
and go straightly to the seq. pool.

As far as for LAN-free, the only available option I know of is SANergy. And 
going down that road (concerning both price & complexity) will probably make 
the VTL look cheap.

Not sure what kind of licensing you're talking about concerning VTL, but I 
assume it's a Data Domain license and not a TSM license? 

Best Regards

Daniel Sparrman



Daniel Sparrman
Exist i Stockholm AB
Växel: 08-754 98 00
Fax: 08-754 97 30
daniel.sparrman AT exist DOT se
http://www.existgruppen.se
Posthusgatan 1 761 30 NORRTÄLJE



-----"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> skrev: -----


Till: ADSM-L AT VM.MARIST DOT EDU
Från: Rick Adamson <RickAdamson AT WINN-DIXIE DOT COM> Sänt av: "ADSM: Dist 
Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Datum: 09/27/2011 16:52
Ärende: Re: [ADSM-L] vtl versus file systems for pirmary pool

A couple of things that I did not see mentioned here which I experienced 
was.... for Data Domain the VTL is an additional license and it does limit the 
available mount points (or emulated drives), where a TSM file based pool does 
not. Like Wanda stated earlier depends what you can afford !

I myself have grown fond of using the file based approach, easy to manage, easy 
to configure, and never worry about an available tape drive (virtual or 
otherwise). The lan-free issue is something to consider but from what I have 
heard lately is that it can still be accomplished using the file based storage. 
If anyone has any info on it I would appreciate it.

~Rick
Jax, Fl.

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Tim Brown
Sent: Monday, September 26, 2011 4:05 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] vtl versus file systems for pirmary pool

What advantage does VTL emulation on a disk primary storage pool have

as compared to disk storage pool that is non vtl ?



It appears to me that a non vtl system would not require the daily reclamation 
process

and also allow for more client backups to occur simultaneously.



Thanks,



Tim Brown
Systems Specialist - Project Leader
Central Hudson Gas & Electric
284 South Ave
Poughkeepsie, NY 12601
Email: tbrown AT cenhud DOT com <<mailto:tbrown AT cenhud DOT com>>
Phone: 845-486-5643
Fax: 845-486-5921
Cell: 845-235-4255




This message contains confidential information and is only for the intended 
recipient. If the reader of this message is not the intended recipient, or an 
employee or agent responsible for delivering this message to the intended 
recipient, please notify the sender immediately by replying to this note and 
deleting all copies and attachments.
<Prev in Thread] Current Thread [Next in Thread>