Storage-VPS einrichten: die erste Stunde nach dem Kauf

Storage-VPS einrichten: was in der ersten Stunde passiert

Ein Storage-VPS einrichten heißt in der ersten Stunde vor allem: die große Platte finden, sie dauerhaft einhängen, Benutzer und Quotas anlegen, und den ersten Job starten, bevor irgendjemand Daten darauf schreibt. Am Ende dieser Stunde steht die Platte per UUID mit nofail in /etc/fstab, jeder Dienst hat sein eigenes Verzeichnis und seinen eigenen Unix-Benutzer, jeder Benutzer hat eine Quota, und ein Cronjob meldet sich, bevor die Platte voll ist. Der erste echte Job ist ein restic-Backup vom Haupt-VPS.

Die Reihenfolge ist nicht beliebig. Wer erst Daten kopiert und dann über Mount-Optionen, Benutzer und Quotas nachdenkt, räumt später Terabytes um. Wer die Platte verschlüsseln will, muss das sogar vor dem Formatieren entscheiden, weil LUKS unter dem Dateisystem liegt und nicht darüber. Was einen Storage-VPS von einem normalen VPS unterscheidet, nämlich viel Platz auf langsameren Platten statt wenig Platz auf NVMe, steht in Storage-VPS oder normaler VPS. Hier geht es um die Stunde nach dem Kauf.

Alle Befehle sind für Ubuntu 24.04 geschrieben und laufen mit sudo. Als Beispiel dient eine Platte mit 4 TB, die am Ende unter /srv/data hängt.

Wo ist die große Platte? lsblk und findmnt zeigen es

Anbieter liefern einen Storage-VPS in zwei Formen aus. Entweder ist die große Platte ein zweites, leeres Blockgerät, das im System hängt und noch kein Dateisystem hat. Oder sie ist schon formatiert und gemountet, manchmal als Systemplatte mit allem in /, manchmal unter einem Pfad wie /mnt/data. Welche Form du hast, sagt dir nicht die Produktseite, sondern lsblk:

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS

Form A, das zweite leere Gerät, sieht so aus:

NAME    SIZE TYPE FSTYPE MOUNTPOINTS
vda      40G disk
├─vda1   39G part ext4   /
└─vda15 106M part vfat   /boot/efi
vdb       4T disk

vdb hat weder FSTYPE noch MOUNTPOINTS. Das ist ein rohes Blockgerät, und der Rest gilt für genau diesen Fall. Ob das Gerät vdb oder sdb heißt, hängt vom Virtualisierer ab. Wichtig ist nur, dass es die Größe des gekauften Speichers hat und leer ist.

Form B, schon gemountet, zeigt bei vdb oder vdb1 ein Dateisystem und einen Mountpoint. Dann prüfst du, wie der Anbieter es eingehängt hat:

findmnt --real -o TARGET,SOURCE,FSTYPE,OPTIONS
grep -v '^#' /etc/fstab

Zwei Dinge sind hier oft schlecht gelöst. Die fstab-Zeile nennt das Gerät als /dev/vdb statt per UUID, und die Optionen sind nur defaults. Beides korrigierst du im Abschnitt zur fstab. Das Formatieren überspringst du, weil mkfs auf einer Platte mit Daten die Daten löscht.

Form C ist eine einzige große Systemplatte: vda hat 4 TB und vda1 ist /. Dann gibt es nichts zu mounten. Du legst die Verzeichnisse direkt unter /srv/data an und überspringst die Abschnitte zu Dateisystem und fstab. Quotas auf der Wurzelpartition sind möglich, aber ein eigenes Thema. Für die erste Stunde reichen das Verzeichnislayout und der df-Alarm.

Welches Dateisystem für mehrere Terabyte: XFS oder ext4?

Beide tragen 4 TB ohne Mühe. Der Unterschied liegt in Details, die auf einer reinen Datenplatte zählen.

XFS ist für große Dateien und viele parallele Schreiber gebaut, bringt Quotas ohne Zusatzpaket mit und wächst im laufenden Betrieb mit xfs_growfs, wenn der Anbieter das Volume später vergrößert. Verkleinern kann es nicht. Auf einem Storage-VPS spielt das keine Rolle, weil niemand die gekaufte Platte kleiner macht.

ext4 ist der Ubuntu-Standard, kann offline schrumpfen und ist jedem Rettungssystem bekannt. Zwei Dinge musst du wissen. Erstens reserviert mkfs.ext4 standardmäßig 5 % der Platte für root. Auf 4 TB sind das 200 GB, die kein Benutzer beschreiben kann, deshalb setzt du das auf einer Datenplatte mit -m 1 auf 1 %. Zweitens brauchen Quotas das Paket quota und einen quotacheck-Lauf.

Die Befehle unten nehmen XFS. Wer ext4 will, tauscht die zwei markierten Zeilen aus. Verzeichnisse und Benutzer sind identisch.

Vor dem Formatieren fällt eine Entscheidung, die sich später nicht mehr ändern lässt: Verschlüsselung. LUKS (Linux Unified Key Setup) liegt zwischen Blockgerät und Dateisystem. Wer erst formatiert, Daten kopiert und dann verschlüsseln will, formatiert noch einmal und kopiert noch einmal. Wie das auf einem Storage-VPS aussieht, und was es beim Reboot ohne Konsole bedeutet, steht in Daten auf dem Storage-VPS verschlüsseln. Wer sich dafür entscheidet, macht diesen Schritt jetzt und setzt unten /dev/mapper/data überall dort ein, wo /dev/vdb steht.

Formatieren, ohne die Systemplatte zu treffen

Für eine reine Datenplatte brauchst du keine Partitionstabelle. Das Dateisystem liegt direkt auf dem Gerät, und ein späteres Vergrößern des Volumes ist dann ein einziger xfs_growfs-Aufruf ohne Partitionsarbeit. Wann eine Partitionstabelle trotzdem sinnvoll ist, und die ext4-Variante mit allen Optionen, erklärt ein Block-Storage-Volume an den VPS anhängen. Hier nur der eine Befehl:

sudo apt update && sudo apt install -y xfsprogs
sudo mkfs.xfs -L storage /dev/vdb

-L storage vergibt ein Label, das lsblk -f später anzeigt. Der Befehl schützt dich vor dem häufigsten Fehler. Trägt /dev/vdb schon ein Dateisystem, bricht mkfs.xfs ab:

mkfs.xfs: /dev/vdb appears to contain an existing filesystem (ext4).
mkfs.xfs: Use the -f option to force overwrite.

Diese Meldung heißt fast immer, dass du das falsche Gerät angegeben hast. Lies lsblk noch einmal, bevor du an -f denkst.

Für ext4 lautet die Zeile sudo mkfs.ext4 -L storage -m 1 /dev/vdb.

Mounten per UUID mit nofail in /etc/fstab

Gerätenamen wie /dev/vdb sind nicht stabil. Hängt der Anbieter ein zweites Volume an oder ändert sich die Reihenfolge der Geräte, heißt die Datenplatte nach dem nächsten Reboot vdc, und eine fstab-Zeile mit /dev/vdb mountet die falsche Platte oder gar keine. Die UUID (Universally Unique Identifier) steht im Dateisystem selbst und wandert mit ihm:

sudo blkid -s UUID -o value /dev/vdb
sudo install -d -m 755 /srv/data

Trage die UUID in /etc/fstab ein, als eine einzige Zeile:

UUID=1b2c3d4e-0000-4000-8000-abcdefabcdef  /srv/data  xfs  noatime,nosuid,nodev,noexec,nofail,x-systemd.device-timeout=15s,uquota  0  0

Jede Option hat einen Grund.

nofail ist die wichtigste. Ohne sie wartet systemd beim Booten 90 Sekunden auf das Gerät und fällt dann in den Notfallmodus. Der VPS ist dann nur noch über die Konsole des Anbieters erreichbar, SSH kommt nie hoch. Mit nofail bootet das System ohne die Platte weiter, und der df-Alarm weiter unten meldet den fehlenden Mount. x-systemd.device-timeout=15s kürzt die Wartezeit auf ein Maß, das bei einem wirklich fehlenden Volume nicht schmerzt.

nosuid, nodev und noexec sind die drei Optionen für eine Datenplatte, die nie Programme ausführen muss. Eine SUID-Datei (set user ID), ein Geräteknoten oder ein Skript, das ein SFTP-Benutzer hochlädt, bleibt damit eine Datei ohne Wirkung. Die Begründung im Detail, und was anders ist, wenn ein Docker-Verzeichnis auf derselben Platte liegt, steht in Mount-Optionen nosuid, nodev und noexec richtig setzen.

noatime spart bei jedem Lesezugriff einen Schreibzugriff auf die Metadaten. Auf einer Backup-Platte, die restic bei jedem check komplett liest, ist das messbar.

uquota schaltet die Benutzer-Quota von XFS ein. Für XFS muss diese Option beim ersten Mount dabei sein. Ein späteres mount -o remount aktiviert sie nicht, du musst aushängen und neu einhängen. Deshalb steht sie jetzt schon in der Zeile, obwohl die Quotas erst weiter unten kommen.

Die beiden Nullen am Ende: XFS wird beim Booten nicht per fsck geprüft. Für ext4 ersetzt du xfs durch ext4, uquota durch usrquota und die letzte 0 durch 2.

Dann prüfen und einhängen:

sudo findmnt --verify
sudo systemctl daemon-reload
sudo mount /srv/data
findmnt /srv/data

findmnt --verify liest die fstab und meldet Tippfehler, bevor sie beim nächsten Reboot zuschlagen. daemon-reload ist nötig, weil systemd aus der fstab Mount-Units erzeugt und eine geänderte Datei sonst erst beim Reboot liest. Die letzte Zeile muss /srv/data mit /dev/vdb, xfs und einer Optionsliste zeigen, in der nosuid,nodev,noexec und usrquota vorkommen.

Schlägt mount so fehl:

mount: /srv/data: wrong fs type, bad option, bad superblock on /dev/vdb, missing codepage or helper program, or other error.

dann passt der Dateisystemtyp in der fstab nicht zum Gerät, meist ext4 in der Zeile bei einer XFS-Platte oder umgekehrt, oder eine Option ist falsch geschrieben. sudo dmesg | tail nennt die genaue Ursache.

Hast du Form B, ersetzt du die Zeile des Anbieters durch diese. Ist der Mountpoint des Anbieters schon in Benutzung, etwa /home, behältst du den Pfad und änderst nur Gerät und Optionen. noexec auf /home verhindert allerdings, dass Dateien dort direkt ausführbar sind, und das entscheidest du bewusst.

Ein Verzeichnis und ein Benutzer pro Verbraucher

Die Regel ist einfach und spart Monate später Ärger: Jeder Dienst, der auf die Platte schreibt, bekommt ein eigenes Verzeichnis unter /srv/data und einen eigenen Unix-Benutzer. Kein Dienst schreibt als root, kein Dienst sieht die Daten eines anderen, und eine Quota pro Benutzer wird damit zur Quota pro Dienst.

Für die erste Stunde sind es drei Verbraucher. restic ist das Ziel für die Backups vom Haupt-VPS. mirror ist ein rsync-Ziel für ein Verzeichnis, das als Kopie vorliegen soll. anna steht für ein Familienmitglied, das per SFTP (SSH File Transfer Protocol) Fotos ablegt und sonst nichts sehen soll. Ein WebDAV-Share, falls du ihn brauchst, bekommt später genauso ein Verzeichnis und einen Benutzer. Der Dienst dahinter ist ein eigenes Thema, das Layout ändert sich nicht.

sudo groupadd sftponly
sudo useradd -M -d /srv/data/restic -s /usr/sbin/nologin -G sftponly restic
sudo useradd -M -d /srv/data/anna -s /usr/sbin/nologin -G sftponly anna
sudo useradd -M -d /srv/data/mirror -s /bin/sh mirror

-M legt kein Home-Verzeichnis an. Das machst du gleich selbst mit den richtigen Rechten. restic und anna bekommen nologin als Shell, weil sie nur SFTP sprechen. mirror braucht /bin/sh, weil sshd den rsync-Serverprozess über die Shell des Benutzers startet. Die Einschränkung für mirror kommt weiter unten über den SSH-Schlüssel.

Das Layout:

sudo install -d -m 755 -o root -g root /srv/data/restic /srv/data/anna
sudo install -d -m 750 -o restic -g restic /srv/data/restic/repo
sudo install -d -m 750 -o anna -g anna /srv/data/anna/files
sudo install -d -m 750 -o mirror -g mirror /srv/data/mirror

Die zwei Ebenen bei restic und anna sind kein Versehen. Ein SFTP-Chroot verlangt, dass das Chroot-Verzeichnis und alle Verzeichnisse darüber root gehören und für niemanden sonst beschreibbar sind. Darum gehört /srv/data/anna root, und erst /srv/data/anna/files gehört Anna. mirror braucht kein Chroot, also gehört ihr Verzeichnis ihr direkt.

SFTP-Chroot für restic und für die Familie

Ein Chroot (change root) zeigt einem Benutzer ein Verzeichnis als Wurzel des Dateisystems. Anna sieht nach dem Login nur / mit einem Ordner files darin. Dass darüber /srv/data mit dem restic-Repository liegt, existiert für sie nicht. Lege die Datei /etc/ssh/sshd_config.d/60-storage.conf an:

AuthorizedKeysFile .ssh/authorized_keys /etc/ssh/authorized_keys/%u

Match Group sftponly
    ChrootDirectory /srv/data/%u
    ForceCommand internal-sftp
    AllowTcpForwarding no
    X11Forwarding no

AuthorizedKeysFile mit zwei Pfaden bedeutet: sshd sucht den Schlüssel zuerst wie gewohnt im Home des Benutzers, dann unter /etc/ssh/authorized_keys/<name>. Die zweite Stelle brauchst du hier, weil die Homes auf der Datenplatte liegen und dort root das oberste Verzeichnis besitzt. Die Schlüssel bleiben so auf der Systemplatte, und ein fehlendes Volume nach dem Reboot nimmt niemandem den Zugang zum Server selbst.

%u wird beim Login durch den Benutzernamen ersetzt, deshalb reicht ein Match-Block für alle Mitglieder der Gruppe. internal-sftp ist der SFTP-Server in sshd selbst. Er braucht im Chroot keine Binärdatei, was mit noexec auf der Platte auch nicht ginge.

Schlüssel hinterlegen, Konfiguration prüfen, sshd neu starten:

sudo install -d -m 755 /etc/ssh/authorized_keys
echo 'ssh-ed25519 AAAA... anna-laptop' | sudo tee /etc/ssh/authorized_keys/anna
echo 'ssh-ed25519 AAAA... haupt-vps-root' | sudo tee /etc/ssh/authorized_keys/restic
sudo chmod 644 /etc/ssh/authorized_keys/*
sudo sshd -t
sudo sshd -T -C user=anna | grep -iE '^(chrootdirectory|forcecommand)'
sudo systemctl restart ssh

sshd -t meldet Syntaxfehler. sshd -T -C user=anna zeigt die Konfiguration, die für genau diesen Benutzer gilt, und die beiden Zeilen müssen erscheinen. Fehlen sie, ist Anna nicht in der Gruppe sftponly, oder die Datei liegt nicht in sshd_config.d. Halte beim Neustart eine zweite SSH-Sitzung offen.

Der Test vom Laptop:

$ sftp anna@storage.example.net
sftp> ls
files
sftp> put urlaub.jpg
Uploading urlaub.jpg to /urlaub.jpg
remote open("/urlaub.jpg"): Permission denied
sftp> cd files
sftp> put urlaub.jpg

Das erste put scheitert, weil / im Chroot root gehört. Das ist gewollt, genau diese Eigentümerschaft verlangt sshd. Sieht der Client stattdessen nur Connection closed und das Login klappt nie, steht der Grund im Log des Servers:

sudo journalctl -u ssh -n 20 | grep chroot

fatal: bad ownership or modes for chroot directory "/srv/data/anna"

Diese Meldung erscheint, wenn /srv/data/anna nicht root gehört oder für Gruppe oder andere beschreibbar ist. sudo chown root:root /srv/data/anna && sudo chmod 755 /srv/data/anna behebt es.

Soll Anna ein Passwort statt eines Schlüssels benutzen? Ubuntu-Images schalten den Passwort-Login global ab. Setze PasswordAuthentication yes in den Match-Block, dann gilt es nur für die Gruppe sftponly, und vergib mit sudo passwd anna ein langes Passwort.

rsync-Ziel mit rrsync absichern

mirror hat eine echte Shell, also könnte der Schlüssel des Haupt-VPS dort alles tun, was die Unix-Rechte erlauben. rrsync (restricted rsync) ist ein Skript aus dem rsync-Paket, das einen SSH-Schlüssel auf rsync-Aufrufe in ein einziges Verzeichnis beschränkt. Seit rsync 3.2.4 gehört es zum Paket, und Ubuntu 24.04 installiert es, Stand September 2026, unter /usr/bin/rrsync:

sudo apt install -y rsync
command -v rrsync
echo 'command="/usr/bin/rrsync /srv/data/mirror",restrict ssh-ed25519 AAAA... haupt-vps-root' | sudo tee /etc/ssh/authorized_keys/mirror
sudo chmod 644 /etc/ssh/authorized_keys/mirror

command= zwingt jede Verbindung mit diesem Schlüssel durch rrsync, das nur rsync-Serverbefehle innerhalb von /srv/data/mirror zulässt. restrict schaltet Port-Forwarding, Agent-Forwarding, X11 und die Terminalzuweisung ab. Vom Haupt-VPS aus ist der Zielpfad dann relativ zu diesem Verzeichnis:

rsync -a --delete /srv/app/ mirror@storage.example.net:app/

/srv/app/ landet in /srv/data/mirror/app/. Ein Aufruf, der etwas anderes versucht, etwa eine Shell oder einen Pfad außerhalb, wird von rrsync abgewiesen, bevor rsync startet.

Quotas pro Benutzer mit xfs_quota

Ohne Quota füllt der erste Dienst, der außer Kontrolle gerät, die Platte für alle. Ein restic-Repository, dessen forget nie läuft, oder ein Familienmitglied mit einem Videoarchiv, und das Backup vom Haupt-VPS scheitert nachts mit No space left on device. Eine Quota (Kontingent) begrenzt, wie viel jeder Benutzer belegen darf, und damit jeder Dienst.

Erst prüfen, dass die Quota aktiv ist:

sudo xfs_quota -x -c state /srv/data

Die Ausgabe muss Accounting: ON und Enforcement: ON zeigen. Steht dort OFF, fehlt uquota in der fstab, oder die Platte wurde vor dem Eintrag gemountet. Dann sudo umount /srv/data && sudo mount /srv/data.

Dann die Grenzen, auf 4 TB zum Beispiel 1,5 TB für Backups, 1 TB für den Spiegel und 500 GB für Anna, mit Luft nach oben:

sudo xfs_quota -x -c 'limit bsoft=1400g bhard=1500g restic' /srv/data
sudo xfs_quota -x -c 'limit bsoft=900g bhard=1000g mirror' /srv/data
sudo xfs_quota -x -c 'limit bsoft=450g bhard=500g anna' /srv/data
sudo xfs_quota -x -c 'report -h' /srv/data

bhard ist die harte Grenze. Dort scheitert ein Schreibvorgang mit Disk quota exceeded. bsoft darf für eine Frist von sieben Tagen überschritten werden, danach wirkt sie wie die harte Grenze. Im report taucht sie vorher als Warnung auf. Ein SFTP-Client zeigt bei erreichter Quota nur ein allgemeines Failure, weil das SFTP-Protokoll keinen eigenen Fehlercode dafür kennt. report -h verrät dann, wer an der Grenze steht.

Die Grenzen liegen in den Metadaten des Dateisystems und überleben Reboots. Für ext4 heißt der Weg sudo apt install -y quota, dann sudo quotacheck -cum /srv/data und sudo quotaon /srv/data. Die Grenze setzt sudo setquota -u anna 450G 500G 0 0 /srv/data, und sudo repquota -s /srv/data ist das Gegenstück zu report -h.

Ein df-Alarm, damit die Platte nie still vollläuft

Quotas verhindern, dass ein Benutzer alles nimmt. Sie verhindern nicht, dass die Summe aller Grenzen die Platte übersteigt, und sie sagen dir nichts, wenn die Platte nach einem Reboot gar nicht gemountet ist. Beides prüft ein kleines Skript alle 30 Minuten. Als Kanal nimmt das Beispiel ntfy, einen Push-Dienst, den ein curl erreicht. Ersetze die URL durch dein eigenes Topic oder durch einen Mailversand, wenn der Server einen hat.

sudo tee /usr/local/bin/check-data-disk >/dev/null <<'EOF'
#!/bin/sh
MOUNT=/srv/data
LIMIT=85
TOPIC=https://ntfy.sh/dein-geheimes-topic

if ! findmnt -rn "$MOUNT" >/dev/null; then
    logger -p user.err -t check-data-disk "$MOUNT ist nicht gemountet"
    curl -s -d "$MOUNT ist nicht gemountet" "$TOPIC" >/dev/null
    exit 1
fi

USED=$(df --output=pcent "$MOUNT" | tail -n 1 | tr -dc '0-9')
if [ "$USED" -ge "$LIMIT" ]; then
    logger -p user.warning -t check-data-disk "$MOUNT ist zu $USED % voll"
    curl -s -d "$MOUNT ist zu $USED % voll" "$TOPIC" >/dev/null
fi
EOF
sudo chmod 755 /usr/local/bin/check-data-disk
echo '*/30 * * * * root /usr/local/bin/check-data-disk' | sudo tee /etc/cron.d/check-data-disk

findmnt -rn "$MOUNT" liefert nichts, wenn /srv/data kein Mountpoint ist, und genau das ist der Fall, den nofail beim Booten durchlässt. Ohne diesen Test würde df /srv/data die Systemplatte messen, der Alarm bliebe stumm, und die Backups liefen auf die kleine Systemplatte. Starte das Skript einmal von Hand mit sudo /usr/local/bin/check-data-disk, und setze für diesen ersten Lauf LIMIT=1, damit du siehst, dass die Nachricht ankommt. journalctl -t check-data-disk zeigt, was es geloggt hat.

Der erste echte Job: restic vom Haupt-VPS

Eine Platte, auf der noch nichts liegt, ist nicht eingerichtet, sondern nur formatiert. Der erste Job zeigt, ob Schlüssel, Chroot, Rechte und Quota zusammenpassen. Die folgenden Befehle laufen auf dem Haupt-VPS, dessen root-Schlüssel oben bei restic hinterlegt ist. Der erste Aufruf per sftp bestätigt den Host-Key des Storage-VPS und zeigt, dass der Chroot greift:

$ sudo sftp restic@storage.example.net
sftp> ls
repo
sftp> exit

Dann das Repository anlegen und den ersten Snapshot schreiben:

sudo apt install -y restic
sudo sh -c 'umask 077; head -c 32 /dev/urandom | base64 > /root/.restic-pass'
sudo restic -r sftp:restic@storage.example.net:/repo -p /root/.restic-pass init
sudo restic -r sftp:restic@storage.example.net:/repo -p /root/.restic-pass backup /etc /srv/app
sudo restic -r sftp:restic@storage.example.net:/repo -p /root/.restic-pass snapshots

Der Pfad /repo ist der Pfad innerhalb des Chroots, auf dem Storage-VPS also /srv/data/restic/repo. snapshots muss genau einen Snapshot listen. Auf dem Storage-VPS siehst du das Ergebnis in der Quota:

sudo xfs_quota -x -c 'report -h' /srv/data
sudo du -sh /srv/data/restic/repo

Die Passwortdatei sicherst du an einem zweiten Ort. Ohne sie ist das Repository nur noch Rauschen, und das Backup war umsonst. Der vollständige Aufbau mit forget, prune, einem systemd-Timer und einer Wiederherstellungsprobe steht in restic-Backups vom VPS. Eine einzelne Kopie auf einem zweiten Server ist ein Backup-Ziel, kein Backup-Konzept. Was noch fehlt, klärt ist ein Storage-VPS ein Backup.

Was deutsche Anbieter anders liefern, und die DSGVO-Frage

Deutsche Anbieter liefern Storage-VPS in beiden Formen aus, mal als eine große Systemplatte, mal als getrenntes Volume, und derselbe Anbieter kann das je nach Produktlinie unterschiedlich halten. Verlass dich nicht auf die Produktseite, sondern auf lsblk im ersten Abschnitt. Welche Anbieter welche Platten, welche Anbindung und welche Rechenzentren bieten, vergleicht Storage-VPS-Anbieter in Deutschland.

Sobald Fotos der Familie oder Daten von Kunden auf der Platte liegen, kommt die Frage nach der Verschlüsselung im Ruhezustand sofort, meist unter dem Stichwort DSGVO (Datenschutz-Grundverordnung). Ob Artikel 32 in deinem Fall Verschlüsselung verlangt und ob du einen Auftragsverarbeitungsvertrag mit dem Anbieter brauchst, kann dieser Text nicht beantworten. Technisch ist die Antwort LUKS unter dem Dateisystem, und diese Entscheidung fällt vor dem mkfs, nicht danach. Das Vorgehen steht in Daten auf dem Storage-VPS verschlüsseln, und was Standort und Rechenzentrum für Datenresidenz und Preis bedeuten, in Storage-VPS in der EU: Datenresidenz und Kosten.

FAQ

Wie erkenne ich, ob die große Platte schon gemountet ist?

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS zeigt jedes Blockgerät. Ein Gerät mit der Größe des gekauften Speichers, aber ohne FSTYPE und ohne MOUNTPOINTS, ist leer und muss formatiert und gemountet werden. Steht dort ein Dateisystem und ein Pfad, hat der Anbieter es schon eingehängt, und grep -v '^#' /etc/fstab zeigt, ob die Zeile per UUID und mit nofail geschrieben ist.

Warum braucht die Datenplatte nofail in der fstab?

Ohne nofail wartet systemd beim Booten 90 Sekunden auf das Gerät und wechselt dann in den Notfallmodus, in dem SSH nicht startet. Ein fehlendes oder umbenanntes Volume macht den VPS dann nur noch über die Konsole des Anbieters erreichbar. Mit nofail bootet der Server ohne die Platte, und ein Skript mit findmnt -rn /srv/data meldet den fehlenden Mount.

XFS oder ext4 für mehrere Terabyte auf dem Storage-VPS?

Beide funktionieren. XFS bringt Quotas ohne Zusatzpaket mit, wächst online mit xfs_growfs und ist für große Dateien gebaut, kann aber nicht verkleinert werden. ext4 ist der Ubuntu-Standard, kann offline schrumpfen und reserviert standardmäßig 5 % für root, was du auf einer Datenplatte mit -m 1 senkst. Für eine reine Datenplatte, die nie kleiner wird, ist XFS die einfachere Wahl.

Warum kann der SFTP-Benutzer nicht in sein Wurzelverzeichnis schreiben?

Weil sshd verlangt, dass das Chroot-Verzeichnis root gehört und für niemanden sonst beschreibbar ist. Gehört es dem Benutzer, bricht sshd das Login ab und loggt bad ownership or modes for chroot directory. Deshalb bekommt der Benutzer ein Unterverzeichnis wie files, das ihm gehört, und schreibt nur dorthin.

Was passiert, wenn ein Benutzer seine Quota erreicht?

Ein Schreibvorgang über die harte Grenze bhard scheitert mit Disk quota exceeded. SFTP-Clients zeigen dafür nur ein allgemeines Failure, weil das Protokoll keinen eigenen Fehlercode kennt. sudo xfs_quota -x -c 'report -h' /srv/data zeigt, wer an der Grenze steht, und limit mit einem höheren Wert hebt sie an, ohne dass etwas neu gemountet werden muss.