GFS for primary backup jobs

Availability for the Always-On Enterprise

Re: GFS for primary backup jobs

Veeam Logoby jmmarton » Thu Jan 19, 2017 2:20 pm

In your case, you could theoretically use ReFS still and leverage the new block clone feature in ReFS 3.1. If you leverage that 50 TB disk array and make your primary repo Server 2016 formatting the disk on that array as ReFS, then creating a second folder for a second repo in order to use a BCJ with GFS would still have the ReFS advantages for all the GFS restore points. After all, each of those is a synthetic full. If you've already formatted your primary repo as NTFS or if it's not even Server 2016, then you'd have to create an additional LUN which is attached to a server running 2016 and then use ReFS.

Joe
jmmarton
Veeam Software
 
Posts: 628
Liked: 74 times
Joined: Tue Nov 17, 2015 2:38 am
Location: Chicago, IL
Full Name: Joe Marton

Re: GFS for primary backup jobs

Veeam Logoby EricJ » Thu Jan 19, 2017 2:29 pm

Thanks for the reply, Joe. We do have the 50TB array formatted as ReFS 3.1, and it works amazingly well for the primary backups. Synthetic fulls are created very fast and take up very little space. However, it seems when I do my first backup copy to a different folder on the same volume, it creates a full copy of all of the data. I have a 5TB job, and if I do a backup copy of that job, it seems to make a bit-for-bit copy and I lose 5TB of free space on disk. I haven't tested yet, but my hunch if that subsequent backup copies will leverage that initial backup copy and take up little space (since the 9.5 documentation says fast clone works on backup copies), but it still requires me to use up 10TB of space for the one 5TB job. It seems since I'm "tricking" Veeam into thinking my second repository is on a different disk, it doesn't bother to attempt to use ReFS to clone the primary copy into a backup copy. Or maybe I have something misconfigured? I will know more after a few more backup copies run.

Thanks,
Eric
EricJ
Novice
 
Posts: 4
Liked: never
Joined: Thu Jan 12, 2017 7:06 pm

Re: GFS for primary backup jobs

Veeam Logoby jmmarton » Thu Jan 19, 2017 4:06 pm

You are spot on. The BCJ will initially create an additional copy of all the data (which in some regards isn't necessarily a bad thing), but any GFS points created will be synthetic fulls that should fully leverage block clone within ReFS. So there's some additional space used but in the end you'll still be getting the benefits of ReFS, and with the 19 GFS retention points (4 weeklies + 12 monthlies + 3 yearlies) you'll still have immense space savings.

Joe
jmmarton
Veeam Software
 
Posts: 628
Liked: 74 times
Joined: Tue Nov 17, 2015 2:38 am
Location: Chicago, IL
Full Name: Joe Marton

Re: GFS for primary backup jobs

Veeam Logoby mkaec » Thu Jan 19, 2017 5:28 pm

It makes sense that ReFS 3.1 goodness would not apply to backup copies. One option is to ditch ReFS and use NTFS. Then you could turn on NTFS deduplication which would dedup the backup copies against the primary jobs. But, I don't know if I would consider that a "better" solution. There would be a lot lost in moving away from ReFS.

I think the ReFS 3.1 cloning functionality actually adds to the case to have GFS available to primary jobs. Why force someone to use double the repository space just to keep long-term backups at the primary site?

Keeping long term backups off-site, when both the primary and secondary repositories are disk based, actually seems counter-intuitive to me. My use for long term backups is to handle the restore request of "I accidentally deleted a file 2 months ago and am just now getting around to asking about it." If I need to go to the off-site backup for DR, I'm going to want to restore from a recent backup.
mkaec
Expert
 
Posts: 168
Liked: 43 times
Joined: Thu Jul 16, 2015 1:31 pm
Full Name: Marc K

Re: GFS for primary backup jobs

Veeam Logoby jmmarton » Thu Jan 19, 2017 5:50 pm

I would think the opposite: ReFS builds the case of having GFS in copy jobs. The reason being is that if the GFS restore points were in the backup job, all of those are pointers to the same set of blocks as the regular backup. If you run into a problem all those GFS restore points are worthless. But if you have an additional copy of all those blocks, which BCJ requires, then you're less likely to lose all your GFS restore points.

This doesn't remove the overall use case of having GFS in primary backup jobs. I can see reasons for it and understand the feature request. I just don't think ReFS is a reason. :-)

Joe
jmmarton
Veeam Software
 
Posts: 628
Liked: 74 times
Joined: Tue Nov 17, 2015 2:38 am
Location: Chicago, IL
Full Name: Joe Marton

Re: GFS for primary backup jobs

Veeam Logoby EricJ » Thu Jan 19, 2017 9:43 pm

I do agree that having separate copies of the data is better, and once we get a second disk array to replace tapes at our third location, I won't care as much about this issue.

However, I do think ReFS makes a stronger case for GFS in primary backups. In the past, it may have been too slow or would consume too much disk space to keep 30 daily, 4 weekly, 12 monthly, and 3 yearly at the primary site. So, we'd keep 30 dailies on primary disk, and the GFS at a secondary site on tape.

With ReFS, keeping the GFS copies on site is very fast and uses very little space. So now it's given me the desire to have GFS at the primary and the backup site. This way, there's nothing lost if a single backup location goes away. Plus, our primary backup repo is much faster than our secondary (tape) repo, so for quick restores I'd love to have them also available on disk. Maybe you mean that this was already possible somehow before ReFS, but for me that was the trigger that made me wish for it.

I understand that you want to encourage customers to keep at least two copies of backup data, and so it's not currently allowed. But it would be nice if it could at least be enabled through a registry key after some kind of warning or disclaimer. 8)
EricJ
Novice
 
Posts: 4
Liked: never
Joined: Thu Jan 12, 2017 7:06 pm

Re: GFS for primary backup jobs

Veeam Logoby jimmycartrette » Thu Feb 02, 2017 2:24 pm

I agree - just coming from Netbackup, I'm finding setting GFS style retention for things difficult. In Netbackup, I'd have something like 30 days of daily, and weekly for a year on my primary, all copied to my DR repository. Now that I've already created a primary site repo with my free SAN space with 2016 ReFS, I'm finding it annoying trying to get the right retention and keeping the ReFS benefits of space savings.
jimmycartrette
Lurker
 
Posts: 1
Liked: never
Joined: Thu Feb 02, 2017 2:13 pm
Full Name: JC

Previous

Return to Veeam Backup & Replication



Who is online

Users browsing this forum: cfanta@theitco.net, ericlaiys78, Google [Bot], jmmarton, mpark and 49 guests