From where to backup zfs bind mounts with proxmox-backup-client

[Str1atum]

Hi!

I have a zfs pool on my Proxmox host which is used for the VM/LCXs and data storage. I use bind mounts to a LXC which serves as a Samba file server / NAS and then shares the data storage to all the clients.
This is naturally not backed up to Proxmox Backup Server so I use proxmox-backup-client to backup up the data storage on file level.
I just wonder where would be the best point to avoid data corruption? I could do it on the Proxmox host, in the NAS-LXC or in another VM which mounts the SMB shares.
I first tried on the NAS-LXC which is backing up fine as it seems, but there are some strange corruptions to the log files the cron job outputs to one of the shared folders. I read those log files on another VM with promtail / loki to visualize them to a grafana instance and the log file gets corrupted after some appends and just outputs "^@^@^@^@^@" - so I wonder if I am missing something in the backup process.

Any clues?
Str1atum

 

[fireon]

I do it completely differently. (if I understand you correctly...)
I backup my LXC's (only the data) with BackupPC directly via SSH to the Proxmox host. This means I don't have a layer in between and the backup works independently of the container. It has worked perfectly for many years, including Recover.

 

[Str1atum]

Weil, I don‘t think I‘d need another piece of software since PBS does the job extremely well. I just wonder - from a file system perspective - what the best solution would be.

 

[fireon]

If you didn't use bindmounts but a subvol, you wouldn't have to worry about the backup. Then it would work with PBS. Wouldn't that be an option for you?

 

[Str1atum]

You’re right, I could just upsize the NAS-LXC and store everything there directly. It’s all on ZFS anyway.
Are there any disadvantages from this approach?
As I planned my setup I didn’t think about PBS so I wanted an easy method for file level backup and also the storage allocation is more flexible as I think you cannot downsize the LXC. I have different quotas for subvolumes at the moment, but I guess I could to that with Samba as well.

 

[Str1atum]

What would be an elegant way to apply quotas to the different smb shares the LXC provides?

 

[fireon]

You’re right, I could just upsize the NAS-LXC and store everything there directly. It’s all on ZFS anyway.
Are there any disadvantages from this approach?

I use drive for root (default) and for datastore like SMB i add a second drive to LXC.

There are disadvantages with LXC, yes. That's why I no longer use LXC for large storage. PBS always has to go through the whole container space when backing up. With a full KVM, PBS does not have to do that, it is fast. Also, quotas in LXC for individual folder -> the feature probably will be removed. The implementation is very complex as i read.
For these reasons, I use a KVM or natively directly on ZFS for Samba/NFS datastores. I personally prefer the first method because it simply makes everything easier.

You have to decide for yourself what is right method for you.

 

[Str1atum]

So I’d run a KVM as base system and attach a second virtual hard drive for data.
Would that still enable incremental backups through PBS?
And If I use zfs as file system for that secondary hard drive to get easy quota, does that no degrade performance significantly?

 

[fireon]

So I’d run a KVM as base system and attach a second virtual hard drive for data.

Yes.

Would that still enable incremental backups through PBS?

Yes.

And If I use zfs as file system for that secondary hard drive to get easy quota,

You use for example ext4 on a virtual harddrive. Where this virtual disk is stored and what storage format is used doesn't matter. And yes, I also use a ZFS pool for this. Quota works according to the manufacturer of the Linux system you are using. Thus, the quota feature is independent of LXC features. Which is a big advantage.

does that no degrade performance significantly?

A little. If you're still working with older kernels like 5.0 or 4.10, 40Gbit can be challenging.