Some background knowledge around the problem
After a bit of research and trying, I fount out that zfs used the mount points. So my theory was right: Mount points are not static like drive letters in Windows. Instead, Linux assign them in the order of detection during boot. Adding or removing disks can mix the mount points.
sda -> Drive #1
sdb -> Drive #2
sdc -> Drive #3
Now we add a new drive #4. It could be inserted like this:
sda -> Drive #1
sdb -> Drive #4
sdc -> Drive #2
sde -> Drive #3
If we depend on the mount point, we're in trouble now: Our system expect drive #2 in
sdb, but got a completely different one (drive #4). According to the arch wiki, this can even happen during a regular boot, without any changes to the hdds.
What can we do?
Well, using those mount points seems a bad idea. We should use persistent block device naming instead, which are available using udev. It should be available on any modern linux distribution. Persistent block names doesn't use neutral names like
sdb. Instead, it creates some kind of names, which are persistently bound to the drive. They're comparable to drive letters in Windows (yes, keep in mind that drive letters are bound to partitions, where block names identify a drive, but both of them are persistent!).
by-uuid seems most relevant to solve this problem, but there are others, too. You can read a more detailed explanation in the linked wiki page from Arch. It's a general article, that can apply to other distributions, too. For this issue it's important to know, that
uuids are a kind of generated unique id. And we can use
ids as a better readable alternative, cause they're using hdd specific information like manufacturer, model and serial number.
As described here, it was required to export all pools and then re-import them, but with the
-d switch. It tells zpool where to look for devices:
zpool export <poolname>
zpool import -d /dev/disk/by-id <poolname>
zpool status this can be verified: Before the export/import, you should see mount points like
/dev/sda for the devices. This should change to disk ids after those procedure.
Regular volumes (optional)
For me this was not enough: I have an additionally hdd called buffer for stuff like ISO images. No important data, only to relieve my SSD. So this was a classic ext3 volume. This discourages my server to boot, since the exactly same problem happens here: The mount point changed cause of the new disks, which let mounting fail.
I solved this by simply removing this drive. Anyway this was my idea, since the new hdds are big enough and I could save some energy by having less discs. To do so, we have to remove the storage from proxmox using
/etc/pve/storage.cfg file. In my case, the relevant part looks like this:
After removing it, we've to take a look at
/etc/fstab. This file mounts our
/buffer volume, where the root cause occurs:
/dev/sdf /buffer ext3 rw 0 0
As you can see, the mount point
/dev/sdf is present here. If you don't want to reject the disk like I do, simply use a unique mount point here! For example /dev/disk/by-id. It's an example for persistent block device names. They're generated on base of device-dependent data.
by-id for example uses the hardware serial number. So we're even able to device two equal disks. Read more in the first paragraph for background info.
In my case, simply removing this line prevents linux to mount my hdd. If you have more volumes, it's required to repeat those steps for each of them, to be sure not to run into any issues after a reboot.