Long Retention with short RPO

[Stabz]

Hello,

Another question for you!

I have a job which backup my vms every 2 hours with 14 points of retention
I have a backup copy job set every 2 hours with 14 points of retention to copy my backups offsite

Now I want to keep in addition the last 7 days. What is the better options to do this?

I can't use GFS of my backup copy job, there are only weekly, monthly ... not a daily options

I thought to use another backup copy job set every day with 7 days retention, is that a good idea?

What will happen if the two backups copy jobs want to access in the same time to the original backup ?

Thanks
Philippe

[DGrinev]

Hi Philippe,

I thought to use another backup copy job set every day with 7 days retention, is that a good idea?

Yes, you can create another backup copy job and choose the target repository of the first copy job as the source.

What will happen if the two backups copy jobs want to access in the same time to the original backup ?

One of the job will stand in a queue until another will be processed. Unless the first job locks the backup file, then both can read and move data blocks simultaneously. Thanks!

[Stabz]

Hi,

yes that is an idea, that depends on which side I would have my backups.

Another question is how could I calculating the estimate backup size?

[veremin]

Check this handy tool called Restore Point Simulator. Thanks.

[DGrinev]

In most cases using default compression a full backup file at least 50% of overall used space by VMs in the job. Thanks!

[Stabz]

Thanks for the link

I'm using Per-Vm backup files, the compression style the same or not?

I'm a bit confused, about the " used size ", in my job I have:
Processed: 2.2TB
Read: 1,5 TB
Transferred: 1.3TB

I presume in my case the "read" correspond to "used size" right?

Unfortunatly in the simulator, we cant change the change rate for a value lower than 3.

[DGrinev]

Under used space I mean the total size of all VM disks added to the job, that value is reflected in the "Processed" counter.
In case of per-VM backup chains, compression is the same. Thanks!

[Stabz]

Hmm ok this match also with the total size in the backup job wizard in the virtual machines tab.

But there is something that I don't uderstand:
In the Html report for my first full (I'm ussing Forever Incremental for my test) I have this:

Processed: 2.2TB Backup size: 1.3 TB
Read: 1,5 TB Dedupe: 1.5x
Transferred: 1.3TB Compression: 1.3x

Could you explain to me the meaning of Compression in this case?

[DGrinev]

You should take into account both values dedupe and compression when calculating the backup size, so maths should look like: total size / 1.5 / 1.3 = 1.1 Tb, which is close enough to the result of the job.
Please review existing discussion about Veeam backup statistics. Thanks!

[Stabz]

Oh ok, the compression of 50% is infact the deduplication and compression addition.
Thanks for the link.

Question about the tools:
I choose "Forever Incremental", but in the result I have a line Work Space


RetentionFile SizeModify Date Point Date
7full.vbk 1300 GB2017-11-23 Th 222017-11-23 Th 22
6incremental.vib130 GB2017-11-24 Fr 222017-11-24 Fr 22
5incremental.vib130 GB2017-11-25 Sa 222017-11-25 Sa 22
4incremental.vib130 GB2017-11-26 Su 222017-11-26 Su 22
3incremental.vib130 GB2017-11-27 Mo 222017-11-27 Mo 22
2incremental.vib130 GB2017-11-28 Tu 222017-11-28 Tu 22
1incremental.vib130 GB2017-11-29 We 222017-11-29 We 22
2080 GB
Work Space +1365 GB
TOTAL: 3445 GB

Why do we need this work space ? For me when the number of allowed restore point is exceeded, VBR merges data blocks from the older increment into the full backup.

[DGrinev]

Hi,

This parameter showing extra space that might be needed for the extra active full + extra inc.
Your understanding of forever incremental is correct. Thanks!

[tdewin]

Well you are certainly not the first one to ask. Basically Dimitry his answer is 100% correct. If you want to read the details:
http://blog.dewin.me/2017/11/rps-workspace.html

[Stabz]

Hi Guys,
Thanks for the clarification, it's clear for me now. This blog is a gold mine!

So now I'm in a reflexion for the backup methods.

I think for short RPo with low change rate the best it's the Forward Incremental Forever.

One disadvantage, it s there is only one full backup job. To me this seems risky.

So I plan to use Surebackup, but I have no idea for the frequence 1 time a week or month ?

I ll will use a copy job too in my memory it protects againts corrup data because it compares its data to the data from the backup job right ?
So planned a surebackup job monthly should be suffisant ?

[DGrinev]

So I plan to use Surebackup, but I have no idea for the frequence 1 time a week or month ?

It depends on your needs and capabilities. Once a week is good practice, once a day would be perfect.

I ll will use a copy job too in my memory it protects againts corrup data because it compares its data to the data from the backup job right ?

That's correct. Thanks!