replication from instant recovery?

[robg]

Hello, I have an extremely large VM (approaching 4TB) - and I am trying to determine the best fast-recovery scenario, using backups.

Replication is not really viable at this time due to only one server being on-site, although there is one off-site with limited space.

So my idea is to use the instant recovery feature and run the VM from the backup, if the host needs replacing. The problem is, the only step after that seems to be "migrate to production" which is just a VM copy job.

What if that job takes 20+ hours to run, and I cannot be down for that long. I assume there is no way to run that VM copy job in parallel, that way the production can be switched back on from the backup with no disruption?

thanks

[dellock6]

You are missing the fact that the vm is completely up and running during the entire time it is powered on from the backup.
Migrate to production is indeed the next step of instant recovery, because you don't want to run always this vm from a compressed and deduped backup file, but rather from the production storage you have.

[robg]

You are missing the fact that the vm is completely up and running during the entire time it is powered on from the backup.
Migrate to production is indeed the next step of instant recovery, because you don't want to run always this vm from a compressed and deduped backup file, but rather from the production storage you have.

Thanks "evangelist," but I am not missing that fact.

Ok, so that's great, the VM is up and running again fast. But it can't stay running on the backup device forever. Not to mention, that backup device needs to return to its backup duty as soon as possible. The VM cannot stay down for the duration it takes to migrate back to production, offline.

[dellock6]

Seems there's some misunderstanding. The vm is not down during the migration back to production, either you use native storage vmotion of the hypervisor or if it's not in your license there's Veeam quick migration.
Yes, the backup file is locked by the instant recovery, but if for example there's only this VM in the job, any other job can be executed during the operation.

Ps, evangelist is my official role in Veeam, not some bragging. Sorry if it sounds vain...

[robg]

Seems there's some misunderstanding. The vm is not down during the migration back to production, either you use native storage vmotion of the hypervisor or if it's not in your license there's Veeam quick migration.
Yes, the backup file is locked by the instant recovery, but if for example there's only this VM in the job, any other job can be executed during the operation.

Ps, evangelist is my official role in Veeam, not some bragging. Sorry if it sounds vain...

I haven't misunderstood anything, but it's possible that you have.

I don't have the license for storage vmotion, so quick migration can only run cold, that's not an option either.

So, back to my original question. I would like to be able to REPLICATE the VM to production from the live backup, because the running VM can stay up at the same for the *days* it might take replication to finish. Then, after hours re-run the replication which should be pretty quick after the first run has completed; and then the live backup can be discontinued.

[foggy]

Rob, do you mean the ability to replicate from the backup file (instead of pulling data from the source datastore, i.e. vPowerNFS)? In fact this is right what Quick Migration is doing, when performed to finalize Instant Recovery. Anyway,
replication approach would still require some VM downtime during failover, probably longer than during Quick Migration.

[robg]

Rob, do you mean the ability to replicate from the backup file (instead of pulling data from the source datastore, i.e. vPowerNFS)? In fact this is right what Quick Migration is doing, when performed to finalize Instant Recovery. Anyway,
replication approach would still require some VM downtime during failover, probably longer than during Quick Migration.

Replicating from backup wouldn't allow the VM to stay running during that process, though. Which is pretty important. Quick migration always says "cold migration" whenever I attempt it, because I don't have the Vmotion license.

This will require some further testing, as it stands I don't believe what I am asking for is possible unfortunately.

It would be nice to be able to define a backup repository as an iSCSI VMFS volume directly. That way in a recovery situation I wouldn't have to have a VM prepared with an iSCSI mounted windows volume just to recover from, and this scenario wouldn't be needed.

[foggy]

Replicating from backup wouldn't allow the VM to stay running during that process, though. Which is pretty important.

Have you tried that? In fact I'd expect replication from backup to work smooth while instantly recovered VM is running, there should not be any locks on backup file, both are just reading it.

Quick migration always says "cold migration" whenever I attempt it, because I don't have the Vmotion license.

Even during a cold switch, VM is down only for a short period of time when changes are transferred.

[robg]

Have you tried that? In fact I'd expect replication from backup to work smooth while instantly recovered VM is running, there should not be any locks on backup file, both are just reading it.
Even during a cold switch, VM is down only for a short period of time when changes are transferred.

It would be interesting to try, if Veeam were to allow a new replication job to commence from the instant-recovery.

In further consideration to reduce complexity here, I think I will just forego backups altogether and instead use replication to the backup NAS with 30 restore points. That would provide point-in-time file level recovery as well as instant recovery (by just adding the backup NAS iSCSI as a datastore, registering it and starting it).

[foggy]

For Veeam B&R replication, NAS is not enough, you would need a second host to serve as replication target, where replica VMs will reside. And in this case, your "instant" recovery would be just a failover to a replica VM. (Also, note that replication jobs have maximum of 28 restore points retention.)

[robg]

For Veeam B&R replication, NAS is not enough, you would need a second host to serve as replication target, where replica VMs will reside. And in this case, your "instant" recovery would be just a failover to a replica VM. (Also, note that replication jobs have maximum of 28 restore points retention.)

Thanks, I am aware of that. They don't have the budget at this time to leave an additional server with that much space running for that purpose. I can go "borrow" another one in the event of failure.. it's not the best situation, but what can you do.

[foggy]

So are you talking about some NAS-level replication than?

[robg]

So are you talking about some NAS-level replication than?

No, the (only) server has 2 datastores defined, its local storage and then the NAS. The production VM is on local storage, but It is possible to replicate a VM just from one datastore to the other, same host, the replica target will be in the 2nd datastore (iSCSI NAS).

The replacement server is brought in, attaches to the NAS and the VM is started up with little downtime. No failover process though, it's all manual. Sounds viable?

[tsightler]

It would be interesting to try, if Veeam were to allow a new replication job to commence from the instant-recovery.

To answer this specific question, it is totally possible to replicate a VM that has been instantly recovered. The primary difference between using replicaiton and choosing failover to production, is that with failover to production, in the abscence of Storage vMotion, uses the Veeam "quick migration" feature, which copies the bulk of the VM disk, then suspends the VM and copies the remaining difference, then resumes the VM. Typically using quick migration the VM is down for only a few minutes of the entire migration process (at the end), but there's no option to "choose" when that downtime happens so if you have a large VM and you want to make sure the failover happens after hours this option can be less than ideal. Using replication means you can choose the exact failover time.

At this point though it sounds like you have a very workable plan of simply using local replication directly to the NAS box.

[robg]

To answer this specific question, it is totally possible to replicate a VM that has been instantly recovered. The primary difference between using replicaiton and choosing failover to production, is that with failover to production, in the abscence of Storage vMotion, uses the Veeam "quick migration" feature, which copies the bulk of the VM disk, then suspends the VM and copies the remaining difference, then resumes the VM. Typically using quick migration the VM is down for only a few minutes of the entire migration process (at the end), but there's no option to "choose" when that downtime happens so if you have a large VM and you want to make sure the failover happens after hours this option can be less than ideal. Using replication means you can choose the exact failover time.

At this point though it sounds like you have a very workable plan of simply using local replication directly to the NAS box.

Perfect, this is the answer I was looking for. I knew it would come eventually! Very encouraging and motivates me to test out the instant recovery option, that's still on the table although replication seems simpler. thanks

[robg]

This is very interesting, and I am glad the software is so flexible. I have a test VM running from instant recovery PowerNFS and am in the process of replicating that back to the same server on its local datastore, which would effectively simulate the restore process.

I did get an error about low space on the production datastore. We can't have that with a 4TB VM of course; I assume this just a matter of changing the default path of PowerNFS in the repository to point back to the same drive that the backup resides on?

[robg]

Major bummer about this method. If the server is turned off, loses power or whatever reason and the PowerNFS session has to be restarted, all the changes from the last run are lost! That would be pretty detrimental for a large VM that might take 24 hours to move back into production.

I can see how the instant recovery feature would be handy for small VMs where a fast re-migration is possible, but perhaps it can be improved in the future for the changed data to be re-incorporated into the backup file, or I'm just missing something.. I'll have to go back to the replica method for now