GFS retention

[MarcinS]

Hello,

i plan to make in Veeam BR backups in style GFS (grandfather, father,son) retention. If i good understood provided help i can do that adding to normal actual jobs new backup copy job(s). Follow that i have few questions as helps is not clear for me here.

- why backup copy jobs must be targeted to another repository then actual backup jobs ?....is little stupid for me cause i must create new repository only to hold GFS retention backups. I try only to put on side few weekly & monthly copies and don't understood why i must storage it separately beside to actual fantastic scale out repository which i already had for backup jobs.

-inside backup jobs on target section is "Restore points to keep:" field. I can not find in help info how its counted. For example ...i want to make that backup copy job will save for me 5 weekly full backups & 3 monthly full backups. So what i should select in that field ? 8 (as 5weekly +3mothly ) ?

thanks for any tips !

[DGrinev]

Hello,

The main idea of the backup copy job is to create an independent backup chain in the offsite location, to be on a safe side when the primary repository is down. You cannot set it up for producing only GFS restore points, there will be a backup chain which can be 2 RPs at minimum. That's why there is a simple retention policy and optional GFS Retention.

Please review this big discussion about GFS retention for additional information. Thanks!

[MarcinS]

thx for clarification ...from second side is strange that suggested link is about topis from 2015 and still is not GFS in backup job and we additionally must loose 2 copies in backup copy jobs even when we not needed only for GFS to work

[nwbc]

I am following the whole GFS topic through the threads and can't make sense of it either.

[DGrinev]

Hey,

What exactly doesn't make sense for you?
Are you referring to why GFS cannot be used apart from the backup copy job?

[nwbc]

Basically the communicated reasons why there is no GFS pattern option in the backup job config itself is:

1. that it is only considered a short term destination
Which I just disagree on, it only is because you do not give users the option not to be, except for keeping like 150 daily backups.

2. that it would not follow 3-2-1 pattern
which just has nothing to do with it in the first place and would be false anyway - having GFS in 1. copy is not less safe, then not having GFS in 1. copy. To be clear, you are not forcing people to copy their files off their 1. copy to another offsite destination(you desire that, but do not force them to), what you are forcing them to though, is not being able to create GFS like scheme in the first copy altogether.

3.
that it can be acquired with copyJobs if someone really wants GFS

which is not trivial to set up and ... is not an effective process (especially on network) at all.

"Hey new IT Guy, let me explain this setup. So we set up a second repository at the same destination, so Veeam can copy files in between the physicaly same location, because veeam does not let you copy in between the same repository, nor let you keep older Backups in your backup job in the first place.". New IT guy probably is thrilled to work with Veeam from that day on. Setting up more Copy jobs for more Backup Jobs...

maybe I am missing the point...maybe I don't - I hope we'll find out.

[derda05]

Hi all,

"Hey new IT Guy, let me explain this setup. So we set up a second repository at the same destination, so Veeam can copy files in between the physicaly same location, because veeam does not let you copy in between the same repository, nor let you keep older Backups in your backup job in the first place.". New IT guy probably is thrilled to work with Veeam from that day on. Setting up more Copy jobs for more Backup Jobs...

Even worse at my side. I have to explain it to my customer why we actually implement such a weird concept. We have a Datadomain with 2 repositorys, so we can dedup the backups and we don´t actually need built the all the full backups, because the mechanism in DD OS does that. But still a bit difficult to explain that to my customer ...

Regards,

Dennis

[nwbc]

that exactly.

Should not have to fall back to workarounds for basic functionality. It just completely goes against how someone(me) thinks and how someone(me) would want to set things up.

While NAKIVO's claim to be able to download, install and configure a Backup in 2 minutes is a bit "sporty", I managed to download, install and configure a Backup in GFS manner altogether in less time, then it would require to read up on Veeams copyJobs alone.

[foggy]

The main reason behind backup copy design was explained in the topic referred to above.

[Gostev]

Having said that, there's one functionality planned for the next update following U4 that practically forces us to add GFS as an option to primary backup jobs, so now we do have another reason which is going to become even "more main"

[nwbc]

Sounds good to me. So I will set up a REFS repo on the bare metal backup machine itself in the meantime and will take what space I have for more restore points in a basic backup scheme until GFS hits in with U5.