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@VM.MARIST.EDU] De la part de
Schneider, Jim
Envoyé : 27 décembre 2012 11:18
À : ADSM-L@VM.MARIST.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@VM.MARIST.EDU] On Behalf Of
Ehresman,David E.
Sent: Tuesday, December 18, 2012 2:38 PM
To: ADSM-L@VM.MARIST.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@VM.MARIST.EDU] On Behalf Of Lee,
Gary
Sent: Tuesday, December 18, 2012 2:10 PM
To: ADSM-L@VM.MARIST.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@VM.MARIST.EDU] On Behalf Of
Welton, Charles
Sent: Tuesday, December 18, 2012 11:10 AM
To: ADSM-L@VM.MARIST.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.
