Control files...

[c.j.hund]

Hi all,

I just inherited a TSM4VE installation where there is no separate disk pool for VM control files, so presumable everything is going from staging disk to tape. How big a deal is that? Best practice has those control files going to a disk pool where they are not migrated to tape.

Sincere thanks,
C.J.

 

[zsoltesz]

The restore will be significantly faster if you store the control file in a separate disk pool.Zoli

 

[marclant]

Zxoltesz is right. Restores are much slower with control files on tape, if affects backups too because the latest control files are restored during the backup to determine what has changed.

 

[c.j.hund]

Zxoltesz is right. Restores are much slower with control files on tape, if affects backups too because the latest control files are restored during the backup to determine what has changed.

That's what I thought, too. I just wanted to make sure the restore is still possible, because a small, persistent disk storage pool did not get carved out for use with control files.

 

[Silapen]

I have a situation where my control files accidentally ended up in tape stgpool. Backup and restore drastically degraded. I'm trying to find a way to get the control files back on a separate disk pool. Any help is appreciated (not enough space to get back everything on disk).
I have tried updating mgmt class, and doing another backup, that didn't help. Next idea is to delete everything and start from scratch, and if needed, use restore from copy pool, but I'm not sure it will work?

 

[manner]

Hi,


im handeling with the same problem . I started backuping my vcenter into tsm with tsm ve. My way of backup following.:


TSMVE -> TSM Diskpool -> LTO 6 and a CopyPool


I backuped all together, vmware Data and controlfiles in the same pool. So when I started a recovery for one vmware-maschine I get poor performance, because vm data und control files are in the same storagepool.

After reading a lot in the internet, I found a solution for my problem. I had to separet data and control files in different storagepools. I make a new disk storagepool for the control files with a management class and updatet the opt file for the datamover node.

VMMC "VM-BACKUP-MASCHINE"

VMCTLMC "VM-BACKUP-CTL"


I restarted the VM-Proxy Server, but the TSM wont seperat VM-Data and Controlfiles into the different storagepools.

 

[marclant]

Are you talking about new backups or previous backups? You have to keep in mind that the change you made will only affect new backups, not existing data.

Did you activate the policy after creating the new management class?

 

[manner]

i know that the change of the management class will only effect on new backups.

yes i activated the policy but it still uses the default managment class.

 

[marclant]

How did you determine that they were not going to VM-BACKUP-CTL? The .CTL are small enough that it may not change numbers of Q STG.

Can you check with this:
select * from backups where class_name='VM-BACKUP-CTL'

 

[manner]

because i see volumehistory on that storagepool file.

from your select statement i get no results.

 

[marclant]

Let's see if the management class is available to that node. From the client, can you do:
dsmc query mgmtclass -optfile={.opt file for VM backups}

Also, check if the client see the option in the option file, or if there is an override by the server
dsmc query option vm* -optfile={.opt file for VM backups}

 

[Silapen]

I have created new disk pool, new mgmt class and directed vmctl files into that pool. I have seen there are some stuff written in the new pool. The problem is that backup still needs old vmctl files on tape to create new backup and new vmctl files in disk pool. I hope that will eventually change, and that all of the necessary vmctl files will be on disk pool only. In the mean time, I had a disaster with my tape library, and now I'm waiting for hardware maintenance, so I can continue with this new setup. Will update this thread when possible.

 

[marclant]

As older backups expire, eventually most or all of .CTL will be in the new pool.

If you do a full backup of the VM, future backups will only need the .CTL from that point forward, which will be on disk.

 

[manner]

hi,

sorry for my late feedback. now my vmware gets backuped right. control and data files get stored in different storagepools. my mistake was that i choose the wrong .opt file for the windows service which makes the backups.

thanks for the help.

daniel

 

[nags]

Hi ,

We are facing the same problem. But our issue was we had a seperate CTL pool but it migrated to tape. Now we gave more disk space on the CTL pool and stopped migration. But VM backups wont run because the CTL files are on tapes and no way of bringing those CTL files alone back to the disk. So I am doing a full backup of the VM which is really taking a lot of time.

How did you get the issue fixed without having to do a full backup of the VM.

 

[Silapen]

AFAIK, there is no way to move CTL from tape to disk. I started few full backups after setting the mgmt class, and the CTL files are now in the disk pool, but still some old CTL files reside in tapepool. Also, I have noticed that restore takes long because same session mounts the same tape volume over and over again. First I thought that it was problem of collocation, then I tested with restore of only one filespace for test vm, which was on a single tape, and tere were multiple mounts/dismounts of the same volume from the same restore session. It took forever to restore.

 

[nags]

Thanks. So there is no option around other than running a full backup ? One full backup and then rest all ran fine. But I want to know if there is an alternate to IFfull backup method to resolve this .ctl file issues, so that the IFIncremental can run fine

 

[nags]

My issue is resolved. As per recommendation the .ctl SHOULD be on a random access disk. But my .ctl files were on tape which still was ok in order to run an IFIncremental as a temp solution.
The real issue was:
We had some tapes that were in unavailable status and so the IFIncremental failed being unable to read those .ctl files.
So we updated the tapes to readwrite. Ran IFIncremental and it was able to read the .ctl files from tapes too.

As a permanent fix, I increased space on the VMCTL disk stgpool and removed the next stgpool value and made it null, so migration never runs to tape. IBM strictly recommends the .ctl file to be on disk pools.