Availability for the Always-On Enterprise
dguidry
Novice
Posts: 4
Liked: never
Joined: Sep 30, 2016 4:57 pm
Contact:

Re: GFS for primary backup jobs

Post by dguidry » Dec 14, 2017 10:09 pm

Now that I've switched to ReFS for my primary backup target, I would absolutely love to be able to fully leverage ReFS block cloning to keep historical backups at our primary site. We already have offsite backups as one should. However, It would be convenient to have a GFS chain at our primary site, if nothing else for the occasional email or file restore from 6 months ago that a user might request. The problem I'm running into is that, in order to keep GFS backups on at our primary site, I have to create a second repo on that server, set up a backup copy job and then run that. Because block cloning can't be leveraged across jobs, that means the base disk space requirements are doubled for us. In other words, let's say an active full of all our VMs would take up 10TB, well that doubles to 20TB in order to use backup copy jobs that can then take advantage of block cloning for longer term GFS purposes. Suddenly the whole notion of "spaceless GFS backups" becomes decidedly less spaceless, at least initially. This is a perfect scenario where having either GFS capability within a normal job, or the ability to link backup chains between a normal and copy job in such a manner where the copy job could leverage block cloning based on the primary job would be ideal. We're a pretty small shop and are looking for ways to be more efficient with storage wherever we can.

I realize this might be abused, but it could be somewhat mitigated with some friendly warnings, or something like that. Again, this has never really been something that mattered to me, but now that I'm utilizing ReFS, I'm realizing how much space I could be saving on the base disk requirements of a backup copy job.

Thanks!
Daniel

Brigham
Lurker
Posts: 1
Liked: never
Joined: Sep 28, 2016 4:39 pm
Full Name: Brigham Mirabelli
Contact:

[MERGED] Feature Request: Extended Retention in Primray Back

Post by Brigham » May 24, 2018 5:38 pm

Feature Request:
Please consider adding extended retention to the primary backup job. This is useful for clients that want to keep years of data at the primary site but only want a small amount data in the copy job offsite.

The only way to do this now is to do a copy job of the backup to the same repo but that is a waste of resources.

Thanks,

foggy
Veeam Software
Posts: 16822
Liked: 1359 times
Joined: Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson
Contact:

Re: GFS for primary backup jobs

Post by foggy » May 25, 2018 10:14 am

Hi Brigham, thanks for the request, your post has been merged into a discussion regarding similar matter.

tturnipseed
Lurker
Posts: 1
Liked: never
Joined: Jun 06, 2018 6:39 pm
Full Name: Tate Turnipseed
Contact:

Re: GFS for primary backup jobs

Post by tturnipseed » Jun 06, 2018 6:43 pm

I would also like to cast my vote for adding extended retention options to the primary backup job. I do not see this extended retention as a replacement for an additional copy in a different location, but with the space savings of fast clone, it seems like a useful data set to have in multiple places.

mkaec
Expert
Posts: 259
Liked: 55 times
Joined: Jul 16, 2015 1:31 pm
Full Name: Marc K
Contact:

Re: GFS for primary backup jobs

Post by mkaec » Jun 07, 2018 3:31 pm

The way it is now I can create a primary job with short retention and then use GFS in a copy job for long retention. If my environment suffers a disaster and I need to recover from DR, I'm going to want to restore from the most recent backups. So, having long term backups there doesn't help me much. It's when a user finds out he made a critical mistake in a file 6 weeks ago that I'll need to go to the long term backups. The current paradigm has me dragging that file over the WAN from the DR site when I'd prefer to be retrieving it out of the local backups.

mkaec
Expert
Posts: 259
Liked: 55 times
Joined: Jul 16, 2015 1:31 pm
Full Name: Marc K
Contact:

Re: GFS for primary backup jobs

Post by mkaec » Jun 07, 2018 5:31 pm

I guess the counter argument to my own argument is if you wanted to use very fast disks for the primary repository in order to provide the best possible performance for restore and instant recovery. In that case, you would want your historical backups elsewhere on less expensive storage.

v.Eremin
Veeam Software
Posts: 15140
Liked: 1141 times
Joined: Oct 26, 2012 3:28 pm
Full Name: Vladimir Eremin
Contact:

Re: GFS for primary backup jobs

Post by v.Eremin » Jun 09, 2018 9:37 am

The current paradigm has me dragging that file over the WAN from the DR site when I'd prefer to be retrieving it out of the local backups.
If you want, you can create a local copy job and make it create GFS restore points locally. Just create a separate folder, assign repository role to it and leverage it then as a target repository for the backup copy job. Thanks.

mkaec
Expert
Posts: 259
Liked: 55 times
Joined: Jul 16, 2015 1:31 pm
Full Name: Marc K
Contact:

Re: GFS for primary backup jobs

Post by mkaec » Jun 09, 2018 10:47 am

That is a work-around. But, it's not ideal as there is quite a bit of extra disk space used.

v.Eremin
Veeam Software
Posts: 15140
Liked: 1141 times
Joined: Oct 26, 2012 3:28 pm
Full Name: Vladimir Eremin
Contact:

Re: GFS for primary backup jobs

Post by v.Eremin » Jun 09, 2018 3:26 pm

Even if we had GFS restore point for primary backup job, those points would occupy the very same amount of space. So, I'm not sure whether I'm following you on that. Thanks.

Dsgrievew
Lurker
Posts: 1
Liked: never
Joined: Aug 01, 2017 8:29 pm
Full Name: William Grieve
Contact:

Re: GFS for primary backup jobs

Post by Dsgrievew » Jun 11, 2018 4:27 am

I definitely agree that the GFS functionality should be independent of the Backup Copy functionality. Having worked with numerous other backup technologies, properly implementing both GFS schemes and backup copies schemes in Veeam is one of the hardest things to figure. I would like lot more control of how weeklies, monthlies and yearlies are created and what backup files are copied. Normally it is the long term retention backups you want multiple copies of. I've found Veeam's scheduling to be both really flexible for some things but really limiting for other things.

mkaec
Expert
Posts: 259
Liked: 55 times
Joined: Jul 16, 2015 1:31 pm
Full Name: Marc K
Contact:

Re: GFS for primary backup jobs

Post by mkaec » Jun 11, 2018 2:09 pm

v.Eremin wrote:Even if we had GFS restore point for primary backup job, those points would occupy the very same amount of space. So, I'm not sure whether I'm following you on that. Thanks.
With the current capabilities, if I want GFS on the primary repository, I've got to create a BCJ to save into a different folder in the repository. So, at least some of the daily backup VBK and VIBs are duplicated between the main job and the GFS job.

v.Eremin
Veeam Software
Posts: 15140
Liked: 1141 times
Joined: Oct 26, 2012 3:28 pm
Full Name: Vladimir Eremin
Contact:

Re: GFS for primary backup jobs

Post by v.Eremin » Jun 13, 2018 11:33 am

It holds true only until backup job retention policy removes those intersecting points, and the additional amount of space temporarily occupied by such restore points should be negligible. Thanks.

mkaec
Expert
Posts: 259
Liked: 55 times
Joined: Jul 16, 2015 1:31 pm
Full Name: Marc K
Contact:

Re: GFS for primary backup jobs

Post by mkaec » Jun 13, 2018 3:55 pm

I would think it is at least one additional VBK for each job. That could add up in large deployments. Plus, there is the time and resources spent making all those extra copies.

KelKnowles
Influencer
Posts: 15
Liked: never
Joined: Sep 15, 2012 8:01 pm
Full Name: Kelly Michael Knowles
Contact:

Re: GFS for primary backup jobs

Post by KelKnowles » Sep 09, 2018 11:49 am

I think it would be much better if REFS would be able to be fully leveraged on the primary backup job to create the GFS copies. Of course you want to try to adhere to 3+2+1 rule however this just makes it so you end up with 4+2+1 if you have a large backup repository and want to keep your historical backups onsite. Creating a seperate folder for backup copies doesn't leverage REFS technology.

Right now I am forced to do a backup copy to a separate folder for a 30TiB job and it would be really nice to be able to leverage REFS for this not just in the space savings but the time required.

Wouldn't it also be great if we could also create a weekly monthly or yearly on demand from an existing .vbk and have it use REFS to become a spaceless full copy?

Shestakov
Veeam Software
Posts: 5968
Liked: 519 times
Joined: May 21, 2014 11:03 am
Full Name: Nikita Shestakov
Location: Prague
Contact:

Re: GFS for primary backup jobs

Post by Shestakov » Sep 09, 2018 9:18 pm

Hello KelKnowles,
Having 2 copies on ReFS it's same as 1 copy in terms of data safety. If the data blocks are corrupted or disk is broken, both copies will be lost.
However, we will count +1 to primary job GFS requests.
Thanks!

Post Reply

Who is online

Users browsing this forum: Exabot [Bot], patrick.shea, rickrbyrne, vhernandez and 45 guests