mounted SMB share for linux repo work?

[asdffdsa6131]

Hello, Thanks,
I have done a lot of testing for over a month now.
Mounted SMB share works with linux repo and linux hardened repo.
Backups work, backup copy jobs work, health checks work, veeam.validator works, restore works, instant restore works.

The docs mention mounted NFS but not mounted SMB, Why no mention of mounted SMB?
https://helpcenter.veeam.com/docs/backu ... ml?ver=120
"You can add a Linux server with local, directly attached storage or mounted NFS as a backup repository"

For hardened repo, https://helpcenter.veeam.com/docs/backu ... ml?ver=120
"As the hardened repository requires the block storage, you cannot use the following storage types:
A Linux machine with the mounted SMB (CIFS) volume"

Despite that statement, backups work, health checks work, backup copy jobs work, restore works, instant restore works.

I really would like to use mount SMB share, does anyone else use it or know a reason why not to use it?

Thanks,
David

[Mildur]

Hi David

https://helpcenter.veeam.com/docs/backu ... ml?ver=120
"You can add a Linux server with local, directly attached storage or mounted NFS as a backup repository"

If it's missing in the user guide, you can assume it's not supported (not tested by us or it doesn't work).
In a Linux world, you normally use NFS mounts and not SMB mounts. SMB shares can directly be accessed by dedicated windows gateway server or the backup server itself. Using a linux machine to mount the SMB and then made it available as a Linux repository doesn't make any sense.
You can also do the same with NFS. It doesn't have to be mounted to a Linux server first.

For hardened repo, https://helpcenter.veeam.com/docs/backu ... ml?ver=120
"As the hardened repository requires the block storage, you cannot use the following storage types:
A Linux machine with the mounted SMB (CIFS) volume"

Correct. For the hardened repository, we use the filesystems capability to set "immutable" flag. This flag is not available for NFS or SMB mounts. A Linux limitation which no workarounds exists. Our recommendation for hardened repositories is to use a server with locally attached disks. Keep it simple and safe.

I really would like to use mount SMB share, does anyone else use it or know a reason why not to use it?

May I ask, why it has to be a SMB share? SMB shares is the least recommended repository type for Veeam Backups. You will loose a lot of functionality and space saving features (FastClone). Additionally, it's not a really secure backup target. No immutability, which makes the backups vulnerable if attackers get access to the share or backup server.

Best,
Fabian

[asdffdsa6131]

Fabian, Thanks much,

You will loose a lot of functionality and space saving features (FastClone).
This is for my home lab, not production and the version of VBR does not support cloud.
I use VBR in a dumb mode, poor mans immutability, once Veeam writes .vib|.vbk, that file never changes.
No synthetic, reverse, fast cloning, etc..

For the last four years, I have been using `rclone copy -immutable` to copy the newer backup files to wasabi and older backup files to aws deep glacier.
That works great but now I am looking for additional solutions. I have even used `rclone mount`and did a instant restore from that mount. super slow but worked.

Additionally, it's not a really secure backup target. No immutability, which makes the backups vulnerable if attackers get access to the share or backup server.

The Veeam backups are encrypted so I hope I can trust that part.

For the last few months months, I have a new variation of cloud backup using mounted SMB.
Backups work, backup copy jobs work, health checks work, veeam.validator works, restore works, instant restore works.
The SMB share is hosted by Hetzner StorageBox, the filesystem is ZFS, SMB is version `3.1.1` and it has automatic and manual zfs snapshots.
Yes, I agree, not fully secure backup target but OK for backup copy jobs and if a problem, I can just recover using snapshot.

---------------------------
So then I tested a cloud vm, as a linux non-hardened repo with that SMB mount as the backup repository.
Backups work, backup copy jobs work, health checks work, veeam.validator works, restore works, instant restore works.
The cloud vm and the SMB share are in the same data center connected over a private VLAN, so the SMB share is not exposed to Internet.

---------------------------
So then I tested a cloud vm as a linux hardened repo with that SMB mount as the backup repository.
Backups work, backup copy jobs work, health checks work, restore works, instant restore works.
Everything I have tested works!
The cloud vm and the SMB share are in the same data center connected over a private VLAN, so the SMB share is not exposed to Internet.

---------------------------
And now finally, I get to my real issue.
"For the hardened repository, we use the filesystems capability to set "immutable" flag. This flag is not available for NFS or SMB mounts. A Linux limitation which no workarounds exists. "

Check this output, Veeam sets`user.immutable.until`correctly, 7 days from the time of the backup.

mount -t cifs -o gid=1000,uid=1000 -o credentials=~/.credentials //xxx.your-storagebox.de/xxx-sub2 /hard01
xattr -l /hard01/backups/ABJ_X:_FOLDER-_HARD01/192.168.62.233/'ABJ_X:_FOLDER-_HARD01 - 192.168.62.233D2023-11-05T115841_300A.vbk'
user.immutable.until: 2023-11-12 19:47:02

---------------------------
"not tested by us"
So is that the real reason, or am i wrong about the "immutable" flag or some other issue?

Thanks so much for taking the the time to read all that!

[david.domask]

> The Veeam backups are encrypted so I hope I can trust that part.

Sure, it's quite fine and reasonable. Just make sure to have encrypted Configuration Backups of Veeam and also best to have the secret in a properly secured secrets manager.

> The SMB share is hosted by Hetzner StorageBox, the filesystem is ZFS, SMB is version `3.1.1` and it has automatic and manual zfs snapshots.

Do I get it right this is some SMB share as a service? Basically they offer you an SMB path and in the background do snapshots on ZFS?

Fabian's statements about unsupported are true, and actually regarding that the immutable worked, it's quite unexpected for me. I _quickly_ threw together a similar setup with a local windows SMB share and my ubuntu linux hardened repo and the chattr call failed due to some iotcl error which I didn't bother to look into. Basically I'm not sure why it would work for your setup, but long story short is that it's not really considered secure, it's not a common setup and I'm not sure why you'd want to introduce the Linux server element with the mount like this. Wouldn't just a gateway and adding it as SMB share be more simple?

Basically, while it won't get support as per the User Guide, if you're okay without immutability and understand the risks of an SMB share, there's no reason you can't use your setup. I don't quite get why you mount it to the Linux server, but if it's stable for you, then go for it. But the setup would not get support if you need to open a case, so just be aware of this element please.

[asdffdsa6131]

david.domask, Thanks much,

"Do I get it right this is some SMB share as a service? Basically they offer you an SMB path and in the background do snapshots on ZFS?"
Yes, you got that right and offers much more than that, including sftp, webdav and a SSH with limit bash shell which supports md5sum.

"I'm not sure why you'd want to introduce the Linux server element with the mount like this"
Well, a matter of cost, $2.32/TiB/Month. and it is a great destination for rclone over sftp with checksum support. and to augment VBR, which lacks cloud repo, in the version I am using.

I am using a cloud vm as a repo, but as you might know, block storage is super expensive to add to any cloud vm.
So the mounted SMB gets around that cost.
"Backups work, backup copy jobs work, health checks work, veeam.validator works, restore works, instant restore works."

"it's quite unexpected for me"
Me too, as I am new to linux. Basically, I tried it and it worked as per the output I shared.
Hetzner must have some amazing techs running their infrastructure.
IMHO, If Hetzner can do it, for sure, Veeam should be able to that.
That is my whole point here. Everything i wrote about works perfectly. Veeam should embrace mounted SMB.
https://www.hetzner.com/storage/storage-box

"Wouldn't just a gateway and adding it as SMB share be more simple?"
I wrote about, as option 1, using the SMB share direct over the internet, using gateway, without a linux repo.
"Backups work, backup copy jobs work, health checks work, veeam.validator works, restore works, instant restore works."

Notice below that the "GatewayAutoDetect : True"

Code: Select all

Get-VBRBackupRepository -Name "BR:SMBTEST01" | Format-List

Info                            : Veeam.Backup.Model.CBackupRepositoryInfo
Host                            : 6745a759-2205-4cd2-b172-8ec8f7e60ef8
Id                              : 3bb7240e-a710-49cb-a619-fdc6fdac1f42
Name                            : BR:SMBTEST01
HostId                          : 00000000-0000-0000-0000-000000000000
MountHostId                     : 6745a759-2205-4cd2-b172-8ec8f7e60ef8
HelperHostId                    : 00000000-0000-0000-0000-000000000000
CreationTime                    :
Path                            : \\redacted.your-storagebox.de\redacted
FullPath                        : \\redacted.your-storagebox.de|redacted
FriendlyPath                    : \\redacted.your-storagebox.de\redacted
ShareCredsId                    : 39d51bc0-64b7-4af0-8b6a-7694dc793d0a
Type                            : CifsShare
Status                          : Ordinal
IsUnavailable                   : False
Group                           : BackupRepository
UseNfsOnMountHost               : True
VersionOfCreation               : 12.0.0.1420
Tag                             : 3BB7240EA71049CBA619FDC6FDAC1F42
GatewayAutoDetect               : True
IsObjectStorageRepository       : False
IsTemporary                     : False
TypeDisplay                     : SMB
IsRotatedDriveRepository        : False
EndPointCryptoKeyId             : 00000000-0000-0000-0000-000000000000
CryptoKeyId                     : {00000000-0000-0000-0000-000000000000}
IsEpRepositoryEncryptionEnabled : False
Options                         : Veeam.Backup.Model.CDomBackupRepositoryOptions
HasBackupChainLengthLimitation  : False
IsSanSnapshotOnly               : False
IsDedupStorage                  : False
SplitStoragesPerVm              : True
IsImmutabilitySupported         : False

[david.domask]

Hi @asdffdsa6131 got it, then the idea is a bit more clear. In short, if immutable "works" for you, then feel free to use it; the setup if it's stable for you I don't anticipate long-term issues, but right now it would still be considered unsupported.

So basically, if it works for your home lab, go for it No one will stop you, just understand you're in unexplored territory and that at the time being you wouldn't be able to get a support case for this configuration, but for your home lab probably it's sufficient.

[Andreas Neufert]

To bring this in a "supported" statement:

1) Create Admin account on the Hetzner Storage, do NOT use the password typed in on any of your systems, use a separate system that you never use in your environment. Setup some Snapshots (daily) that can be only deleted by this account. That way you have a fallback if backups are compromised by hacker. => I would use this approach no matter what in your current setup as well. Potentially use IP filters to only allow access from the Linux Cloud VM.
2) Create a "User" for the SMB share with no rights on the snapshots but read/write/execute rights on the share.
3) Create/use the Linux Cloud VM as managed server
4) Add a SMB repository to Veeam while using the Linux Cloud VM (not GeatewayAutoDetect: True). This setup should work with Synthetic Full processing.

Potentially fast cloning processing is working depending on what Hetzner has exposed from SMB APIs (FSCTL_DUPLICATE_EXTENTS_TO_FILE and FSCTL_SET_INTEGRITY_INFORMATION needed).

Sometimes SAMBA Servers allow to store extended attributes (xattr for the immutability) in the extended ACLs, but likely in this case the target storage is not honoring this, it just stores it. So if you mount the SMB share you can just delete the data.
As it is for your homelab I would maybe go as well with the unsupported setup but add the 1) and 2).