Replica Snapshots To Keep Logic, Feature Request?

[cgsm]

Hello,

From what I can tell from years of using VBR, the only logic VBR uses to keep replica snapshots is the "Restore Points to Keep". It would be great if there was a "GFS" style logic available here.

Let me explain: I have a backup job that runs every 3 hours and triggers a replication job. At "Every 3 hours" scheduling, that gives me 8 backups and replica snapshots per day. I only end up with 3 (full) days worth of replicas since the "Restore Points to Keep" has a maximum of 28. I backup frequently for RPO reasons, and replicate on the same schedule for DR. However, I really only need the latest replica snapshot for "today", and would prefer to have many days worth of other snapshots instead of multiple snapshots per day.

For example: Keep 1 snapshot per day for the last 7 days would be a great start. The current day's snapshot would just be updated each time the replication job runs instead of creating a new snapshot each time. Or, at the end of each day the multiple snapshots for "today" would be compressed into one snapshot.

Yes, I know I can create a replication job that isn't tied to a backup job and run it on a daily schedule, but then I have 24 hours between replications. Yes, I know I can limit when my replication job runs with the "Backup Window" to limit snapshot usage during non-business hours, but this isn't ideal either since I still have new data during these hours, just less of it.

[david.domask]

Hi cgsm,

Have you considered CDP for these machines? CDP lets you set both short term and long term retention, meaning you can have highly granular short-term recovery (down to seconds) and from the same job produce long-term restore points for the replica as well.

[cgsm]

David,
Yes, we have considered CDP, but I believe it requires a higher VMware license than what we have (we run Essentials Plus until our license expires, then the new Standard license) to install the I/O Filter. We are also replicating across the WAN and I am unsure of CDPs performance with variable bandwidth. Lastly, we like having multiple point-in-time recovery points at the replica site as well, although this might be configurable with a combination of CDP and replication.

[david.domask]

Got it re: Vmware license. CDP can handle cross-WAN replication via the mechanisms noted in the User Guide, but understood that this is a no-go based on your license.

However, I really only need the latest replica snapshot for "today", and would prefer to have many days worth of other snapshots instead of multiple snapshots per day.

Yes, I know I can create a replication job that isn't tied to a backup job and run it on a daily schedule, but then I have 24 hours between replications. Yes, I know I can limit when my replication job runs with the "Backup Window" to limit snapshot usage during non-business hours, but this isn't ideal either since I still have new data during these hours, just less of it.

I'm not quite getting the requirement here; you mention needing "only latest replica snapshot of today" but you also note concerns about 24 hours between replications, so I'm not sure which is the goal:

- Each snapshot represents latest state of VM at end of day
- Replicas with very low RPO for each day

I want to say that a second replica job with Replica from Backup is the answer but not entirely sure on the goal. Replica from backup avoids the additional workload on production, but it will always be lagging slightly behind the production machine. If you can clarify a bit more, can better advise.

[cgsm]

David,

I would like something like "Max of 4 replicas for today and 1 replica for each of the past 10 days". That way I can run the replication task relatively frequently to have the most up-to-date data, but still keep replicas over a longer timeframe.

Does this make sense?

I am currently running replication from backup job that runs each time my backup job runs (every 3 hours) and I have scheduled the replication task to only run within business hours to prevent creating replica snapshots, and using up the 28 snapshot allowance, during off-hours.

[david.domask]

Understood on the use case. I think no way to avoid two Replica jobs if CDP is not an option -- I would advise use Replica from Backup for the "long term" restore points as mentioned above to avoid additional snapshots on the production VM.

[cgsm]

David,
OK, so two replica jobs:
1) Replicate from running VMs frequently, say every 1 hour.
2) Replicate from backup, say once per day.

Question: Would both these jobs use separate target replica VMs? I see that as the only way to limit snapshot could (job #1 = 4 snapshot limit, job #2, 7 snapshot limit) I have a slight memory of trying something like this previously and ended up with two copies of each VM; each replica job had its own target replica VM.

[david.domask]

Correct, each job will produce its own separate replicas. To avoid overwriting existing replicas, the job will warn if a VM with the same name already exists, and you can add a prefix or suffix to help distinguish between the two jobs.

[cgsm]

David,
Ok. Something I will consider with my team. This would obviously require double the storage since we have doubles of each VM, which is going to be a concern.

GFS would be awesome for snapshots!

[FCU_JE]

I'm pretty ignorant on advanced configurations of replication jobs so just throwing out a couple comments:

- What is your RTO for the daily "GFS" backups? Is it forgiving?

- Would instant recovery from backup copies be a sufficient alternative for what you're trying to do?

The way I see it - replication jobs essentially just shift the restore work to a more favorable period of time to reduce the time to recover. Of course they do other things too like IP address settings and offer failback features. If you don't see yourself needing those features, maybe using instant recovery is at least a temporary stop-gap measure.

[cgsm]

@FCU_JE
The purpose of replicas for us is simple: in case our primary datacenter gets nuked. In this case, there is no shifting of restore to a more favorable time. The goal is to just get up and running as quickly as possible with as little data loss as possible.

Yes, we have offsite backup copies, but that doesn't really help us unless we were to do something like "backup every 30 minutes, replicate ever 3 hours" and then somehow have to deal with spinning up the replicas and then copying down the latest backups which is a lot of work, and time waiting on downloads, when our primary goal is to just get up and running.