health check on VCC repo

[backupquestions]

Is it true that if say a monthly health check is configured in a backup copy job, that the actual daily copy job will not run until the health check is completed? Since Veeam Cloud Connect jobs are incremental forever, what if you needed to restore entire VM years down the road after you had been merging all that time and it failed to corruption?

The problem is if you use the health check and it takes forever to finish, then you are missing backups during this time as well.

I'm hoping the backups still run while the health check goes on, or what do people with a lot of VCC data stored do to test the integrity? I'm going to have probably 50TB in VCC repo.

[veremin]

Is it true that if say a monthly health check is configured in a backup copy job, that the actual daily copy job will not run until the health check is completed?

Health check is performed at the end of the backup job session, not at the beginning. But you're right - the next backup job session won't start, until health check activity ends.

Since Veeam Cloud Connect jobs are incremental foreverwhat if you needed to restore entire VM years down the road after you had been merging all that time and it failed to corruption?

There is no hard requirement to use forward forever incremental mode for jobs pointed to cloud repository.

what if you needed to restore entire VM years down the road after you had been merging all that time and it failed to corruption?

Use GFS + verify backup chain regularly: health check or SureBackup (I've heard about SPs enabling Surebackup as a service)

Thanks!

[backupquestions]

The problem with a gfs point on a vcc job is if you are using 50tb you need another 50tb just to have two fulls. I think a lot of companies would need to stay incremental forever in the vcc due to price and space.

I guess I'll look into SureBackup by provider.

[veremin]

But year(s) worth of increments will consume more space than those two fulls. Thanks!

[backupquestions]

You mean if you had a large chain right? I mean if I just had a short chain with only one full and say 3 vib.... Keep that going on forever. You are saying in a couple of years that would take more than 2 fulls? Or did you just mean if I had a super long chain? I only plan to have short term chain but keep it going for years.

[veremin]

Just to clarify my statement regarding health check operation:

Health check is performed at the end of the backup job session, not at the beginning. But you're right - the next backup job session won't start, until health check activity ends.

It holds true only in case of backup job, while in case of backup copy job health check operation is performed at the beginning of backup copy job session.

Sorry for confusion caused.

Thanks!

[veremin]

I only plan to have short term chain but keep it going for years.

What do you mean exactly? If you have short backup chain, say, 4 points in total, and run job daily, you will be able to go as far as 4 days back in case of disaster - that's it. Thanks!

[backupquestions]

Yes, with cloud connect since it is expensive my plan is only to have a few restore points always up there run daily. If we lost everything locally and needed to rebuild we would pretty much want last night status with all VMs I'd think...

Now as far as longer term retention my plan is to use SOBR with cloud tier to S3 compatible object storage. various gfs points all various vms would be aged out to that so in disaster we can still rebuild veeam server and then simply reconnect to the s3 repo which we still wouldn't even use unless we got asked for an old file.

Does this sound correct and would work? I think 3 2 1 rule is still met here as 1. production data 2. backup job to local server repo 3. cloud connect for short term of all vms 4. cloud tier for long term of all.

All we really lose is long term restore points are only in one spot, but that is the same with cloud connect too as your main job doesn't have gfs points local.

[HannesK]

yes, that works. except for the point "last night status" because you only age out old data.

[backupquestions]

We would have cloud connect for all vms 3 or 4 days retention.

Capacity tier to s3 is separate and only for old gfs points.

So we would have last night of all vms from the cloud connect partner.

[HannesK]

ah okay - sounds good