Linux Immutable Repository

[perjonsson1960]

Folks,

We are about to install Linux Immutable Repositories in a physical (agent) server.
Which Linux distribution(s) do you recommend from B&R's point of view?
I understand that we should use the 64-bit XFS journaling file system with both dedupe and CRC error correction.
Is the Linux distribution irrelevant? And what about the Inline Data Dedupe? Is that still working with a Linux repo, or should the filesystem's dedupe be used?
In Windows, where we use the ReFS file system, we have turned off the dedupe in ReFS, and are only using B&R's Inline dedupe.

PJ

[chris.childerhose]

I would check here to see officially supported versions for v11a - https://helpcenter.veeam.com/docs/backu ... ory-server

I am sure this list will change slightly with v12 when released.

[perjonsson1960]

Thank you!

I am confused. In the article you linked to it says: "64-bit edition of Linux must be able to run 32-bit programs. Persistent Veeam Data Movers (pure 64-bit Linux editions) are not supported"

And in this article: https://helpcenter.veeam.com/docs/backu ... rvice.html

it says that "Persistent Veeam Data Movers are required for Hardened repositories and Backup proxies."

This seems a bit contradictory to me. Or am I being unbelievably stupid?

PJ

[matteu]

Hello,

Lot of documentation and procedure you will find for Hardened repository will be on Ubuntu 20.04.
I only install this version to my customer to lost less time if an issue appears and I need to contact support. They will have more people on ubuntu than other distro I guess.

22.04 is not supported with v11 !

[perjonsson1960]

Thank you!

Ubuntu 20.04 with XFS journaling file system seems to be the way to go, since it supports Fast Cloning.

PJ

[FSF1667]

If you really want to have something reliable and stable drop Ubuntu and use Debian 10.
All my repos are under debian and no problem

[Gustav]

We run the Ubuntu LTS version with great success = zero issues.
The version we use is 20.04, though a newer is out - should make no major difference.

See my post on the subject and the linked article series: post443096.html.

[perjonsson1960]

Our Linux Hardened Repository is now up and running, and we are using it for our backup copies.

A couple of questions:

1. If I set the immutable retention on the repository to 7 days, then the retention in the backup jobs must be 7 days or more, right?
2. I assume that merge and defrag/compact operations are not possible as long as the backup files are immutable, but what about full backup files in the chain that are no longer immutable? Is the "Defrag and compact" option useless in jobs that write backups only to hardened repos? Or is it still recommended to use that option?

Edit: I just noticed this info in the repo properties: "GFS full backups are made immutable for the entire duration of their retention policy."
I guess that kind of answers question number 2.

PJ

[Gostev]

Please note that 7 days may not give you enough time to react to an attack, I would recommend at least a few weeks.

1. Not necessarily. However, retention policies lower than 7 days will fail to delete backups because they will still be immutable.

2. Backup modes with merge are not supported for backup jobs pointing to immutable repositories (you will not be able to configure a job like that). While defrag/compact only applies to backup files created by such backup jobs

[perjonsson1960]

Thank you! I have changed the retention to 30 days.

[perjonsson1960]

An immutable retention on the repo of 30 days, and a retention of 30 days in the backup job, is that okay, or should the job retention be slightly highter than the repo retention in order to make it possible to delete the oldest backup files?

[Gostev]

Same should be OK, but best to make the retention policy slightly higher (to tackle unexpected backup job delays etc.)
But nothing terrible will happen either way as backups that could not have been removed will be removed later automatically.

[perjonsson1960]

Thank you!

[perjonsson1960]

If we start to notice that the free disk space on the hardened repo is getting too low, is it possible to lower the immutable retention on the repo in order to free up space?

[Gostev]

Sure. This of course won't affect existing backups, which will remain immutable according to the original setting, but new backups will be made immutable for less time.

[perjonsson1960]

Thank you again!

[perjonsson1960]

I read somewhere that all the full backups in a GFS chain will be immutable until the job's retention has passed, regardless of the repository retention setting. But I have a backup copy job that puts the backup files on an immutable repo, with a GFS policy of 4 weekly, 12 monthly and 2 yearly. And all the backup files have an "Immutable until" date that seems to follow the repo's retention of 30 days. How is B&R handling this?

It is notable that the backup chain is newly created, and so far only consists of 15 restore points, thus the repo's retention has not yet been reached.

[Gostev]

It's hard to guess over forum posts, please contact support to review your configuration. For example, if hardened repository is a part of SOBR with the Move policy enabled, then it won't make GFS backups immutable for the entire duration of their retention policy on Performance Tier as this would make moving them to Capacity Tier impossible.

[perjonsson1960]

There are two hardened repositories together in one SOBR, but the Move policy is not enabled.

[perjonsson1960]

Is it not possible to put NAS backup copies on an immutable SOBR? When I do that, I get an error in the SOBR properties saying that I need to enable a GFS policy for the backup copy jobs. But as far as I can see, there is no such option in the NAS backup jobs, only the "Keep all file versions for the last xx days" option. We are still running B&R v11a, if that is significant.

[perjonsson1960]

I have googled a little, and it seems that immutability for NAS backups is not supported in v11a. Right?

[Mildur]

Right.
It is supported starting with V12.

Best,
Fabian