VMWare backups and archive copies/archiving

[Teet]

Hello.

I'm currently backing up vm's from VMWare using TDP for VMWare to directory container storage pool and the retention periods vary 7-14 days. I'm looking a way to make archives/archive copies of these VMWare backups for longer retention (for example monthly copy with some months retention) without making a whole new full backup to another node/storage pool with longer retention, as I know that backupset's are out of the question with non-file backups, are there any other way You know/can recommend to me?

I've read about export node (to tape) command but does it work with VMWare data and can the previously described be achieved by using this command?

Manually controlling archive copies retention wouldn't be a problem if export node can be used.

Thanks In Advance.

Teet Saar.

 

[RecoveryOne]

As far as I know you cannot export data out of a container pool.
Quick overview of directory container pools.

To share some insight that was given to me in the past, setup a different management class inside your policy set that's using your container storage pool. Then use the vmmc and the vmctlmc for your 'archive'. Just remember, these won't be an archive in the true sense, just a full backup that will last $days. May want to open a PMR or perhaps someone here can provide more insight if the control files (vmctlmc) should be bound to the different management class as well for your 'archive' backup. Apologies, memory failing me on that part.

The nice thing about putting this fake archive/longer term backup retention into the same directory container pool is you will still benefit from the deduplication and compression. And then less hassle trying to protect two different container pools.

I believe same situation arises for archives with any TDP product, even if you weren't using a container storage pool.
As moon-buddy said a while ago when the question of archives for TDPSQL came up:

There is no real archive for TDP. What you can do is extend the TDP backup retention period or dump the database and archive the dump using the BA client.

Just in your situation (I'm faced with similar situation involving VM's + archives of said VM's), if you absolutely must have a true archive of a VM, the two best way's I can I can think of is:

1. Export the vmdk and archive that file with a BA-client.
2. Install the BA-client on the guest OS, and then archive the node that way.

Hope it helps.

 

[Teet]

As far as I know you cannot export data out of a container pool.
Quick overview of directory container pools.

To share some insight that was given to me in the past, setup a different management class inside your policy set that's using your container storage pool. Then use the vmmc and the vmctlmc for your 'archive'. Just remember, these won't be an archive in the true sense, just a full backup that will last $days.

I'm doing that already for keeping 7 versions(days) of some specific vm's and keeping 30 versions(days) of other specific vm's and I have vmctl mgmtclass configured similarly to the 30 days/versions mgmtclass.

Would it be possible to create a whole new schedule, mgmtclass, node combo and make a whole new ifincremental backup line to the new node for keeping basically another set of backups of the same vm's but with retention of for example 12 version with ifincremental every month? I know that this is possible with other backup software's (for example Veeam) but would it be possible with TSM?

Thanks In Advance.

Teet Saar.

 

[Teet]

I've seem to be found an article that seems to describe exactly what I want to do, testing it now.

Article: http://www-01.ibm.com/support/docview.wss?uid=swg21688752

Teet Saar.

 

[RecoveryOne]

I've seem to be found an article that seems to describe exactly what I want to do, testing it now.

Article: http://www-01.ibm.com/support/docview.wss?uid=swg21688752

That looks like a very elegant solution. Couldn't get back to you sooner was busy the other day.

 

[Teet]

That looks like a very elegant solution. Couldn't get back to you sooner was busy the other day.

Just tested it, seems to be working.

 

[Teet]

Hello again, I've tested the solution and it seems to be working altough I have some doubts about it:

* I have 2 backup 'lines'- one ifincremental keeping 7 days/versions of backups and iffull keeping 6 months/versions of backups
* The previous linked article states that "Note that the schedule uses -MODE=IFFull to perform an "incremental forever full backup (IFFULL)" backup. This is necessary so not to interfere with the "Change Block Tracking (CBT)" mechanism used by the daily "incremental forever incremental backup (IFINCR)" backups."

Is it certain that the second schedule's iffull doesn't interfere with first schedule's ifincremental, for example if I'm using daily ifincremental to make incremental backups one friday and months first weekend's saturday the second iffull schedule kicks-off, doesn't the second iffull zero-out the vmware cbt data that was collected since the last ifincremental from friday and on monday (when the ifincremental is scheduled to run again) the cbt data is not from friday but from saturday when the iffull was made? Or is the TSM VE smart enough to not to break the friday's cbt data until monday? This article states that iffull resets the CBT: http://www-01.ibm.com/support/docview.wss?uid=swg21973323&acss=danl_2860_web

Thanks In Advance.

Teet Saar.

 

[RecoveryOne]

This article states that iffull resets the CBT: http://www-01.ibm.com/support/docview.wss?uid=swg21973323&acss=danl_2860_web

That link seems to be taking about a bug with VMWare and looks to have been resolved: "this issue is resolved in VMware ESXi 6.0 patch ESXi600-201511001"

Beyond that I haven't had the chance to make headway with longer term retention in our VM Environment. Sorry, not much help.

 

[Teet]

Hello again.

After reading a bit on vmware cbt, I think the more accurate question might be- does the iffull made by another/second datamover reset the cbt changeid to 0 as described here http://www-01.ibm.com/support/docview.wss?uid=swg21681916 ? Therefore if the initial/first datamover asks for blocks with changeid for example 1 since it's last backup but doesn't get the blocks, only the blocks since the last full by prementioned another/second datamover.

Correct me if I understood something wrong about cbt or anything else.

Thanks In Advance.

Teet Saar.