That would be more convenient except I am not provided room for down time as these are highly utilized production machines and there's about 7TB to deal with.
In either case there will be a downtime involved. Two-steps replication process, plus, time it takes to finally failover VMs.
I understand that I can backup already replicated VMs, but can I replicate a replicated VM?
Yes, you can. Though, you'd better make sure replication activities do not overlap, meaning do not replicate VMs to second host before you've replicated all of them to the first one. Otherwise, you may encounter several issues.
Similar situation here - we did a replica Failover of a VM to our DR site however it's been running in a 'failover' state for more than one week. Unfortunately we are unable to do a 'failback to production' as it's a critical VM.. etc.
Can we take backups of this failover replica on our DR site or it will cause corruption? This is major concern as currently there is no backups.
I think the options are:
1. Permanent failover to DR site and create a backup job. Create a new replica job to migrate back to 'production site'. Reverse process.
2. Failback to production and schedule downtime (at least 20 min).
3. ?
Yes, you can take a backup of the replica. Both approaches should work, however with the second approach it's hard to provide any estimates on the downtime.
Hi
We tested backup the replicated VMs in Veeam v9.0.
It is successful, but read value is 0 kb despite a Full backup.
However, if we test it by using Veeam v9.5, a warning that CBT can not be activated is output, and full scan Read is being carried out.
Since the replica VM have the snapshot, we think the behavior of Veeam 9.5 is correct.
Is it by design in Veeam 9.0 ? Or known issue ?
Do we need to disable CBT setting of backup job in Veeam 9.0, when backup replica VMs ?
Let me know.
Regards
Toshi
We have a client who uses Veeam to create a replica environment on a second vCenter server system, ready to fire up in the event of an outage. They wish to create a tape backup for offsite storage.
I cannot see a way to backup to tape unless it uses data from a backup job. Is there a way to be able to backup to tape a set of "off" state VM replicas?
The live environment is in a datacenter, and there is a replica set of hosts and a SAN locally. There is a physical server onsite locally that has a tape library attached, Veeam is installed on a VM on the local Disaster Recovery site and pulls the replicas in. Veeam has connected to the tape library so now we just need to find a way to back up certain systems to tape.
You can backup those replicas to a local repository on the DR site, and then send the backups to tape. Please check this thread for additional considerations.
We are a SP so we have clients` replicas in our DC .We have one client that asked us if we can backup his replicas that are created through cloud connect .
So can we operate the VMware infra with both Cloud Connect and Veeam Backup & Replication - are there any known limitations ?
You can do that, but mind the following limitations:
- You will need to have a separate backup console to create backup jobs on (CC backup server cannot be used for that)
- Backup jobs won't leverage CBT, so job cycles will be rather slow
- You will need to make sure tenant's replication jobs do not overlay with your backup ones. Otherwise, multiple issues will be expected
we have a VMware Backup Job who is making a backup from a VMWare Replica to another storage. We are using the CBT Optoin on this Job but we getting always the following message:
:: CBT data is invalid, failing over to legacy incremental backup. No action is required, next job run should start using CBT again. If CBT data remains invalid, follow KB1113 to perform CBT reset. Usual cause is power loss.
The KB says we have to delete all Snapshots from the source, but the replica dont have a snapshot it is a snapshot on him self.
Is there a way to let run the job with CBR without a error msg?
We run replications of our MSSQL server from Datacenter A to Datacenter B.
We also do veeam backups of these same database servers in Datacenter A but the backups also live in Datacenter A.
I would like to start backing up the replicas themselves as we now have a requirement that production data and backup data cannot live in the same physical location.
When I tried to backup the replica, Veeam gave a warning stating "Changed block tracking cannot be enabled: one or more snapshots present". I presume these are restore points? Is there a way to do this?
Hi Tom, please review this thread for considerations regarding replica VMs backup. Basically, yes, you will not be able to utilize CBT in this case as replica restore points are stored as snapshots. Haven't you thought about using replication from backups instead?
We need to replicate off site once per hour, but the backups only need to run once per day at Datacenter B. The actual backups we would use in production are at Datacenter A and these run once per hour. We just need to get one copy off site to Datacenter B once per day so production data and backups aren't living in the same physical place.
During the copy job, is the vm being copied available to be backed up? We have to have the backups run each hour for RPO. Or did you mean copy job of the replica itself?
Depends, but usually "yes". Certain operations from the primary job might be delayed (I think just Synthetic Full?) if the Backup Copy was running at the same time, but they should behave with one another.
good morning , I will describe my project in detail:
I have a production site with wmare in the company, and another replication site at a cloud provider.
For replicas I don't use cloud connect.
always at the cloud provider I have a physical linux red hat server with the role of repository and the function of immutability.
I want to backup the replicated machines on the physical repository with the immutability function
It's possible ? what kind of job should i use?
Are there any options I need to enable or disable in the job ?
It's possible, just create a backup job and add replica VMs as its source and immutable repository as its target. The only thing you need to do is to ensure that backup and replication jobs do not interfere - have different schedules, in other words. Thanks!
I'm actually doing this for a few customers to save out on the bandwidth, since else the same data needs to be go over the interconnect twice. So I first do the replication (actually pulling it from the main site to the DR) and then I backup those replica's, since they are already 1-to-1 copies of the on prem VM's. Never had any issues, and I'm keeping enough time between the replication and the backup.
