-
-
Community Tip: Forum Rules (PLEASE CLICK HERE TO READ BEFORE POSTING)
Click the link above to access ADSM.ORG Acceptable Use Policy and forum rules which should be observed when using this website. Violators may be banned from this website. This notice will disappear after you have made at least 3 posts.
VMguest Archive
- Thread starter h2ohenke
- Start date
marclant
ADSM.ORG Moderator
There is no archive for VMs. For regular files, the purpose of an archive is long time storage of a group of files. So, if you need to keep the VM backup for a long time, you could do it through a few ways:
- increase the retention of the management class, will affect all VMs
- use the VMMC option for a given VM to send it to a different management class with longer retention
- use a different node to backup the VM with a different default management class
The last option might be best if you don't want to affect your regular backups, while keeping some for a long time.
- increase the retention of the management class, will affect all VMs
- use the VMMC option for a given VM to send it to a different management class with longer retention
- use a different node to backup the VM with a different default management class
The last option might be best if you don't want to affect your regular backups, while keeping some for a long time.
Mita201
ADSM.ORG Senior Member
I think there is no need for changing MC or nodename. Once you want to archive some VM, you just backup it, and that's it. It remains as active backup version, meaning forever, as long as you don't delete it on purpose from backup server. It won't get inactivated by following backups, since you do not backup it any more. One VM is one filespace for the node.
marclant
ADSM.ORG Moderator
That's true if it's a VM that is not backup regularly. The OP didn't specify if they were backing up regularly or not, but most people are.
Mita201
ADSM.ORG Senior Member
Regularly or not, unlike TSM BA file backup, TSM4VE will not update (inactivate) TSM server with data about removed VM. You need to do it manually, delete backup or expire it.
marclant
ADSM.ORG Moderator
Only true if he does a single backup, not true if he does regular backups. If he has a retention that keeps X number of versions, and backups more versions than X, older ones will expire. Also, if he wants to keep a single version 2 years, but his regular retention is 30 days, that won't work as well.
source: https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Tivoli Storage Manager/page/DP for VMWare FAQ for Tivoli Storage Manager for Virtual Environments?section=Q11a retention
Mita201
ADSM.ORG Senior Member
Ok, it becomes interesting now:
Retention settings in TSM apply to INACTIVE versions only. Active versions of backup are not going to be removed from TSM server never (except deliberately) as long as they are active, regardless of retention settings.
How backup becomes inactive?
With TSM BA client, during backup session, files are compared and inspected, in TSM server database (file metadata) and on filesystem of client. If file has been changed, it is sent againt to TSM server, and new ACTIVE version is created on TSM server. previous version that has been backuped before becomes INACTIVE, and falls under retention policy. Also, if BA client notice that there (on file server) are some files that is missing compared to data that exists in TSM database, it (BA client) expires that file on TSM server - inactivates it. There are no more active versions of the file on TSM server, retention apply to all copies that has been left on TSM server (sure you know there are two settings for case a and case b, verexists and verdeleted, retextra, retonly, and these stuff)
VM backup also have some similarity,
but,
there are differences as well:
There is no "automatic" way to inactivate latest backup version of VM backup (as far as I know). Actually, before TSM4VE 7.1 there was no way at all. Now you can do it deliberately, using BA cmd line client.
Regular VM backup (by schedule), as far as I know (may be wrong, but I will test it) will not inactivate previous active version if it finds that the machine is no more. It (the schedule) will simply fail.
Thus, last VM backup remains active, not falling under retention policy, as long as you do not do it explicitly (expire or delete it).
Retention settings in TSM apply to INACTIVE versions only. Active versions of backup are not going to be removed from TSM server never (except deliberately) as long as they are active, regardless of retention settings.
How backup becomes inactive?
With TSM BA client, during backup session, files are compared and inspected, in TSM server database (file metadata) and on filesystem of client. If file has been changed, it is sent againt to TSM server, and new ACTIVE version is created on TSM server. previous version that has been backuped before becomes INACTIVE, and falls under retention policy. Also, if BA client notice that there (on file server) are some files that is missing compared to data that exists in TSM database, it (BA client) expires that file on TSM server - inactivates it. There are no more active versions of the file on TSM server, retention apply to all copies that has been left on TSM server (sure you know there are two settings for case a and case b, verexists and verdeleted, retextra, retonly, and these stuff)
VM backup also have some similarity,
but,
there are differences as well:
There is no "automatic" way to inactivate latest backup version of VM backup (as far as I know). Actually, before TSM4VE 7.1 there was no way at all. Now you can do it deliberately, using BA cmd line client.
Regular VM backup (by schedule), as far as I know (may be wrong, but I will test it) will not inactivate previous active version if it finds that the machine is no more. It (the schedule) will simply fail.
Thus, last VM backup remains active, not falling under retention policy, as long as you do not do it explicitly (expire or delete it).
marclant
ADSM.ORG Moderator
Everything you said is correct, but if the OP does regular backups of the VM in question, then none of this apply to him and he will need a different node with a different retention to keep a specific backup of a VM longer than the retention they normally use since there is no archive functionality.
Alternatively, he could clone the VM, do a single backup of it, and that backup would remain active forever as long as no new backups of that cloned VM is done.
Alternatively, he could clone the VM, do a single backup of it, and that backup would remain active forever as long as no new backups of that cloned VM is done.
Mita201
ADSM.ORG Senior Member
Oh, ok, it looks like we were reading same question different ways.
as I red original question as:
Hi,
Is there a way to archive VM's in tsm4ve?
i.e. dsmc a /path/to/vm -deletefiles
If not, how have you solved the matter?
That -deletefiles makes me think that one wants to "bury" VM to backup server and to remove it from VM infrastructure. Looks like we both were right, just answering different question...
Regards,
m.
as I red original question as:
Hi,
Is there a way to archive VM's in tsm4ve?
i.e. dsmc a /path/to/vm -deletefiles
If not, how have you solved the matter?
That -deletefiles makes me think that one wants to "bury" VM to backup server and to remove it from VM infrastructure. Looks like we both were right, just answering different question...
Regards,
m.
