On-premise backup -> duplication2cloud

[StanoSedliak]

Hi,

has someone best practice for this scenario please?
We are doing backup on-premise but we need to duplicate it to Azure.
Full backup has 10TB, incremental 100GB.

We would need to have this restore times in azure:
from last month we need a possibility to restore a file on a weekly basis
from older than 1 month a restore on a monthly basis

If I will make a backup copy job a to server located in azure with storage attached and I will set:
Restore points to keep: 31
Keep the following restore points as full backups for archival purposes:
Monthly backup: 12 times

I will be able to do restore within last month on daily basis and last 12 months on monthly basis but I will need space for 13 times full backup + 30x incremental?
But this would cost +130TB space in azure.

Another solution would be to run a on-premise backup job every last sunday in the month with forever incremental and to duplicate this job to cloud to keep the possibility for a restore from last 12 months on monthly basis.
With this option I would have 1full backup+11 big incrementals in cloud.
And another on premise backup job to run everyday with retention 31 days and duplicate also this job daily to cloud to have the possibility to do a restore on daily basis.

With this option I would have 1full backup+30incrementals in cloud.

Do you please have another solution for this?

Thank you!

Br, Stano

[veremin]

Since you're already thinking about the cloud, may be you can make use of Azure Blob Storage?

You can:

- Create Scale-Out Backup Repository consisting of two extents: Performance (Azure VM), Capacity (Azure Blob Storage)
- Configure move policy for Capacity Tier: Move backup files older than 30 days
- Create a backup copy job: daily - 31, monthly - 12
- Point it to the Scale-Out Backup Repository

This way, GFS backups will be moved to cheap Azure Blob Storage. Plus, blocks already moved to Azure Blob Storage will not be copied again (at the time of next GFS restore point offload) - Capacity Tier works in ReFS-like fashion offloading only unique data.

Thanks.

[StanoSedliak]

Hi Veremin,

thank you for your idea. Could you please write me an example how to configure the jobs as this not clear for me.

1. Because if I will backup the data to SOBR and I will configure move policy to move backups files older than 30 days - the chain needs to be inactive or?
2. I would need to make a backup job with once per month a full backup and configure move older backup files sooner if space-out backup repository is reaching capacity to 1% that the whole chain can be inactive and moved to blob (capacity tier) to save space on performance tier storage?
3. In the case you propose to me I would have:
Performance tier storage:
Chain#1 {1x full + 30 x incremental} + Chain#2{1 x full}
Capacity tier storage:
Chain#1 {1x full + 30 x incremental} + Chain#2{unique data for restore from monthly basis?} + Chain#3{unique data for restore from monthly basis?}+ and so on....?

Thank you!

Br, Stano

[veremin]

Just to clarify - we're talking about backup copy job or backup job? For the backup copy job only GFS restore points will be moved to Capacity Tier. GFS restore points are independent of each other, so, there is no need to configure anything else (monthly full backup or something) to make them inactive.

So, you will have: 1 full backup + 30 increments on Performance Tier, 12 full backups on Capacity Tier (each of the size of monthly unique data).

Thanks!

[StanoSedliak]

Thank you for the clarification.
Just to be sure a short summary.

1. Create SOBR from storage attached to azure server as performance tier and blob storage as capacity tier
2. Configure move policy for Capacity Tier: Move backup files older than 30 days
3. Create a backup copy job with restore points to keep: 31, Keep the following restore points as full backups for archival purposes: Monthly backup: 12
4. as backup repository I will choose the SOBR created in step 1.

Outcome will be:
only the monthly full backups GFS will be stored on the capacity tier (if incremental backup has 100GB - it will be 31x100GB per month=3.1TB) the last 31 restore points will be stored only on the performance tier (1 full 10TB + 30x100GB = 13TB) and there is no need to have a bigger performance tier storage as for example 15TB (no need of defragment and compact full backup file as GFS restore points will be created).
Restore will be possible on daily basis for the last 31 days from perf. tier and on monthly basis for the last one year.

Is this right?

Thank you!

[veremin]

I'd recommend having a space for at least two full backups on Performance Tier to host GFS restore for the time period: when it has been created already, but has not been moved to object storage yet. Everything else looks valid. Thanks!

[YouGotServered]

Couple of notes here.

Required storage:
Since you're using an Azure VM, you can easily scale storage, so you can use less than my recommendation for sure, but for physical on premise deployments, I typically plan to have at least 4x the current full backup size in my performance repository - 1x for full backup, 1x for all of the incrementals, 1x for a second full backup (defrags, corruption, vSphere VM ID change, or ig data is migrated from one VM to another one during an upgrade, and then 1x for growth = 4x.

Restore point size:
Your monthly restore point will likely not equal 31x your daily incremental. For example, the same blocks will likely be modified multiple times over the course of the month. So while you have 100GB of changes from day to day, you may only have 500GB of unique blocks that were changed throughout the month. If block A changes and is backed up every day for 31 days, your monthly backup will only contain the value of block A on the last day - so you're only copying 1 block's worth of data instead of 31.

Does that help?