Config Backup to SoBR

[veremin]

Thanks for the update, do we know when V12a might be released?

Hard to tell right now (as even v12 hasn't gone GA yet), you can check the previous version release dates and get a rough estimation of how fast minor versions are released after major versions. Thanks!

[seirui]

I'm not quite a +1 on this, even though backing up to the SOBR would be an improvement.

I'd rather be able to backup to a Cloud location. For Azure, the SOBR needs to be pointed to an individual folder in the SOBR. I can create a separate folder in the Azure repository, that's not used for the SOBR, but I can't point the Config Backup job to it. If I could, I'd get offsite backup of the config, and it would not be in the "SOBR Zone", so to speak.

So, could I get a backup to cloud, instead?

[Mildur]

Hi Gary

This will be possible in V12.
Config Backup directly to object storage.

Best,
Fabian

[bct44]

Great news, can we expect config backup immutable soon?

[Mildur]

Hi Bertrand

It will not be immutable in V12. But we have it on our feature request list. We count yours as +1.
Unfortunately we cannot provide any ETA when and in which version it may be released.

Thanks,
Fabian

[jim.lowry]

@bct44
While you are waiting for the config backup job to support the immutability API calls directly, a workaround would be to use immutability on the NAS file share (or NAS appliance) itself. That will be immutable storage that locks each file per the desired immutable time length. NAS backup immutability is a new feature coming in v12 and will be part of the configuration wizard for NAS backup jobs.

This same concept would also work for any image based backup that targets immutable storage for its backup or backup copy jobs. If the config backup targets that image, then the image will make all of the files immutable when writing to object storage. This is something you can do right now and you do not need to wait for v12 GA to be released.

[SnakeSK]

Thats an ugly workaround

[jim.lowry]

True statement - it's definitely not elegant. But it does work! There's no requirement for a workaround to be pretty, right?

Thankfully, we know the elegant solution IS coming relatively quickly.

[bct44]

Indeed i will wait the elegant solution, i prefer my workaround with a bash script and a crontab on my xfs repo but thank you for the suggestion @jim.lowry

[ratkinsonuk]

Another 'version' of Jim's solution is the AWS DataSync service (https://aws.amazon.com/datasync/), which effectively mirrors a local share onto AWS S3 object storage. Useful if you want something fairly simple and near-zero maintenance.

Rob.

[cgsm]

I have somewhat of a workaround for this in place, at least solving the problem of "getting the config backup offsite". I created a small SMB share (10GB) on an offsite repo (where backup copies are shipped to). I then created a Windows Scheduled Task running a batch file that (1) mounts this share, (2) copies the config backups from the local VBR server disk to the SMB share, (3) unmounts the share. Config file backup backed-up? Yes. Immutable? No. Tradeoffs...

Would I appreciate some method of "copying config backups" built into VBR?..yes. I suggested somewhere a while back that there could simply be two destinations/repos set for config file backups. A file backup copy job that could also remove old files would help (see below).

Note, the VBR file backup copy job functionality doesn't work for this since it won't remove old files, hence the scheduled task/batch file combo.

[Gostev]

Note that you will be able to use File Backup jobs in V12 to make immutable backups of any files.

[jim.lowry]

I'll add another quick amendment for the workaround. If your targeting an image, you can leverage Hardened Linux repos (HLR) on the XFS file system, then leverage object immutability on the back-end. For example, if you create an NFS mount on a HLR server's volume using XFS, use that NFS mount as the repository for the config backup job, then XFS will make that data immutable at the volume level as it's written. Then you can take a backup image of that machine and leverage object immutability using SOBR's capacity tier functionality. And that will work right now!

Granted, it's still not the permanent, elegant solution, but it's viable and not that complex to set up. v12 will add a lot of options, as has already been noted, but this is a solid workaround I have many partners using in the field today.

[Herbert Sz]

Note that you will be able to use File Backup jobs in V12 to make immutable backups of any files.

I think this is a nice workaround in V12:
people tend to forget that one can do a File Backup job of a folder of a managed server, too, no need to define a SMB share (I mean a REAL File Backup, not the file variant of a machine block backup job).
One could e.g. do a daily configbackup to the default repo on the C: disk of the backupserver (what we usually do not recommend , but in this case it is just an interim step), lets say at 19h, and run a File backup job of this directory at 19h30 targetting an immutable repo.
Then you have all config changes of that day on immutable space ...



... and all daily versions you want to keep of your config backup available via the file explorer:

[r.bernhard]

Any updates on this? Is the feature to enable ConfigBackup to SOBR still on track for v12a?
It is the only thing that is holding us back from deploying our shiny new xfs repository.

Also, is the release date for v12a already set? Does anybody know when it is to be expected?

Best regards

[tyler.jurgens]

As a workaround, create another directory on your XFS server and create a repository pointing to it. As long as that folder isn't inside the path of the other repository you are using as part of the SOBR, you'll be fine.

That one XFS server will have a standalone repository and a repository as an extent in your SOBR.

[jim.lowry]

Regarding the upcoming release date and confirmation whether this feature is included in v12.1, formerly known as v12a, I’ll defer to the product team monitoring this forum post.

However, I will say that we will have public announcements addressIng these questions during the upcoming VeeamON Resiliency Summit. Registration for the VeeamON Resiliency Summit is now LIVE https://www.veeam.com/veeamon-resiliency-summit. This event is happening on Oct. 24 at 10:00 am ET.

If you decide to follow the suggested workaround that @tjurgens-s2d mentioned (great suggestion, Tyler), make sure to have a backup copy job of that XFS repo. That way you can get the config backups offsite. It’s always wise to keep a config backup offsite using a platform that is accessible via the public internet. Something like One Drive, Dropbox, Google, etc.

[r.bernhard]

v12.1 was released, and in our lab setup I still get the error "Selected repository is not supported for a configuration backup. Please contact your service provider for futher information." when trying to set the configuration backup target to a CC SOBR repository.
Did anybody else succeed in backing up their configuration data to a SOBR repo?

[Gostev]

12.1 adds support for immutable configuration backups to object storage. I'm not sure if there are any changes about CC SOBR. I see nothing in the official What's New about this.

@veremin please share the current status and our plans (do we think it's a heavy feature to add?)

[veremin]

As I recall, configuration backups do not respect the extent selection logic (used from initial placement to evacuation), so we will have to either modify their format first for them to be the subject of the same algorithm or implement some alternative approach. It was not a trivial task to achieve, so the feature has been postponed to the next major product version. Thanks!

[GeraldS]

Has this been released yet? I'm on 12.2.0.334 and the SOBR is still not selectable as a target for the configuration backup.

Edit:

Well, it seems it hasn't. The documentation still notes:

Important
You cannot store configuration backups in external repositories and scale-out backup repositories.