Questions about "data hungry" Apps

I’m specifically testing BackupPC, but these could apply to any installed App, regardless of the data volume.

The data store for BackupPC is a folder within it’s own file system , so when that App is backed up by NS8’s own Backup, all of that data is included. Is there a way to exclude certain directories from the NS8 backup.

Can NS8’s backup be modified to separate configuration and data so in cases where the user didn’t want/need the data backed up can still save the configuration.

Second issue. Can I use a mounted directory (NFS/SMB/local disk) as the data directory, so I can keep the size of the NS8 disk/partition down to a reasonable size without having to cater for any App’s data requirements.

Cheers.

1 Like

Yes this is interesting. I include the data volume but indeed do we need it, in somecases yes, somehow it is a matter of feelings

If you have a crash of the server and in the same time you have a crash of your client…yes it will be the day to play lotery, few chances but it exists

It could be a choice but I do not know how to do yet

Search the forum it has been already asked

https://wiki.nethserver.org/doku.php?id=howto:useful_commands#mount_volumes_of_a_container_to_a_specific_drive

I saved it for your sometime ago

I’d already found davidep’s post in the forum, which is repeated in the wiki you reference.

Starting backuppc gives:

2024-10-11T13:43:50-07:00 [1:backuppc2:backuppc2] Error: lsetxattr /home/backuppc2/.local/share/containers/storage/volumes/data/_data: operation not supported

More Google required I guess.

*** Update ***

Probably this:

Cheers.

Maybe not, as a CIFS/SMB mount gives exactly the same error.

So what’s the next step. Has anyone managed to get a remote filesystem mounted as data storage.

Cheers.

2 Likes

After I don’t know how many attempts at trying to use a mounted drive as the DATA volume for BackupPC I finally got this to work after chasing down far too many rabbit holes.

The first problem I hit was:

Error: lsetxattr /home/backuppc1/.local/share/containers/storage/volumes/data/_data: operation not supported

Initially I thought that Davide’s comment was the reason as I was trying to use NFS. But then I got the same with a CIFS mount. So to me it sounds like SELinux is now getting in the way, so I just disabled SELinux for testing. Strangely making it permissive still forced an error, not just a warning.

Digging around I found quite a few comments regarding NFS mounts and Podman that state that the later versions do support NFS on rootless containers (forgive me if I get some of the terminology wrong, I’m still need things ELIF). But could I get this to work: NO. But I did get some strange issues along the journey, like the mounted DATA path being accessible and writable, but parts of the application directory tree containing the execution binaries being empty.

After giving up on NFS, it was CIFS turn. With this I got closer to it working, but again just slightly out of reach. The closest I got came down to the ownership of the DATA location. Even with this:

runagent -m backuppc1 podman volume create --opt=device=/mnt/backupdata/ --opt=type=bind --opt=o=uid=1000,gid=1000  data

The directory still ended up being owned by root, which meant the application couldn’t write to it.

In the end, as desperation set in, I tried iSCSI, which turned out to be a relatively smooth process, with success.

So, for anyone else struggling with this in the future, there’s my solution for the search engine to find.

Cheers.

2 Likes