Comprehensive data protection for all workloads
Post Reply
motoxrdr21
Influencer
Posts: 13
Liked: 1 time
Joined: Apr 30, 2014 10:52 am
Full Name: Steve Galambos
Contact:

GFS Copy job to manage retention on the same repo.

Post by motoxrdr21 » Jan 11, 2017 1:31 pm

To keep a long story short, a Veeam Support Engineer recently suggested that we could handle our backup file retention using a GFS copy job rather than running a separate annual job.

I like the idea, so I setup a GFS backup copy job this morning to test it, however the job won't run because the source and target repositories are the same. This job is only being used to handle file retention, more specifically to satisfy our requirement to keep an annual backup, so pointing it at a different target repository isn't really a requirement for our use case. I'm sure a separate source & destination repo would perform better, but everything from the backup server to the repository storage is outside of our production environment so the only effect that will have is a decreased backup window.

Is there a registry flag to configure the copy job to ignore this warning, or would we have to setup another repository in order to use GFS-based retention?

P.Tide
Product Manager
Posts: 5066
Liked: 439 times
Joined: May 19, 2015 1:46 pm
Contact:

Re: GFS Copy job to manage retention on the same repo.

Post by P.Tide » Jan 11, 2017 4:51 pm

Hi,

Did I get it right - you basically want to use a copy job to make copies of backup files produced by a simple backup job and place them on the very same repo thus managing the backup files retention, is that correct?

Thanks

sethj
Lurker
Posts: 1
Liked: never
Joined: Jan 11, 2017 7:55 pm
Full Name: Seth J
Contact:

Re: GFS Copy job to manage retention on the same repo.

Post by sethj » Jan 11, 2017 7:59 pm

I actually came here looking for the same thing: I just want an 'end of month' that is kept for a year. Backup Copy won't allow source/target to be same repo. Do I really have to setup a separate set of jobs for my month end?

motoxrdr21
Influencer
Posts: 13
Liked: 1 time
Joined: Apr 30, 2014 10:52 am
Full Name: Steve Galambos
Contact:

Re: GFS Copy job to manage retention on the same repo.

Post by motoxrdr21 » Jan 11, 2017 8:52 pm

Yes PTide,

We would run a simple backup job as the source which would keep the minimum number of restore points, and from that a backup copy job would run to manage an annual grandfather restore point along with regular father/son restore points. All restore points from the simple backup job & the copy job would be on the same repo...ideally the simple backup job would be configured to handle the GFS rotation, but it seems like that type of restore point retention is only available with copy jobs.

Thanks

jdavidson_waters
Service Provider
Posts: 40
Liked: 15 times
Joined: May 07, 2013 2:50 pm
Full Name: James Davidson
Location: Northeast UK
Contact:

Re: GFS Copy job to manage retention on the same repo.

Post by jdavidson_waters » Jan 11, 2017 8:56 pm 2 people like this post

You can setup two repositories on the same underlying storage volume.
E.g if you are using F:\Backups as your main backup job repo then you can create a new repo called F:\GFS and use that as a target for the Backup Copy job.

It's the same underlying disk, but has two Veeam repos on it.

Obviously if you lose the disk then you've lost your recent backups and long term retention so this doesn't meet the 3-2-1 best practice.
@jam_davidson

motoxrdr21
Influencer
Posts: 13
Liked: 1 time
Joined: Apr 30, 2014 10:52 am
Full Name: Steve Galambos
Contact:

Re: GFS Copy job to manage retention on the same repo.

Post by motoxrdr21 » Jan 11, 2017 9:26 pm

jdavidson_waters wrote:Obviously if you lose the disk then you've lost your recent backups and long term retention so this doesn't meet the 3-2-1 best practice.
We also go to tape stored on-site & to offsite rotating disks, so we still hit 3-2-1.
Right now we run an additional VMWare Backup job once a year to create an annual backup, the GFS copy job would replace that by maintaining an annual grandfather.

Honestly this would be much easier if the source VMware backup job supported GFS-style retention, because all we're doing is using a backup copy job to supplement the simple retention policy that we're restricted to in the source job.

P.Tide
Product Manager
Posts: 5066
Liked: 439 times
Joined: May 19, 2015 1:46 pm
Contact:

Re: GFS Copy job to manage retention on the same repo.

Post by P.Tide » Jan 12, 2017 1:39 pm

James is spot on - you can create another repo folder on the same volume.
Honestly this would be much easier if the source VMware backup job supported GFS-style retention
There is an existing thread for that feature request, feel free to post there.

Thanks

veehexx
Influencer
Posts: 12
Liked: never
Joined: Nov 19, 2015 10:00 am
Contact:

[MERGED] GFS without backup copy jobs?

Post by veehexx » Aug 31, 2017 8:58 am

I've just found out that copy jobs do not like the source & destination being on the same server. We've been using them for 7 year GFS retention.

We've recently updated our backup server hardware from 3 small capacity servers (1x 7TB, 2x 32TB) to two large capacity servers (2x 92TB) and intended to mirror them using rsync.

since backup copy jobs do no work if source&destination are on the same server, what would be the correct way to restructure our job design?

we currently take weekly incrementals with monthly full.
GFS copy jobs then ran on these backup jobs with a policy of 4x monthlies, 5x 3 month and 7x yearly.

DGrinev
Veeam Software
Posts: 1620
Liked: 198 times
Joined: Dec 01, 2016 3:49 pm
Full Name: Dmitry Grinev
Location: St.Petersburg
Contact:

Re: GFS without backup copy jobs?

Post by DGrinev » Aug 31, 2017 11:24 am 1 person likes this post

Hi,

You can create another repository on the same volume, however, it doesn't meet best practices and 3-2-1 rule.
GFS retention cannot create and retain its restore points without a backup chain of the copy job.
Please review this thread for additional information. Thanks!

sosborne
Enthusiast
Posts: 37
Liked: 2 times
Joined: Jan 30, 2018 12:06 pm
Full Name: Simon Osborne
Contact:

Re: GFS Copy job to manage retention on the same repo.

Post by sosborne » Feb 02, 2018 4:46 pm 1 person likes this post

I have just run into this same issue today. Now I can understand the spirit of this requirement what with the 3-2-1 rule. And we will be having everything copied offsite to an identical server/disk setup anyway, with key servers also being replicated.

But what we like so many others are trying to achieve is a monthly and yearly retention off of the original backup job. So that we can ultimately have all of our short term backups and long term backups at both sites in one repository (once I setup another backup copy to do that).

It seems silly to add this restriction in especially as we lack the ability to do GFS on the original job. Is it likely in the future to be able to either override the target repository requirement and/or set GFS in the original backup job? After all we are all adults and as long as we are explicitly accepting the consequences then no harm surely.

But now I have to create a separate folder on the same physical RAID set as the source repository called GFS or archive and then create another repository which I point at this folder. Its not a massive chore but it seems unnecessary.

After all the first place you tend to need your archival data is in your main site?

mbandanza
Lurker
Posts: 1
Liked: never
Joined: Jun 14, 2019 1:32 pm
Contact:

Re: GFS Copy job to manage retention on the same repo.

Post by mbandanza » Jun 14, 2019 1:36 pm

+1 on getting GFS into simple backup job as soon as possible. Will save me time, disk space and cut down on the jobs I need to keep my data where I need it. To much data moving with multiple backup copy jobs for one simple backup. Having to go to the same disk but different repository for GFS on dedup appliance is a waste of time and space.

Thanks

Post Reply

Who is online

Users browsing this forum: No registered users and 59 guests