network shared storage

D

dirtydevver

New Member
Sep 13, 2024
9
0
1
so ive been using PVE for a few months and decided to take the plunge and get proxmox backup server installed as everyone has been telling me how amazing it is.

after installation it looks very familiar to PVE, however, i noticed there is no option in the GUI to add network shared storage, i have a qnap nas and a truenas so would like to get at least one of these connected, maybe even both?

ive seen a few videos online with mixed results and was wondering if there is an official, or very reliable way to mount these to proxmox backup server.

im also using a windows domain so not sure if that adds complexity to the solution?
 
Hello!

Depending on what type of shared storage you are using, you mount the storage like you would in Debian.


NFS:
oguz

Post in thread 'Adding NFS Share as Datastore in Proxmox Backup Server'

hi,

you can simply mount your NFS share (with mount command or by adding to /etc/fstab). afterwards create a datastore on the mountpoint (via GUI, or with proxmox-backup-manager datastore create mystore /path/to/my/nfs)
  • Like

SMB:
A

[SOLVED] Post in thread 'PBS - Mounting Windows SMB Share as Datastore'

shurik said:
Hello Aarolain

I'am rather new to Proxmox / PBS / Linux. Ever worked with Hyper-V , unfortunately there is no free Version of Hyper-V anymore.
Could you please post here the steps, needed to mount SMB in PBS to datastore?
I just would like to copy backup of the VMs to a NAS (so copy of backup)
PBS natively allows only backupsync to "remote" PBS, which could be pointed to local PBS... but no possibility like in PVE to make/mount SMB Datastore.

thanks for your help...
Click to expand...

I'm not sure how much you know about PBS/Proxmox/Debian/Linux currently, but I'll do my best briefly explain what...
  • Like



After it has been mounted, you can add the storage within the GUI as a directory or with
Code: 
proxmox-backup-manager datastore create mystore /path/to/my/nfs
 
Last edited:
ok thanks, im currently using SMB and i think i did see that post, but when i saw storing passwords in files i wasnt sure if that was a hacky way to do things or just the norm. ive also got things setup with a windows domain, doesthis mean id need to create some local accounts to stick into the creds file, or is there a way to pass that through from Active Directory?
 
There is a reason, why this is not in the GUI: It's not recommended by the developers, see https://pbs.proxmox.com/docs/installation.html#recommended-server-system-requirements

They recommend local storage, preffered Enterprise SSDs or (as a compromise) a zfS pool with HDD mirrors for bulk data and an enterprise ssd mirror as special device for small files and metadata.

The reason is that PBS split it's data in a lot of small files ("chunks") to do it's deduplication magic: Data is saved only one time, if another backup is done and the chunk is already present the backup won't need to take more space, instead references to the already saved data. This benefit comes with a price though: For most tasks every chunk needs to be read (e.G. for garbage collection, verify etc) which won't perform well on a HDD and even worse on a network share like NFS or CIFS.

Some guy tried to recreate the PBS setup of a lot of small files with a benchmark script. Although the Proxmox developers had quite some good points how some of his assumptions are actually not true they agreed with his main result: Network shares don't work well with PBS, see his results here:
D

[TUTORIAL] Thread 'Datastore Performance Tester for PBS'

This is a performance tester for datastores of your PBS.

-> Intended before you setup a production PBS. <-

Bash: 
apt-get update
apt-get install git
git clone https://github.com/egandro/pbs-storage-perf-test.git
cd pbs-storage-perf-test
# replace datastore-dir with your own directory
./create_random_chunks.py /datastore-dir
rm -rf /datastore-dir/dummy-chunks

- Read how/what/and why we test in this way: https://github.com/egandro/pbs-storage-perf-test/blob/main/README.md
- Our results: https://github.com/egandro/pbs-storage-perf-test/blob/main/results.md
- Our conclusion...
  • Like

Since his tests were done on a localhost (so a network share on the same machine) the bad results can't be explained with network issues it's just that NFS or CIFS are really not suited for PBS.

The reason videos for such subpar setups exist (my "favourite" even explain how to do this over Internet to some cloud storage folder like Hetzners storagebox) isn't because it's a good idea (it isn't) but because v-loggers need clicks and ads revenue.

Now since PBS is basically a Debian you can still use network shares via the cli and shell, but instead of doing this I would try whether you might setup a VM with PBS in your qnap or Truenas. As far I know both systems have support for running VMs, so if your hardware has enough power this is the way to go.
I remember some guy here in the German forum, who first tried with CIFS or nfs, than switched to a VM on his nas. Allthough his datastore was on a hdd mirror (so not a recommended setup!) the results were quite impressive:
J

Post in thread 'Warum ist der PBS so "picky" bei NFS-Storage-Mounts?'

Johannes S said:
Naja, wenn die auf HDDs liegen, wird das vor allen daran liegen. Hat man ZFS, lässt sich das mit einen sogenannten special device beschleunigen (da die Metadaten dann dort gespeichert werden und Garbage Collection vor allen mit den Metadaten arbeitet), da muss man aber beachten, dass man mindestens zwei SSDs im Mirror hat, da bei einen Ausfall des special devices auch alle Daten auf den HDDs weg sind
Click to expand...
Dafür habe ich bei der Synology den oben beschriebenen BTRFS-Metadaten-Cache auf zwei 1TB-NVMe-SSD (als RAID-1) im Gerät. Das ist quasi das "Special Device" in dem Fall. Bei Verwendung...

The verify via CIFS took 5 h, 30 min, the garbage collection job around 8-9 minutes. As a vm on the NAS verify took 3h, 40 min, garbage collection around one to two minutes.

In my book these numbers speak for themselves, so I wouldn't bother with network shares, it's really not worth the trouble.
 
Last edited:
  • Like
Reactions: dirtydevver, carles89 and Weehooey-HSS
Johannes S said:
There is a reason, why this is not in the GUI: It's not recommended by the developers, see https://pbs.proxmox.com/docs/installation.html#recommended-server-system-requirements

They recommend local storage, preffered Enterprise SSDs or (as a compromise) a zfS pool with HDD mirrors for bulk data and an enterprise ssd mirror as special device for small files and metadata.

The reason is that PBS split it's data in a lot of small files ("chunks") to do it's deduplication magic: Data is saved only one time, if another backup is done and the chunk is already present the backup won't need to take more space, instead references to the already saved data. This benefit comes with a price though: For most tasks every chunk needs to be read (e.G. for garbage collection, verify etc) which won't perform well on a HDD and even worse on a network share like NFS or CIFS.

Some guy tried to recreate the PBS setup of a lot of small files with a benchmark script. Although the Proxmox developers had quite some good points how some of his assumptions are actually not true they agreed with his main result: Network shares don't work well with PBS, see his results here:
D

[TUTORIAL] Thread 'Datastore Performance Tester for PBS'

This is a performance tester for datastores of your PBS.

-> Intended before you setup a production PBS. <-

Bash: 
apt-get update
apt-get install git
git clone https://github.com/egandro/pbs-storage-perf-test.git
cd pbs-storage-perf-test
# replace datastore-dir with your own directory
./create_random_chunks.py /datastore-dir
rm -rf /datastore-dir/dummy-chunks

- Read how/what/and why we test in this way: https://github.com/egandro/pbs-storage-perf-test/blob/main/README.md
- Our results: https://github.com/egandro/pbs-storage-perf-test/blob/main/results.md
- Our conclusion...
  • Like

Since his tests were done on a localhost (so a network share on the same machine) the bad results can't be explained with network issues it's just that NFS or CIFS are really not suited for PBS.

The reason videos for such subpar setups exist (my "favourite" even explain how to do this over Internet to some cloud storage folder like Hetzners storagebox) isn't because it's a good idea (it isn't) but because v-loggers need clicks and ads revenue.

Now since PBS is basically a Debian you can still use network shares via the cli and shell, but instead of doing this I would try whether you might setup a VM with PBS in your qnap or Truenas. As far I know both systems have support for running VMs, so if your hardware has enough power this is the way to go.
I remember some guy here in the German forum, who first tried with CIFS or nfs, than switched to a VM on his nas. Allthough his datastore was on a hdd mirror (so not a recommended setup!) the results were quite impressive:
J

Post in thread 'Warum ist der PBS so "picky" bei NFS-Storage-Mounts?'

Johannes S said:
Naja, wenn die auf HDDs liegen, wird das vor allen daran liegen. Hat man ZFS, lässt sich das mit einen sogenannten special device beschleunigen (da die Metadaten dann dort gespeichert werden und Garbage Collection vor allen mit den Metadaten arbeitet), da muss man aber beachten, dass man mindestens zwei SSDs im Mirror hat, da bei einen Ausfall des special devices auch alle Daten auf den HDDs weg sind
Click to expand...
Dafür habe ich bei der Synology den oben beschriebenen BTRFS-Metadaten-Cache auf zwei 1TB-NVMe-SSD (als RAID-1) im Gerät. Das ist quasi das "Special Device" in dem Fall. Bei Verwendung...

The verify via CIFS took 5 h, 30 min, the garbage collection job around 8-9 minutes. As a vm on the NAS verify took 3h, 40 min, garbage collection around one to two minutes.

In my book these numbers speak for themselves, so I wouldn't bother with network shares, it's really not worth the trouble.
Click to expand...


thanks for the info thats really useful, i previously used veeam to backup my vm's and thought PBS was going to be a suitable replacement as veeam would only take a few minutes per VM.
 
You must log in or register to reply here.
Top Bottom