GFS for primary backup jobs

Availability for the Always-On Enterprise

Re: GFS for primary backup jobs

Veeam Logoby dguidry » Thu 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
dguidry
Novice
 
Posts: 4
Liked: never
Joined: Fri Sep 30, 2016 4:57 pm

[MERGED] Feature Request: Extended Retention in Primray Back

Veeam Logoby Brigham » Thu 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,
Brigham
Lurker
 
Posts: 1
Liked: never
Joined: Wed Sep 28, 2016 4:39 pm
Full Name: Brigham Mirabelli

Re: GFS for primary backup jobs

Veeam Logoby foggy » Fri May 25, 2018 10:14 am

Hi Brigham, thanks for the request, your post has been merged into a discussion regarding similar matter.
foggy
Veeam Software
 
Posts: 16271
Liked: 1302 times
Joined: Mon Jul 11, 2011 10:22 am
Full Name: Alexander Fogelson

Re: GFS for primary backup jobs

Veeam Logoby tturnipseed » Wed 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.
tturnipseed
Lurker
 
Posts: 1
Liked: never
Joined: Wed Jun 06, 2018 6:39 pm
Full Name: Tate Turnipseed

Re: GFS for primary backup jobs

Veeam Logoby mkaec » Thu 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: 242
Liked: 54 times
Joined: Thu Jul 16, 2015 1:31 pm
Full Name: Marc K

Re: GFS for primary backup jobs

Veeam Logoby mkaec » Thu 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.
mkaec
Expert
 
Posts: 242
Liked: 54 times
Joined: Thu Jul 16, 2015 1:31 pm
Full Name: Marc K

Re: GFS for primary backup jobs

Veeam Logoby v.Eremin » Sat 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.
v.Eremin
Veeam Software
 
Posts: 14812
Liked: 1113 times
Joined: Fri Oct 26, 2012 3:28 pm
Full Name: Vladimir Eremin

Re: GFS for primary backup jobs

Veeam Logoby mkaec » Sat 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.
mkaec
Expert
 
Posts: 242
Liked: 54 times
Joined: Thu Jul 16, 2015 1:31 pm
Full Name: Marc K

Re: GFS for primary backup jobs

Veeam Logoby v.Eremin » Sat 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.
v.Eremin
Veeam Software
 
Posts: 14812
Liked: 1113 times
Joined: Fri Oct 26, 2012 3:28 pm
Full Name: Vladimir Eremin

Re: GFS for primary backup jobs

Veeam Logoby Dsgrievew » Mon 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.
Dsgrievew
Lurker
 
Posts: 1
Liked: never
Joined: Tue Aug 01, 2017 8:29 pm
Full Name: William Grieve

Re: GFS for primary backup jobs

Veeam Logoby mkaec » Mon 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.
mkaec
Expert
 
Posts: 242
Liked: 54 times
Joined: Thu Jul 16, 2015 1:31 pm
Full Name: Marc K

Re: GFS for primary backup jobs

Veeam Logoby v.Eremin » Wed 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.
v.Eremin
Veeam Software
 
Posts: 14812
Liked: 1113 times
Joined: Fri Oct 26, 2012 3:28 pm
Full Name: Vladimir Eremin

Re: GFS for primary backup jobs

Veeam Logoby mkaec » Wed 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.
mkaec
Expert
 
Posts: 242
Liked: 54 times
Joined: Thu Jul 16, 2015 1:31 pm
Full Name: Marc K

Previous

Return to Veeam Backup & Replication



Who is online

Users browsing this forum: Google Feedfetcher and 34 guests