ADSM-L

Re: [ADSM-L] Reclamation of Virtual Tapes

2012-12-28 17:32:53
Subject: Re: [ADSM-L] Reclamation of Virtual Tapes
From: Alex Paschal <apaschal5 AT FRONTIER DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 28 Dec 2012 14:30:58 -0800
Pierre, Jim, having read your observation of read performance impact with your Data Domain and your DXi, do you guys have thoughts on how you might handle a full server recovery or other large restore during your backup window? Do you think you might be forced to stop all backups in order to get a large restore done before 6am/8am/whatever production, or is there possibly a workaround?


On 12/27/2012 12:51 PM, Billaudeau, Pierre wrote:
I noticed a serious performance drop when our backup primary tapes to copypool runs at 
night (VTL Quantum DXi8500 to TS1140 tapes). The throughput of backups to VTL drops when 
the DXi "rehydrates" the deduplicated/compressed virtual tapes. I can imagine 
the reclamation process does the same thing. There is a need to adjust maintanance 
schedules to avoid the situation.

Pierre Billaudeau
Analyste en stockage
Livraison des Infrastructures Serveurs
Société des Alcools du Québec
514-254-6000 x 6559

-----Message d'origine-----
De : ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] De la part de 
Schneider, Jim
Envoyé : 27 décembre 2012 11:18
À : ADSM-L AT VM.MARIST DOT EDU
Objet : Re: [ADSM-L] Reclamation of Virtual Tapes

Our primary (and only) storage is a Data Domain.  Be careful when reclaiming 
virtual tapes.  It works perfectly but servers backing up to the Data Domain 
have their bandwidth throughput drop from 85% to 5% during reclamation.  This 
was determined by watching Windows Task Manager network utilization with 
reclamation running and then cancelled.

Our reclamation threshold is set at 95% and runs for about 20 minutes.  The SQL 
storage pool that holds 1.1 TB files is set at 99% to effectively prevent 
reclamation.  We had a bad weekend where reclamation started Friday at 5 PM and 
was 60% complete Monday morning before being cancelled.  All of those weekend 
backups were slowed and the database backup ran 5 hours instead of 1.75 hours.

Don't make my mistakes!

Jim Schneider

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Ehresman,David E.
Sent: Tuesday, December 18, 2012 2:38 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Reclamation of Virtual Tapes

We reclaim our virtual tapes.  They have the same waste patterns as physical 
tape and are certainly as expensive.

David

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Lee, Gary
Sent: Tuesday, December 18, 2012 2:10 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Reclamation of Virtual Tapes

Sounds like someone set the reclaim storage pool on the virtual tape pool to 
the physical tape pool.

I know of no reason why not to reclaim virtual tapes.

Wish I had one to play with.


Gary Lee
Senior System Programmer
Ball State University
phone: 765-285-1310



-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Welton, Charles
Sent: Tuesday, December 18, 2012 11:10 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] Reclamation of Virtual Tapes

Hello:

We have a TSM instance that uses virtual tapes as our primary backup data pool. 
 The data on the virtual tapes are eventually migrated to tape.  We are 
currently down to 3 virtual scratch tapes and 6 physical scratch tapes.  I 
noticed that we are not running any reclamation processes on our virtual tape 
pool.  It seems we have a hand-full of under-utilized virtual tapes.  I went 
ahead and ran a manual reclamation on the virtual tape pool and I noticed the 
output tape pool is a physical tape.  I assumed that the virtual tape would 
reclaim to another virtual tape.  Is that not the case?

Could there be a reason why reclamation shouldn't be ran on a virtual tape pool?

Thank you...


Charles

This email contains information which may be PROPRIETARY IN NATURE OR OTHERWISE 
PROTECTED BY LAW FROM DISCLOSURE and is intended only for the use of the 
addresses(s) named above.  If you have received this email in error, please 
contact the sender immediately.

**********************************************************************
Information contained in this e-mail message and in any attachments thereto is 
confidential. If you are not the intended recipient, please destroy this 
message, delete any copies held on your systems, notify the sender immediately, 
and refrain from using or disclosing all or any part of its content to any 
other person.

------------------


Information confidentielle : Le présent message, ainsi que tout fichier qui y est joint, est envoyé à l'intention exclusive 
de son ou de ses destinataires; il est de nature confidentielle et peut constituer une information privilégiée. Nous avertissons 
toute personne autre que le destinataire prévu que tout examen, réacheminement, impression, copie, distribution ou autre 
utilisation de ce message et de tout fichier qui y est joint est strictement interdit. Si vous n'êtes pas le destinataire prévu, 
veuillez en aviser immédiatement l'expéditeur par retour de courriel et supprimer ce message et tout document joint de votre 
système. Merci.


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