backup offsite

[deesloop]

I have machines that were backed up to another building. However I want to backup to cloud also.

I had this working as separate backups jobs to the cloud repository but it was forever incremental and on
moving VMs to a new vcentre the backup chain is broken and entirely useless now.

Moving forward I'm told to use backup copies and maintain offsite with GFS which I understand
However I'm not sure how to go about this.
My existing jobs are running OK to the local repository but as soon as I select configure secondary source I'm prompted for setting up tapes etc?

Whats the way to store data long term i the cloud so that it's recoverable in future and not affected by things like moving esx hosts to a new vcentre.

This https://helpcenter.veeam.com/backup/70/ ... te_bu.html isn't a huge help, and I dont want to set it up again and have
to repeat the process in VCentre 7 for example.

Thanks

[Mike Resseler]

Hi Darren,

From your post I understand that you are working with a Veeam Cloud connect provider?

Have a look at this help guide for seeing the GFS settings: https://helpcenter.veeam.com/docs/backu ... tml?ver=95

I believe it will help you better in understanding how it works in combination with a cloud repository

If you have more questions

Please let us know

Thanks
Mike

[DGrinev]

Hi Darren,

I'd recommend you to create a Backup Copy Job for the backup job, so it will be a separate backup chain at the offsite repository.
Also, for a long term archival purposes, you should utilize GFS functionality.

moving VMs to a new vcentre the backup chain is broken and entirely useless now.

That's not correct, the backup chain still valid and can be used for restore but the job will start a new chain, since VMs MoRef IDs have changed.

Since you have moved to the new vCenter, all VMs have new MoRef IDs.
Please, review existing discussion about Moving VMs to new vCenter.
There is a vCenter migration tool that will help you to reassign VMs to the old jobs.

Thanks!

[deesloop]

create a Backup Copy Job for the backup job,

Thats what I was looking for! I had never ever spotted the Backup copy button. I'm mortified I missed it
I was creating totally separate backup jobs and that was it - doubling the workload possibly?

Also is there a better explanation of the GFS? I've not quite grasped it - storage wise.
I'm looking to have a months worth of weekly fulls offsite, Then 3 month ends, 4 quarterlies and 10 years.
Since much of the data doesn't change - it's more adding to existing data, I dont want to store 100 full backups, but I'm concerned by offsite repository will run out quickly if I choose the wrong settings...

I'm also a little confused as to the scheduling
The backup copy jobs you can run every day. But I only want to run it as part of the backup job schedule. So I do my Backup locally on Monday night, Wednesday and friday. I want the backup copy to run then also? Not every day.

moving VMs to a new vcentre the backup chain is broken and entirely useless now.

It's useless in that it's filled my cloud repository and cannot be added to.
Migrating to the new VCentre starts a new chain and I cant afford to fork out for additional storage for 2 full backups basically.

Moving forward and long term I want only to set this up one more time and do it right.
Forever incrementals as separate backup jobs was definitely wrong wrong wrong - in this situation at least.

Am I making sense?

[DGrinev]

Also is there a better explanation of the GFS? I've not quite grasped it - storage wise.

Please review existing big discussion about GFS Retention Policy for better understanding.
You can use Restore point simulator for storage planning.

I'm also a little confused as to the scheduling

The backup copy job is looking for new restore points continuously, so it will start to move data right after the backup jobs have completed.

If you will have additional questions do not hesitate to ask. Thanks!