If you recover the VM metadata to a disk or filepool (diskpool is recommend by IBM btw) before restoring the vm's an offsite pool should give the same restore performance as an onsite pool given the same device class and tapedrive availability.
I think restoring incremental forever vm backups from tape isn't doable in most cases and you need to make periodic full's if you want to restore from tape, if you need tape but still want incremental forever (maybe because of your license/file device class usage) I would recommend restoring the entire storagepool to disk before restoring vm's. Restoring a filepool from tape and then restoring vm's from that filepool is faster than restoring vm's from tape if an incremental forever method was used, especially if you don't use filespace collocation for the vm's. On Wed, Apr 23, 2014 at 4:05 PM, Matthew McGeary < matthew.mcge...@potashcorp.com> wrote: > Yes, our copypool is on LTO4 tape. > > Thanks for the recommendation to restore the VMCTL storage pool. I'll add > it to my notes for the next test. Has anyone experimented with changing > the megablock refresh values? If I lower the threshold such that each > 128MB block is completely refreshed more often, I will increase my daily > intake amounts but potentially reduce the number of tapes that are needed > for a DR restore, correct? > > Matthew McGeary > Technical Specialist > PotashCorp - Saskatoon > 306.933.8921 > > > > From: "Ehresman,David E." <deehr...@louisville.edu> > To: ADSM-L@VM.MARIST.EDU > Date: 04/22/2014 12:36 PM > Subject: Re: [ADSM-L] TSM for VE going to tape copypool, > recommendations? > Sent by: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> > > > > I don't know how the VMCTL metadata is used. But I see multiple "files" > in the vmctl storage pool for a given VM which leads me to believe that > TSM will need to read more than one of those metadata entries for a given > VM restore. If that is true, I am guessing it would be a significant > benefit to restore them from tape to disk before beginning the VM > restores. By the way, are we talking about physical tape? > > David > > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of > Matthew McGeary > Sent: Tuesday, April 22, 2014 11:54 AM > To: ADSM-L@VM.MARIST.EDU > Subject: Re: [ADSM-L] TSM for VE going to tape copypool, recommendations? > > Yes, the VMCTL data is stored in its own stgpool with a FILE devc and we > could request additional disk for the test to use for the RESTORE STG > command. Would that be faster than restoring individual VM's? Should I > still look at collocating the VMCTL data on a single tape? > > Matthew McGeary > Technical Specialist > PotashCorp - Saskatoon > 306.933.8921 > > > > From: "Ehresman,David E." <deehr...@louisville.edu> > To: ADSM-L@VM.MARIST.EDU > Date: 04/22/2014 09:48 AM > Subject: Re: [ADSM-L] TSM for VE going to tape copypool, > recommendations? > Sent by: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> > > > > Is your PRIMARY VMCTL storage pool on FILE type disk? Can you create a > corresponding FILE storage pool at DR and do a RESTORE STGPOOL prior to > starting the VME restores? > > David > > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of > Matthew McGeary > Sent: Tuesday, April 22, 2014 11:28 AM > To: ADSM-L@VM.MARIST.EDU > Subject: [ADSM-L] TSM for VE going to tape copypool, recommendations? > > We've been using TSM for VE for about a year now and while it's been great > for onsite restores, our recent DR test was troubling. We've been using > the IFINCR strategy and while I was expecting restores from tape to be > slow, I wasn't expecting restores to drag into the 5-6 hour range for a > small VM (40 GB.) I know that the admin guide recommends periodic-full > for VM tape retention, but we use dedup disk onsite and we're already > experiencing pressure on our daily backup intake volumes and disk usage, > so I'd prefer not to have to change our backup strategy due to the > increase caused by periodic-full in both daily traffic and storage. > > Is there any other way I could conceivably improve restore times from a > tape copypool while still using IFINCR as my backup method? Here are a > few things I considered: > > 1) A separate collocated copypool for the VECTL data. This would live on > one tape easily and would reduce the number of mounts required for a > restore. However, if that tape goes bad, I'm totally screwed in a DR > situation because there's no way to restore VM backups without the control > files. I'm assuming that if I use collocation by node, TSM will generate > a new tape every day with all the CTL files and call back the old one. Am > I right in that assumption? > 2) Could I do an IFFULL backup every few weeks or even every month to > limit tape mounts? > 3) ??? > > If anyone with some practical experience in using TSM for VE with tape > copypools could offer some guidance, I'd appreciate it. > > Thanks, > > Matthew McGeary > Technical Specialist > PotashCorp - Saskatoon > 306.933.8921 >
