Full Backup and Synthetic fulls config question

[BackupSlacker]

Is there any way to setup backup jobs so that the following is true? (if not what is the closest I can get?)

-Full backup happens once per week, and incrementals every day
-Synthetic full backups created weekly utilizing ReFS Fastclone
-Only keep a single Full backup and keep the synthetics for a longer period of time (including some kind of GFS policy to keep years worth etc.)

The basic idea is that I really want to have a full active backup happen once per week but I do not want to incur large space usage and therefor utilize synthetics for every other full backup that is older. I also would preferably like to have incrementals that go back at least 30 days.

So like day 1-6 are incrementals 7 is the active full backup day 8-13 incrementals day 14 synthetic full and so on with only synthetic fulls and incrementals for a 30 day period and then a GFS policy for monthly and yearly synthetic fulls.

[LickABrick]

Synthetic fulls and active fulls are the same thing on disk. Active fulls pull the data from your hypervisor again while synthetic fulls merges the existing restore points into a single vbk.

Active fulls will put some extra stress on your environment which might not be desirable. Also in my experience synthetic fulls are much quicker (but this might vary depending on the environment).

[BackupSlacker]

okay just so I understand fully. Active fulls will still utilize FastClone space saving? for example if all I did was active fulls every day then I would only incur the space usage of 1 active full and then the rest would be delta (incremental) data usage?

[LickABrick]

No, only synthetic fulls will make use of ReFS

[BackupSlacker]

okay so that comes back to my question, is what im asking at all possible? I want weekly active fulls but i don't want to keep 4 active fulls but I do want to keep 30 days of daily incrementals and my understanding would be I would end up with 3 or 4 active fulls because im doing them weekly but I would prefer 1 active full that is at most 1 week old and then the rest of the older ones be synthetic fulls.

[PetrM]

Hello,

You can create full backups in either synthetic or active modes. Synthetic backups take advantage of REFS to ensure fast clone and space savings. You can schedule weekly synthetic backups and enable GFS-retention to store backups for a longer period of time.

The only way to achieve your goal to have one active full backup and several synthetic ones is to script switching of full backup creation methods by using our PowerShell module. However, I'm not sure that I clearly understand this goal: why do you want to use both active and synthetic fulls? Why don't just always use synthetic backups if your storage allows you to leverage REFS capabilities?

Thanks!

[BackupSlacker]

I guess my reason is for sanity reasons, having a true clean backup (active full) periodically (weekly) but also not experience what I guess I will have to experience which is 4 active fulls to fulfil my 30 days worth of daily backups.

[PetrM]

Hello,

If you're worrying about validness of backups, I'd suggest to set up SureBackup job to automatically test restore workflows in the isolated environment and enable health check to verify backup data integrity. Also, forever forward incremental chain might be an option, in this case you'll have just one full backup on repository and daily merge can leverage fast clone on REFS.

Thanks!

[BackupSlacker]

I appreciate that and utilize surebackup but not every application has a way to verify integrity. For example MSSQL I can mount the databases and run an SQL command to check the integrity of the database but there's not always an option to check the actual integrity of a specific applications and its accompanying databases/files etc. I just thought it would be nice to have a full backup that i know is more than likely as clean as it can get.

[PetrM]

You can run pre-freeze and post-thaw scripts to ensure data consistency of applications that do not support VSS. I hardly envision an issue with application data in backup as long as application-aware image processing is in use and SureBackup or Health Check do not see any corrupted blocks. Anyway, feel free to use our PowerShell module to script the desired behavior.

Thanks!

[c.haydock]

So... I'm looking at my backup job right now to confirm this is possible.. When you get to the "Storage" section for configuring the job, click on the "Advanced" button. From the new window, under the "Backup" tab (the first tab), The top half of that section is labeled "Backup mode" and within that section I'm able to pick "Incremental backups" and underneath that is a checkbox that says "Create synthetic full backups parodically" and next to that is a button "Days..." which will let you pick which day of the week to do that on. We'll say you pick Friday as your synthetic full backup day. Now... on that same page, the lower half of the window is labeled as "Active full backup" and there's a checkbox you can select for "Create active full backups periodically". I believe you would want to select the first option of "Monthly on:" and then pick a corresponding Friday of the month (e.g. First Friday). And, don't forget to also click on "Months..." to pick which months you want that to happen on (I presume every month?). I've confirmed that the job will will accept both periodic synthetic as well as periodic active fulls being simultaneously chosen.

With that, depending on what you set for your retention schedule, you'll get a periodic active full mixed in with your synthetic fulls. As others have already noted though... You'll stress your systems hard when doing an active full as it ignores any existing backups and instead pulls a completely fresh set of data from your production environment to make the full backup file. This usually isn't too big of a deal unless you are very constrained for space. But, depending on your backup size and internet connection, it can be especially important when pushing data off-site. When an active full is taken and copied off-site it pushes the full backup file, not just the incremental difference like a synthetic full would do. And, as also noted... You would have very limited block clone savings using such a schedule. Every time you do an active full, any subsequent backups can leverage block clone to reference that one active full... but once you take another active full... the block chain has to start all over again. So, if you did an active full once a month, you'll only get block clone savings for the other 3 weekly backups in between the next active full.

SO... depending on what your goals are and your motivation for periodically taking active fulls... You may want to consider standing up two parallel jobs. Have one be your primary long haul GFS + Off-Site backup job that can leverage block cloning to its fullest every step of the way. And then a second job that runs once a week (perhaps on a Saturday or something) that just does active fulls and keeps those on-prem only for a 1-month retention as you had mentioned. OR... depending on which version of Veeam you are using... run a SureBackup job to verify the integrity of your backup chain (which I would recommend for Active or Synthetic Fulls regardless). Just food for thought.

[david.domask]

I would actually take a different approach to this. Your goal is clear enough: Periodic Active Fulls and the old ones thus become archival and used for space savings, but currently block cloning doesn't work like that.

What if instead you had different targets for your long term storage like perhaps Object Storage of some sort? It can even be a local one. You can set it up to Move old backups out and because of how the offload algorithm works, only unique blocks will be moved, the original Fulls will be dehydrated to save space, and seems like you meet your goals. Granted, this means an extra job and an S3 system to consider, but it would handle it pretty readily.

Outside of that I'm not sure it's possible to quite achieve what you're looking for without revisiting some of the premises of the scenario. I actually think you should reconsider the Active Full part, as with xfs and refs, both have integrity scrubbing built into the file system, so the moment there is a block that got bitflipped for any reason, you will know. XFS has a fair chance to "heal" it out of the box with its toolset, and ReFS can be configured to do the same.

I would actually position that the same threat scope you're likely trying to avoid with Active Fulls still exists; bitrot/flips on the repository. The Synthetic Full process itself isn't a full health check, but it has some validation that the data it's reading/writing is consistent from source and target file, so that part should not be an issue. Reads from production also are CRC'd so the issue likely isn't production reads, it's what happens to the data while it's on the repository, and an Active Full is no more resistant to this than a Synthetic Full. All in all, I understand your major concern is probably the Synthetic part of the process itself, and the only real counter I can give to that is that there haven't been any specific Synthetic Full (virtual ones included) issues for 6+ years that I can remember, so it's pretty stable.

> I just thought it would be nice to have a full backup that i know is more than likely as clean as it can get.

Thing is, an Active Full actually doesn't mitigate this in any way, @BackupSlacker. It adds workload to production and means that you can't use any space saving techniques aside from repository deduplicaiton and inline dedup/compression, but in terms of integrity validation, you're not really any better off. Same data, same problem scope for the data on the repository, just it's taking more space.

Surebackup can be set to run validation scripts of your own design to best meet your needs; these are executed from the Backup Server, but you can set it to connect to the machines in the lab and do whatever validation you want, and I think that's what you're actually wanting.

With the above I'd really reconsider the approach towards Active Fulls, as I'm not sure that they actually meet your needs based on what you described.