VPS als externes Backup-Ziel nutzen

Was ein externes Backup-Ziel tatsächlich ist

Ein externes Backup-Ziel ist eine zweite Maschine, die eine Kopie Ihrer Daten enthält und unabhängig vom Original ausfallen kann. Ein VPS bei einem anderen Anbieter ist für die meisten Leser die günstigste verfügbare Option. Drei Varianten sind realistisch: Proxmox Backup Server auf dem VPS, ein über SSH oder S3 erreichbares restic-Repository oder ein rsync-Spiegel, den der Backup-Host abruft. Welche Variante geeignet ist, hängt davon ab, was Sie wiederherstellen und wie schnell es wieder verfügbar sein muss. Wer die Kopie löschen darf, entscheidet über den Rest.

Extern bedeutet eine andere Ausfalldomäne. Das heißt: ein anderer Anbieter und ein Konto, das keine Anmeldedaten mit dem Konto für Ihren Server teilt. Ein zweiter Server in einer anderen Region desselben Anbieters übersteht einen Brand in einem Gebäude. Einen kompromittierten Zugang zum Control Panel übersteht er nicht, weil ein Konto beide Kopien kontrolliert.

Ein Snapshot bei Ihrem Anbieter ist keine solche zweite Kopie. Er befindet sich hinter demselben Passwort für das Control Panel. Wer dieses Passwort erhält, kann den Server und seine Snapshots in einer Sitzung löschen. Snapshot-Dienste berechnen außerdem pro Gigabyte und Monat deutlich höhere Preise als gewöhnlicher Speicherplatz. Dadurch werden neunzig Tage Aufbewahrung teuer. Der Unterschied zwischen VPS-Snapshots und Backups ist lesenswert, bevor Sie sich auf eine der beiden Varianten verlassen.

Welche der drei Varianten passt zu Ihnen

• Proxmox Backup Server (PBS): Die Quelle ist Proxmox VE (virtuelle Umgebung), und Sie stellen eine vollständige virtuelle Maschine wieder her. Die Sicherung erfolgt auf Ebene der Disk-Images. Bei den Verify-Jobs werden die auf dem Ziel gespeicherten Daten erneut gelesen.
• Ein restic-Repository: Die Quelle ist ein oder mehrere Linux-Hosts, und Sie stellen ein Verzeichnis oder einen Datenbank-Dump wieder her. Die Verschlüsselung erfolgt auf dem Client. restic unterstützt SSH und S3 sowie sein eigenes REST-Protokoll.
• rsync über SSH, abgerufen vom Backup-Host: Sie möchten die Dateien auf dem Ziel als normale Dateien vorliegen haben. Sie sollen mit ls und cat lesbar sein. Für die Wiederherstellung soll keine Client-Software erforderlich sein.

Wenn Sie sich nicht entscheiden können, verwenden Sie restic. Die Verschlüsselung erfolgt, bevor Daten das System verlassen. Auf dem Ziel werden außer einem SSH-Konto und Speicherplatz keine weiteren Komponenten benötigt. restic-Backups auf einem VPS einrichten behandelt die Client-Seite ausführlicher. restic und BorgBackup im Vergleich hilft bei der Auswahl, wenn Sie bereits Borg einsetzen.

Die Zielgröße bestimmen: Was ein Monat Aufbewahrung kostet

Die Deduplizierung ist der Grund dafür, dass die Zahlen niedriger ausfallen als erwartet. restic und PBS teilen Dateien in Chunks variabler Größe auf und hashen jeden Chunk. Jeder eindeutige Chunk wird nur einmal gespeichert. Das zweite Backup eines 500-GB-Datensatzes fügt nicht weitere 500 GB hinzu. Es fügt nur die geänderten Chunks hinzu.

Die Repository-Größe hängt daher vom Alter des ältesten Snapshots ab, nicht von der Anzahl der Snapshots. Nehmen wir 500 GB Daten und täglich 5 GB neue eindeutige Daten an. Das Repository enthält dann die 500 GB Basisdaten plus ungefähr 5 GB für jeden Tag bis zurück zum ältesten Snapshot, den die Richtlinie aufbewahrt.

[
  {
    "label": "7 daily",
    "repo_size_gb": 535,
    "usd_at_10_per_tb": 5.35
  },
  {
    "label": "7 daily, 4 weekly",
    "repo_size_gb": 640,
    "usd_at_10_per_tb": 6.4
  },
  {
    "label": "7 daily, 4 weekly, 6 monthly",
    "repo_size_gb": "1,400",
    "usd_at_10_per_tb": 14.0
  },
  {
    "label": "7 daily, 4 weekly, 12 monthly",
    "repo_size_gb": "2,325",
    "usd_at_10_per_tb": 23.25
  }
]

Die Spalte mit den Dollarbeträgen berechnet die Kosten für dieses Repository mit 10 US-Dollar pro TB und Monat. Sie dient nur als Platzhalter für die Berechnung und ist kein Angebot eines bestimmten Anbieters. Ersetzen Sie den Wert durch den tatsächlichen Preis pro TB für den Tarif, den Sie in Betracht ziehen. Eine Woche täglicher Backups belegt ungefähr 535 GB. Ein vollständiges Jahr Aufbewahrung belegt 2,325 GB. Das entspricht $23.25 pro Monat gegenüber $5.35 für die Woche. Die Aufbewahrung älterer Daten ist günstig. Für die Basiskopie zahlen Sie.

Die Deduplizierung bringt bei Daten, die bereits komprimiert oder verschlüsselt eintreffen, keinen Vorteil. Ein komprimiertes Datenbank-Dump im gzip-Format ändert sich bei jedem Lauf vollständig. Daher wird jeder Dump als neue Chunks gespeichert, und das Repository wächst jede Nacht um die vollständige Größe eines Dumps. Schreiben Sie den Dump unkomprimiert und lassen Sie das Backup-Tool die Komprimierung übernehmen. restic unterstützt komprimierte Repositories seit 0.14. In Version 0.19 wurden die fastest- und better-zstd-Modi hinzugefügt. Foto- und Videobibliotheken lassen sich aus demselben Grund schlecht deduplizieren. Berechnen Sie deren Größe daher anhand ihrer tatsächlichen Wachstumsrate und nicht anhand der Werte in der Tabelle oben.

Sie kaufen hier eher ungenutzten Speicherplatz als CPU-Leistung. Genau in diesem Fall ist ein Storage-VPS einem regulären VPS überlegen.

Warum Bandbreite und Wiederherstellungszeit den Plan bestimmen

Der Speicherplatz ist der günstige Teil. Der erste Upload und die spätere Wiederherstellung sind die teuren Teile. 500 GB entsprechen 4 Billionen Bits. Die Division durch die Übertragungsgeschwindigkeit ergibt daher die Mindestdauer einer vollständigen Wiederherstellung.

[
  {
    "label": "40 Mbit/s home upload",
    "elapsed_h": 27.8
  },
  {
    "label": "100 Mbit/s",
    "elapsed_h": 11.1
  },
  {
    "label": "500 Mbit/s",
    "elapsed_h": 2.2
  },
  {
    "label": "1 Gbit/s VPS port",
    "elapsed_h": 1.1
  }
]

Das sind Werte mit voller Leitungsgeschwindigkeit und ohne Protokoll-Overhead. Betrachten Sie sie daher als Best Case. Bei 100 Mbit/s benötigt eine vollständige Wiederherstellung 11.1 Stunden, bevor jemand auf die Daten zugreifen kann. Bei einem Upload von 40 Mbit/s aus einem Privathaushalt sind es 27.8 Stunden. An einem Port mit 1 Gbit/s dauert dieselbe Wiederherstellung 1.1 Stunden. Viele kleine Dateien werden langsamer übertragen als rechnerisch ermittelt, weil der Overhead pro Datei dominiert, sobald die Dateien kleiner als einige hundert Kilobyte sind.

Daraus folgen zwei Punkte. Wenn Ihr Recovery Time Objective (RTO), also der tolerierbare Ausfall, vier Stunden beträgt, wird dieses Ziel bei einer Wiederherstellung von 500 GB über eine Verbindung mit 100 Mbit/s bereits verfehlt. Günstiger Speicherplatz hilft dann nicht. Außerdem rechnen die meisten VPS-Tarife den ausgehenden Datenverkehr ab. Eine vollständige Wiederherstellung verbraucht daher 0,5 TB des monatlichen Kontingents des Backup-Hosts. Prüfen Sie dieses Kontingent und klären Sie, was der Anbieter beim Überschreiten berechnet oder unternimmt, bevor Sie die Daten benötigen.

Das erste Backup umfasst den gesamten Datenbestand und ist der langsamste Lauf, den Sie jemals durchführen werden. Starten Sie es an einem Freitag und begrenzen Sie die Übertragungsrate, damit der Uplink der Quelle nicht ausgelastet wird: Bei restic wird die Rate in --limit-upload KiB pro Sekunde angegeben, bei rsync in --bwlimit.

Form 1: Proxmox Backup Server als Remote-Datastore

PBS eignet sich, wenn die Quelle Proxmox VE ist und eine virtuelle Maschine wiederhergestellt wird. Ein VPS kann nicht von der Proxmox-ISO booten. Installieren Sie PBS daher auf Debian. Version 4.2 ist im August 2026 aktuell und basiert auf Debian 13 (trixie).

wget https://enterprise.proxmox.com/debian/proxmox-archive-keyring-trixie.gpg \
  -O /usr/share/keyrings/proxmox-archive-keyring.gpg
sha256sum /usr/share/keyrings/proxmox-archive-keyring.gpg

Vergleichen Sie diese Prüfsumme mit dem Wert auf der Seite der Proxmox-Paketrepositorys. Ein apt-Repository ist nur so vertrauenswürdig wie der Schlüssel, den Sie verifiziert haben. Schreiben Sie anschließend /etc/apt/sources.list.d/proxmox.sources:

Types: deb
URIs: http://download.proxmox.com/debian/pbs
Suites: trixie
Components: pbs-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

sudo apt update && sudo apt install -y proxmox-backup-server
sudo proxmox-backup-manager datastore create offsite /mnt/datastore/offsite

Geben Sie dem Datastore ein eigenes Dateisystem oder ein eigenes Volume. Ein vollständig belegter Datastore stoppt Backups. Wenn der Datastore das Root-Dateisystem gemeinsam nutzt, fällt bei dessen Überlauf der gesamte Server aus.

Erstellen Sie anschließend das Konto, das die Quelle verwenden wird, und geben Sie ihm statt eines Passworts ein Token.

sudo proxmox-backup-manager user create backup@pbs
sudo proxmox-backup-manager user generate-token backup@pbs pve1
sudo proxmox-backup-manager acl update /datastore/offsite DatastoreBackup \
  --auth-id 'backup@pbs!pve1'

Das Token-Geheimnis wird nur einmal ausgegeben und kann später nicht erneut ausgelesen werden. Speichern Sie es daher, sobald es angezeigt wird. Die Rolle ist ebenso wichtig wie das Token. DatastoreBackup kann eigene Backups erstellen und wiederherstellen. Das Privileg Datastore.Prune ist darin nicht enthalten. Dieses Token kann daher keinen Snapshot löschen, den es selbst geschrieben hat.

Die Aufbewahrung auf PBS besteht aus zwei Teilen. Der zweite Teil wird häufig übersprungen. Prune entfernt Snapshots. Die Garbage Collection entfernt die Chunks, auf die kein verbleibender Snapshot mehr verweist. Freier Speicher wird durch die Garbage Collection verfügbar, nicht durch Prune.

proxmox-backup-client prune host/web1 \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --dry-run
sudo proxmox-backup-manager garbage-collection start offsite
sudo proxmox-backup-manager verify offsite

Entfernen Sie --dry-run, sobald die Liste der zu entfernenden Snapshots korrekt aussieht. Die Garbage Collection läuft in zwei Phasen: Zuerst aktualisiert sie die Zugriffszeit jedes weiterhin referenzierten Chunks. Danach löscht sie Chunks, deren Zugriffszeit älter als der Stichtag ist. Dieser liegt 24 Stunden und 5 Minuten vor dem Start des Vorgangs. Diese Karenzzeit verhindert, dass ein Chunk, in den gerade ein laufendes Backup schreibt, währenddessen gelöscht wird. Planen Sie Prune täglich und die Garbage Collection wöchentlich für den Datastore ein. Fügen Sie außerdem einen Verify-Job hinzu. Dadurch liest das Ziel seine eigenen Chunks erneut und meldet eine Beschädigung auf dem Datenträger, bevor eine Wiederherstellung daran scheitert.

Wenn die Quelle selbst eine PBS-Instanz ist, kann der Offsite-Server die Daten abrufen, statt sie dorthin übertragen zu bekommen.

sudo proxmox-backup-manager remote create home1 \
  --host pbs.home.example --userid sync@pam --password 'SECRET' \
  --fingerprint '64:d3:ff:3a:50:38:53:5a:9b:f7:50:ab:fe'
sudo proxmox-backup-manager sync-job create home1-offsite \
  --remote home1 --remote-store main --store offsite --schedule 'Wed 02:30'

Führen Sie diesen Sync-Job auf dem VPS in der standardmäßigen Pull-Richtung aus. Der VPS greift auf den Datastore zu Hause zu. Dadurch besitzt der Heimserver keine Zugangsdaten, mit denen sich die Offsite-Kopie verändern lässt.

Form 2: ein restic-Repository über SSH oder S3

Debian und Ubuntu enthalten beide restic in ihren Paketquellen, liegen aber hinter dem Upstream-Projekt zurück. Stand August 2026 ist Version 0.19.1 aktuell. Installieren Sie die offizielle Binärdatei auf dem Quellhost.

curl -LO https://github.com/restic/restic/releases/download/v0.19.1/restic_0.19.1_linux_amd64.bz2
bunzip2 restic_0.19.1_linux_amd64.bz2
sudo install -m 755 restic_0.19.1_linux_amd64 /usr/local/bin/restic
restic version

restic version gibt die Version und den Go-Compiler aus, mit dem die Binärdatei erstellt wurde. Spätere Aktualisierungen erfolgen mit sudo restic self-update. Das funktioniert mit offiziellen Binärdateien, nicht jedoch mit einer aus apt installierten Kopie.

Legen Sie auf dem Backup-VPS ein Konto an, das keine anderen Dateien besitzt. Kopieren Sie anschließend den öffentlichen Schlüssel des Quellhosts nach /home/resticsrv/.ssh/authorized_keys.

sudo adduser --disabled-password --gecos '' resticsrv
sudo install -d -m 700 -o resticsrv -g resticsrv /srv/restic

Initialisieren Sie das Repository vom Quellhost aus über SFTP.

sudo sh -c 'umask 077; head -c 32 /dev/urandom | base64 > /root/.restic-password'
export RESTIC_REPOSITORY='sftp:resticsrv@backup.example.net:/srv/restic/web1'
export RESTIC_PASSWORD_FILE=/root/.restic-password
restic init
restic backup /etc /srv /var/backups --exclude-caches

Speichern Sie dieses Passwort an einem Ort, der weder dieser Server noch das Backup-Ziel ist. Wenn Sie es verlieren, ist das Repository nicht lesbar. Es gibt keinen Wiederherstellungsweg. Das ist die Konsequenz der clientseitigen Verschlüsselung.

Die Aufbewahrung wird mit einem Befehl festgelegt. Der zweite Teil dieses Befehls gibt den Speicherplatz frei.

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check --read-data-subset=10%

forget löscht Snapshots. prune löscht die Pack-Dateien, auf die nur diese Snapshots verwiesen haben, und --prune führt diesen Schritt automatisch aus, wenn tatsächlich etwas gelöscht wurde. Ohne diesen Schritt wird das Repository nie kleiner. restic check überprüft die Repository-Struktur. --read-data-subset=10% liest ein Zehntel der Pack-Dateien erneut ein und berechnet deren Hashes erneut. Dadurch wird eine Beschädigung auf dem Ziel erkannt, ohne alle Dateien lesen zu müssen. Die andere Form, --read-data-subset=1/10, überprüft immer dasselbe Zehntel. Wenn Sie die erste Zahl jede Woche erhöhen, wird das gesamte Repository innerhalb von zehn Wochen geprüft.

Wenn ein Lauf beendet wird, stoppt der nächste Lauf mit repository is already locked exclusively by PID. Stellen Sie sicher, dass kein Backup läuft, und entfernen Sie die Sperre mit restic unlock.

Für Object Storage wird der Repository-String zu s3:https://s3.example.net/web1. Die Zugangsdaten stehen in AWS_ACCESS_KEY_ID und AWS_SECRET_ACCESS_KEY. Alles andere bleibt identisch. So kommuniziert restic mit einem selbst gehosteten MinIO-Objektspeicher, der auf demselben VPS läuft.

Form 3: rsync über SSH mit einem Schlüssel nur für Pull-Zugriffe

Die Sicherheitseigenschaft dieser Form ist die Richtung. Der Backup-VPS verbindet sich mit der Quelle und liest Daten. Auf der Quelle befindet sich kein Schlüssel, und es gibt von dort keine Route zum Backup-Host. Eine Kompromittierung der Quelle kann die Backups daher überhaupt nicht erreichen.

Generieren Sie auf dem Backup-VPS ein Schlüsselpaar. Installieren Sie anschließend den öffentlichen Schlüssel mit einem erzwungenen Befehl auf der Quelle.

command="rrsync -ro /srv",restrict ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA offsite-pull

rrsync ist unter Debian 13 und Ubuntu 24.04 im rsync-Paket unter /usr/bin/rrsync enthalten. -ro erlaubt ausschließlich das Lesen und schließt -no-del ein. Dieser Schlüssel kann daher weder auf die Quelle schreiben noch dort etwas löschen. restrict deaktiviert die hier nicht benötigten SSH-Funktionen, einschließlich Portweiterleitung und pty. Der Schlüssel kann daher nicht für eine interaktive Anmeldung verwendet werden. Pfade sind anschließend relativ zu dem von Ihnen angegebenen Verzeichnis. Der entfernte Pfad / bezeichnet daher /srv auf der Quelle.

Der Pull-Vorgang erhält die Historie mit Hardlinks. Unveränderte Dateien im neuen Verzeichnisbaum sind Hardlinks auf den vorherigen Baum. Sie benötigen daher nur einen Verzeichniseintrag statt einer zweiten Kopie.

DEST=/srv/mirror/web1
TODAY=$(date +%F)
LAST=$(ls -1d "$DEST"/2* 2>/dev/null | tail -1)
LINK=""
if [ -n "$LAST" ]; then LINK="--link-dest=$LAST"; fi
rsync -aH --numeric-ids $LINK -e 'ssh -i /root/.ssh/pull_ed25519' \
  pull@web1.example.net:/ "$DEST/.$TODAY.partial/"
mv "$DEST/.$TODAY.partial" "$DEST/$TODAY"

Die Umbenennung am Ende macht ein Verzeichnis mit Datumsangabe vertrauenswürdig: Der Name wird erst vergeben, nachdem rsync mit Exit-Code 0 beendet wurde. Eine unterbrochene Übertragung erscheint daher nie als fertiger Snapshot. Löschen Sie alte Bäume mit einer einzigen Zeile und behalten Sie dreißig.

ls -1d /srv/mirror/web1/2* | sort | head -n -30 | xargs -r rm -rf

Berücksichtigen Sie die Kosten dieser Form. Hardlinks deduplizieren nur vollständige Dateien. Wenn sich ein Byte in einem 4-GB-Disk-Image ändert, werden daher alle 4 GB kopiert. restic und PBS würden dagegen nur wenige geänderte Chunks speichern. Außerdem enthält das Ziel Ihre Dateien im Klartext. Jeder Benutzer mit root-Zugriff auf den Backup-VPS kann sie lesen.

Clientseitige Verschlüsselung, damit das Ziel niemals Klartext sieht

Behandeln Sie den Backup-VPS wie eine Maschine, die Sie nicht vollständig kontrollieren. Er wird von einem Provider betrieben. Dieser Provider hat Mitarbeiter und defekte Festplatten, die das Gebäude verlassen.

restic verschlüsselt jeden Chunk auf dem Quellsystem, bevor er ihn überträgt. Das Repository enthält daher Chiffretext sowie Metadaten zu Größen und Zeitpunkten. Bei PBS ist die Verschlüsselung optional. Erstellen Sie einen Schlüssel und übergeben Sie ihn anschließend bei jedem Backup.

proxmox-backup-client key create /root/pbs-encryption.key
proxmox-backup-client backup root.pxar:/ --keyfile /root/pbs-encryption.key
proxmox-backup-client key paperkey --output-format text > qrkey.txt

Drucken Sie den Schlüssel aus und bewahren Sie ihn an einem physischen Ort auf. Die Proxmox-Dokumentation formuliert die Konsequenzen eindeutig: Ohne diesen Schlüssel sind die gesicherten Dateien nicht zugänglich. Bewahren Sie den Schlüssel getrennt vom Backup-Ziel auf. Ein Schlüssel neben dem Chiffretext schützt niemanden.

Für rsync-Spiegelungen gibt es keine gleichwertige Funktion. Die Dateien werden als Dateien abgelegt. Wenn die Daten vertraulich sind, müssen Sie entweder akzeptieren, dass das Ziel sie lesen kann, oder eine der beiden anderen Varianten verwenden.

Eine kompromittierte Quelle daran hindern, ihre eigenen Backups zu löschen

Ein Angreifer, der die Quelle übernimmt, sucht als Nächstes nach den Backups. Das Zugangstoken für deren Upload liegt ebenfalls auf diesem Rechner. Wenn dieses Token auch löschen darf, wird der Angreifer es dafür verwenden.

PBS löst dieses Problem mit Rollen. Ein Token, das nur DatastoreBackup besitzt, kann neue Snapshots schreiben und eigene Snapshots wiederherstellen. Es kann keine Snapshots bereinigen, weil dafür das separate Privileg Datastore.Prune erforderlich ist. Führen Sie die Aufbewahrungsrichtlinien auf der PBS-Seite aus. Die Quelle besitzt dann kein Zugangstoken, mit dem sich Daten löschen lassen.

Bei restic über SFTP gibt es diese Trennung nicht. Der SSH-Key, der in das Repository schreiben darf, kann daraus auch Daten löschen. Die Lösung ist das REST-Backend. Starten Sie rest-server auf dem Backup-VPS mit --append-only. Dadurch lassen sich neue Backups erstellen, bestehende Backups jedoch weder löschen noch ändern. Konfigurieren Sie den Client mit rest:https://backup.example.net:8000/web1 und RESTIC_REST_USERNAME auf RESTIC_REST_PASSWORD. Ein restic forget --prune von der Quelle schlägt dann fehl. Das ist das gewünschte Verhalten. Die Aufbewahrung wird deshalb von einem zweiten Rechner mit einem eigenen Zugangstoken ausgeführt. Das restic-Handbuch empfiehlt für Append-Only-Repositories außerdem --keep-within anstelle von richtlinienbasierten Zählwerten. Ein Angreifer könnte das Repository andernfalls mit nutzlosen Snapshots füllen und Ihre echten Snapshots aus einem --keep-last-Zeitraum verdrängen.

rsync löst dasselbe Problem strukturell durch das Abrufen der Daten. Die Quelle besitzt dabei kein Zugangstoken für das Ziel.

Für alle drei Varianten gilt dieselbe Regel: Das Zugangstoken, mit dem sich Backups löschen lassen, liegt auf einem Rechner, der nicht gesichert wird.

Wiederherstellung regelmäßig testen

Ein Backup, das Sie noch nie wiederhergestellt haben, ist nur eine Annahme. Planen Sie vierteljährlich eine Stunde ein und testen Sie es.

restic snapshots
restic restore latest --target /var/tmp/restore-test --include /etc/nginx
diff -r /etc/nginx /var/tmp/restore-test/etc/nginx

diff -r ohne Ausgabe bedeutet, dass der wiederhergestellte Verzeichnisbaum dem aktiven entspricht. Auf PBS lautet derselbe Test proxmox-backup-client restore host/web1/2026-08-13T02:30:00Z root.pxar /var/tmp/restore-test/. Zusätzlich sollte ein geplanter Verify-Job die Chunks auf dem Ziel erneut einlesen und Prüfsummenfehler melden.

Der Test muss mehr nachweisen als nur die Unversehrtheit der Daten.

• Stellen Sie die Daten auf einem dritten Rechner wieder her, nicht auf dem Quellsystem. Genau dessen Ausfall setzen Sie voraus. Das Repository-Passwort oder der PBS-Schlüssel muss daher ohne dieses System erreichbar sein.
• Messen Sie die Dauer der Wiederherstellung und notieren Sie den Wert. Vergleichen Sie ihn anschließend mit dem angegebenen RTO. Das Diagramm oben zeigt die minimale Übertragungsdauer. Die tatsächliche Zeit umfasst außerdem das Entschlüsseln und Schreiben auf die Festplatte sowie die Zeit, die Sie benötigen, um den gewünschten Snapshot zu ermitteln.
• Stellen Sie Daten mit Zustand wieder her, beispielsweise einen Datenbank-Dump, den Sie anschließend in eine Scratch-Instanz laden. Eine TAR-Datei, die sich entpacken lässt, beweist nicht, dass die Anwendung startet.

Die günstigste Festplatte der Welt ist wertlos, solange Sie daraus nicht mindestens einmal eine Wiederherstellung durchgeführt haben.

FAQ

Ist ein Snapshot bei meinem VPS-Provider ein Offsite-Backup?

Nein. Ein Provider-Snapshot befindet sich im selben Konto, ist durch denselben Panel-Login geschützt und wird über dieselbe Rechnung abgerechnet wie der Server, von dem er erstellt wurde. Wer diesen Login erhält, kann den Server und alle seine Snapshots in einer Sitzung löschen. Snapshots sind für ein schnelles Rollback vor einem riskanten Upgrade nützlich. Sie befinden sich jedoch nicht an einem zweiten Standort. Eine Offsite-Kopie liegt unter einem anderen Konto, idealerweise bei einem anderen Provider, mit Zugangsdaten, die auf dem Quellsystem nicht vorhanden sind.

Wie viel Speicherplatz benötige ich für Backups, die einen Monat aufbewahrt werden?

Richten Sie die Größe nach dem Alter Ihres ältesten Snapshots und nicht nach der Anzahl der Snapshots. Ein Deduplizierungswerkzeug speichert jeden eindeutigen Chunk nur einmal. Das Repository entspricht daher ungefähr der Größe der Quelle plus den täglich neu hinzukommenden eindeutigen Daten, multipliziert mit der Aufbewahrungsdauer in Tagen. Bei 500 GB Daten, die sich täglich um 5 GB ändern, belegen tägliche Backups über eine Woche etwa 535 GB. Eine vollständige Jahres-Historie belegt 2,325 GB. Planen Sie zusätzlichen Spielraum ein. Ein voller Datenträger verhindert das nächste Backup. Außerdem benötigt restic's prune freien Speicherplatz, um Pack-Dateien neu zu schreiben, bevor Speicherplatz wieder freigegeben werden kann.

Kann ein kompromittierter Server seine eigenen Offsite-Backups löschen?

Ja, sofern Sie dies nicht verhindert haben. Bei einem einfachen SSH- oder SFTP-Repository kann der Schlüssel, der Schreibzugriff gewährt, auch Daten löschen. Geben Sie der Quelle Zugangsdaten, mit denen Daten nicht entfernt werden können: ein PBS API token mit ausschließlich der Rolle DatastoreBackup, der das Privileg Datastore.Prune nicht besitzt, oder restic mit einem rest-server, der mit --append-only gestartet wurde und das Löschen sowie Ändern vorhandener Backups verweigert. Ein Pull-Design geht noch weiter, weil die Quelle dann überhaupt keine Zugangsdaten für den Backup-Host besitzt. Führen Sie die Aufbewahrungsregeln von der Seite aus, die nicht die Quelle ist.

Sollte ich Proxmox Backup Server oder restic auf dem Backup-VPS ausführen?

Wählen Sie das Werkzeug passend zu der Einheit, die Sie wiederherstellen. Wenn die Quelle Proxmox VE ist und Sie eine vollständige virtuelle Maschine wiederherstellen möchten, verwenden Sie PBS. PBS sichert auf Ebene der Disk-Images und stellt eine VM in einem Schritt wieder her. Wenn die Quelle ein Linux-Host ist und Sie Dateien sowie Datenbank-Dumps wiederherstellen möchten, verwenden Sie restic. Dafür wird nur ein SSH-Konto auf dem Ziel benötigt, und die Daten werden vor der Übertragung verschlüsselt. Der Betrieb beider Werkzeuge ist üblich: PBS für den Hypervisor und restic für die Server, die nicht auf ihm laufen.

Wie lange dauert die Wiederherstellung aus einem VPS-Backup?

Teilen Sie die Datenmenge durch die Link-Geschwindigkeit, um die minimale Dauer zu berechnen. Addieren Sie anschließend die Zeit für Entschlüsselung und Schreibvorgänge. 500 GB über eine Verbindung mit 100 Mbit/s entsprechen bei voller Leitungsrate 11.1 Stunden. Über einen Port mit 1 Gbit/s dauert dieselbe Wiederherstellung 1.1 Stunden. Viele kleine Dateien werden aufgrund des Overheads pro Datei langsamer übertragen, als diese Berechnung ergibt. Messen Sie eine echte Wiederherstellung und verwenden Sie diesen Messwert. Nur auf ihn kann sich Ihr Wiederherstellungsplan verlassen.