NAS-Backup auf einen Storage-VPS mit Borg oder restic

So sieht ein NAS-Backup auf einen Storage-VPS aus

Ein NAS auf einen Storage-VPS zu sichern, erfordert auf der Serverseite vier Dinge: einen unprivilegierten Benutzer, einen SSH-Schlüssel, der nur auf ein Repository zugreifen kann, ein Backup-Programm, das Versionen statt eines Spiegels speichert, und einen Zeitplan, der einen Reboot übersteht. Die Einrichtung dauert einen Nachmittag. Der Vorgang, der eine Woche dauern kann, ist die erste vollständige Kopie, weil eine private oder kleine geschäftliche Leitung deutlich langsamer hochlädt als herunterlädt.

Diese Anleitung geht von einer Umgebung aus, wie sie tatsächlich vor Ort anzutreffen ist: ein Synology- oder QNAP-NAS mit einigen Terabytes, hinter einem asymmetrischen VDSL- oder Kabelanschluss, in einem Haushalt oder kleinen Büro, das eine Kopie dieser Daten außerhalb des Gebäudes aufbewahren möchte. Der Vergleich zwischen einem Storage-VPS und dem NAS zu Hause hilft bei der Entscheidung, ob Sie den VPS überhaupt benötigen. Diese Anleitung setzt voraus, dass Sie ihn verwenden möchten, und zeigt die erforderliche Konfiguration.

Zunächst ein Begriff. Ein Repository ist das Verzeichnis auf dem VPS, das Ihr Backup-Programm verwaltet. Es enthält deduplizierte, verschlüsselte Blöcke und keine durchsuchbare Kopie Ihrer Dateien. Sie können es nicht mit einem Dateimanager öffnen. Genau das ist der Zweck: Der VPS speichert Daten, die er nicht lesen kann.

Storage-VPS oder verwaltete Storage-Box

Eine verwaltete Storage-Box, also eine pro Terabyte gebuchte und über SFTP, rsync, SMB oder WebDAV erreichbare Freigabe, ist für viele Leser hier die bekannte Standardlösung. Für ein einfaches rsync-Ziel oder einen Hyper-Backup-Auftrag reicht sie aus. Sie bietet jedoch keine Shell. Die Gegenstelle kann daher nur Daten speichern.

Root-Zugriff auf einem Storage-VPS erweitert die Möglichkeiten der Gegenstelle:

• Die Serverseite des Backup-Programms läuft dort. borg serve liest den Repository-Index auf dem VPS und beantwortet die Frage „Ist dieser Block bereits vorhanden?“ lokal. Dadurch müssen nur neue Blöcke über Ihre Leitung übertragen werden. Über eine einfache SFTP-Einhängung führt dieselbe Abfrage auf einer Verbindung mit 15 bis 30 ms Latenz zu Tausenden kleiner Umläufe. Der Lauf verlangsamt sich dadurch stark, selbst wenn sich nur sehr wenige Daten geändert haben.
• Die Erzwingung des Append-only-Modus erfolgt auf dem Server. Ein kompromittiertes NAS kann sie daher nicht deaktivieren.
• Die Aufbewahrung wird nach einem von Ihnen festgelegten Zeitplan auf der Festplatte und mit der CPU des VPS ausgeführt.
• Auch die Verifizierung läuft dort. Eine wöchentliche Prüfung des Repositorys benötigt daher keine Bandbreite.

Das sagt nichts darüber aus, was ein bestimmter Anbieter erlaubt oder im Preis einschließt. Lesen Sie deshalb die Bedingungen des von Ihnen gemieteten Angebots. Der technische Punkt ist eng gefasst: Eine Shell auf der Gegenstelle verlagert die Repository-Logik dorthin.

Zwei Möglichkeiten, die Daten vom NAS zu übertragen

Der integrierte Auftrag des Herstellers. Synology Hyper Backup und QNAP Hybrid Backup Sync verwenden beide über SSH einen rsync-kompatiblen Server als Ziel. Auf dem VPS müssen Sie außer einem SSH-Konto und der rsync-Binärdatei nichts installieren. Sie planen den Auftrag in der Weboberfläche, und nach einer unterbrochenen Verbindung wird er automatisch fortgesetzt. Das Repository-Format ist herstellerspezifisch. Für die Wiederherstellung benötigen Sie daher das Tool des Herstellers. Für einen Haushalt, der eine externe Kopie ohne Kommandozeile benötigt, ist dies die richtige Lösung.

Borg oder restic, die in ein Repository auf dem VPS schreiben. Damit erhalten Sie Deduplizierung über alle Versionen hinweg, clientseitige Verschlüsselung und eine Aufbewahrungsrichtlinie, die Sie in einem Befehl festlegen. Dafür muss die Software an einem geeigneten Ort ausgeführt werden: im Container Manager auf einem x86-Synology-System, in Container Station auf einem QNAP-System oder auf einem kleinen, dauerhaft eingeschalteten Linux-System, das die Freigaben einbindet. Die Ausführung von einem anderen Computer über SMB funktioniert ebenfalls. Dabei verlieren Sie jedoch Besitz- und ACL-Metadaten (access control list), und der Scan dauert deutlich länger, weil das Lesen von Größe und Änderungszeit jeder Datei nun einen Netzwerkaufruf erfordert. Die Wahl zwischen restic und Borg hängt davon ab, wo die Repository-Logik liegen soll und wie Sie Bereinigungen durchführen möchten. Beide Varianten funktionieren in diesem Fall.

Ein einfaches rsync -a --delete zu einem VPS erstellt einen Spiegel. Löschen Sie am Montag versehentlich einen Ordner, wird er am Dienstag auch aus dem Spiegel gelöscht. Verschlüsselt Ransomware das NAS, werden die verschlüsselten Daten beim nächsten Lauf über die intakten Daten kopiert. Warum eine zweite Kopie nicht automatisch ein Backup ist erläutert diese Fälle. Kurz gesagt benötigen Sie Versionen und einen Append-only-Schlüssel. Genau das richtet der restliche Leitfaden ein.

Set up the backup user on the VPS

These commands are for Ubuntu 24.04 on the VPS. Run them as your normal sudo user.

sudo apt update && sudo apt install -y borgbackup
sudo adduser --disabled-password --gecos "" nasbackup
sudo install -d -m 700 -o nasbackup -g nasbackup /home/nasbackup/.ssh
sudo install -d -m 755 -o root -g root /srv/borg
sudo install -d -m 700 -o nasbackup -g nasbackup /srv/borg/nas1
borg --version

--disabled-password means the account has no password to guess, so the key is the only way in. Note the version that prints. The Borg on the NAS must be the same major version as the Borg on the VPS, because a 1.x client cannot speak to a 2.x borg serve, and that mismatch shows up at the first connection rather than at install time.

On the NAS, as root, generate a key pair used for nothing else:

ssh-keygen -t ed25519 -f /root/.ssh/nas_offsite -N "" -C "nas1 offsite backup"

The empty passphrase is deliberate, because an unattended nightly job cannot type one. That is exactly why the next step matters: the key must be worthless anywhere except this one repository. Put the public key into /home/nasbackup/.ssh/authorized_keys on the VPS as a single line.

command="borg serve --restrict-to-repository /srv/borg/nas1",restrict ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... nas1 offsite backup

Then sudo chown nasbackup:nasbackup /home/nasbackup/.ssh/authorized_keys and sudo chmod 600 on it. command= replaces whatever the client asks to run, so this key cannot get a shell, cannot run rsync, and cannot touch any other path on the server. restrict switches off port forwarding, agent forwarding, X11 and pty allocation in one word (OpenSSH 7.2 and later). --restrict-to-repository is Borg's half of the same idea.

Test it from the NAS:

ssh -i /root/.ssh/nas_offsite nasbackup@vps.example.com

You should see PTY allocation request failed on channel 0, which is restrict doing its job, and then a session that sits there with no prompt, because borg serve is waiting for Borg's protocol on standard input. Press Ctrl-C. A password prompt instead means the key never got installed. Permission denied (publickey). usually means the mode on .ssh or on authorized_keys is too open, and sshd refuses to use a group writable file.

Now create the repository, from the NAS:

export BORG_REPO=ssh://nasbackup@vps.example.com/srv/borg/nas1
export BORG_RSH="ssh -i /root/.ssh/nas_offsite -o ServerAliveInterval=30"
borg init --encryption=keyfile-blake2
borg key export :: /root/nas1-borg-key.txt

keyfile-blake2 keeps the encryption key on the NAS, under /root/.config/borg/keys/, so the VPS holds ciphertext and no key material at all. The cost is real: lose the NAS and the key together and the repository is unreadable forever. Export it the moment you create it and store that export where neither machine can reach it, with the passphrase in a password manager. borg key export --paper produces a version you can print. The other choice, repokey-blake2, stores the encrypted key inside the repository, which is easier to recover and only as strong as your passphrase. Keeping plaintext off a rented disk covers the wider question of what a host can see.

Once borg init and the first backup have worked, go back to the VPS and add --append-only to the forced command in authorized_keys. In append-only mode the server never removes data: a borg delete or borg prune sent through this key reports success to the client while the segments stay on disk, so an attacker who owns the NAS cannot erase your history. The price is that real pruning has to come from somewhere else. Run borg prune from a machine that is not the NAS using a second key without the flag, or delete old archives by hand a few times a year. Either way, borg compact runs in a shell on the VPS to actually free the space.

For restic the restriction is an sshd block rather than a forced command, because restic speaks SFTP:

Match User nasbackup
    ChrootDirectory /srv/restic
    ForceCommand internal-sftp
    AllowTcpForwarding no

ChrootDirectory requires /srv/restic to be owned by root and not writable by anyone else, with the repository in a subdirectory that nasbackup owns. Inside the chroot the path is /nas1, not /srv/restic/nas1, so the repository string is sftp:nasbackup@vps.example.com:/nas1. Check the config before reloading, because a bad Match block locks everyone out: sudo sshd -t && sudo systemctl reload ssh. Restic's append-only mode lives in its REST server (rest-server --append-only), which is the reason to run that instead of SFTP when ransomware on the NAS is the threat you care about.

Das erste Backup und was Sie auslassen sollten

borg create --stats --progress \\
  --compression auto,zstd,3 \\
  --exclude '/volume1/*/@eaDir' \\
  --exclude '/volume1/*/#recycle' \\
  --exclude-caches \\
  ::'nas1-{now:%Y-%m-%d}' /volume1/documents /volume1/photo

auto,zstd,3 weist Borg an, jeden Block zu testen und die Komprimierung zu überspringen, wenn sie keinen Vorteil bringt. Das ist bei den meisten Foto- oder Videosammlungen der Fall. @eaDir enthält die Vorschaubilder und Indexdaten von Synology. #recycle ist der Netzwerk-Papierkorb. Beides lässt sich neu erstellen. Bei einer großen Fotosammlung können allein @eaDir mehrere zehn Gigabyte an Uploads verursachen, die Sie nie benötigt hätten. --exclude-caches überspringt Verzeichnisse, die mit CACHEDIR.TAG gekennzeichnet sind.

Beginnen Sie mit den Daten, deren Verlust Sie am meisten bedauern würden, und nicht mit allem. Sichern Sie zuerst Dokumente und Fotos, die Mediensammlung später. Borg dedupliziert anhand der bereits gespeicherten Daten. Wenn Sie die Liste der eingeschlossenen Verzeichnisse später erweitern, werden daher nur Blöcke hochgeladen, die das Repository noch nicht kennt. Ein schrittweises Vorgehen verursacht keinen zusätzlichen Aufwand.

Wie lange dauert die erste vollständige Kopie?

Führen Sie diese Berechnung vor dem Start durch, da das Ergebnis die Planung ändert. Teilen Sie die Upload-Rate in Megabit pro Sekunde durch 8, um Megabyte pro Sekunde zu erhalten. Rechnen Sie für TCP-, SSH- und Protokoll-Overhead mit etwa 90 Prozent dieses Werts. Teilen Sie anschließend die Datenmenge durch diesen Wert und die Sekunden durch 86,400, um die Dauer in Tagen zu erhalten.

Achten Sie auf die Einheiten. Leitungsraten werden dezimal angegeben, daher entsprechen 2 TB hier 2,000,000 Megabyte. Ein NAS, das 2 TiB Daten meldet, enthält in diesen Einheiten etwa 2.2 TB. Das sind 10 Prozent mehr Upload-Daten als eingeplant.

[
  {
    "label": "VDSL 50/10",
    "mb_per_sec_up": 1.1,
    "mb_per_sec_down": 5.6,
    "full_copy_up": "21 days",
    "full_restore_down": "4.1 days"
  },
  {
    "label": "Cable 250/25",
    "mb_per_sec_up": 2.8,
    "mb_per_sec_down": 28.1,
    "full_copy_up": "8.3 days",
    "full_restore_down": "19.8 hours"
  },
  {
    "label": "VDSL 250/40",
    "mb_per_sec_up": 4.5,
    "mb_per_sec_down": 28.1,
    "full_copy_up": "5.1 days",
    "full_restore_down": "19.8 hours"
  },
  {
    "label": "Fibre 500/100",
    "mb_per_sec_up": 11.2,
    "mb_per_sec_down": 56.2,
    "full_copy_up": "2.1 days",
    "full_restore_down": "9.9 hours"
  }
]

Diese Zeilen wenden die Formel auf 4 typische veröffentlichte Tarifprofile an. Sie sind keine Messung einer realen Leitung. Beim VDSL 50/10, dem üblichen Einstiegstarif, dauert der Upload einer ersten Kopie mit 2 TB 21 days bei voller Rate, Tag und Nacht. Bei Fibre 500/100 dauert dieselbe Kopie 2.1 days. Kabel liegt ungünstig dazwischen: Cable 250/25 bietet 2.8 Megabyte pro Sekunde im Upload. Dafür sind also 8.3 days erforderlich, obwohl dieselbe Leitung das gesamte Repository in 19.8 hours wieder herunterlädt.

Daraus folgen zwei Punkte. Eine Bandbreitenbegrenzung verlängert die Dauer direkt proportional. Die halbe Rate bedeutet daher eine erste Kopie von sechs Wochen auf der langsamsten Leitung. Die Wiederherstellungsrichtung ist bei einer asymmetrischen Verbindung dagegen nie das Problem. Die belastende Richtung ist diejenige, die Sie nur einmal nutzen.

Wenn die erste Kopie nicht in ein für Sie akzeptables Zeitfenster passt, gibt es diese sinnvollen Möglichkeiten:

• Sichern Sie zuerst die kleinen und wichtigen Datensätze. Erweitern Sie die Liste der einzuschließenden Daten dann über mehrere Wochen.
• Führen Sie die erste Kopie über eine schnellere Leitung aus. Kopieren Sie die Daten auf eine USB-Festplatte, bringen Sie diese in ein Büro oder zu einem Freund mit Glasfaseranschluss und führen Sie dort die erste borg create gegen dasselbe Repository aus. Borg erstellt seinen lokalen Cache neu, wenn es das Repository von einem neuen Rechner aus erkennt. Geänderte Pfade führen dazu, dass Dateien erneut gelesen werden. Bereits im Repository vorhandene Blöcke werden jedoch nicht zweimal hochgeladen.
• Lassen Sie den Vorgang einen Monat lang mit begrenzter Rate laufen. Für einen Haushalt ist das eine vertretbare Entscheidung. Benennen Sie ausdrücklich die Daten, die noch nicht geschützt sind, da die Offsite-Kopie erst nach Abschluss des Vorgangs vorhanden ist.
• Prüfen Sie, ob die Mediensammlung überhaupt Offsite gespeichert werden muss. Eine Filmsammlung, die Sie wiederherstellen können, ist nicht mit der einzigen Kopie von Rechnungen aus fünf Jahren gleichzusetzen. Wenn Sie die Filmsammlung auslassen, kann sich die Dauer von sechs Wochen auf zwei Tage verkürzen.

Die Haushaltsverbindung während der Sicherung nutzbar halten

Eine Sicherung, die den Upstream auslastet, lässt die gesamte Verbindung gestört wirken, auch Downloads. Ursache ist das Queuing. Das Modem nimmt Pakete schneller an, als die Leitung sie übertragen kann. Sein Puffer füllt sich mit Sicherungsdaten. Jedes interaktive Paket, jede DNS-Abfrage und jede TCP-Bestätigung wartet dann hinter diesem Puffer. Die Ping-Zeit steigt von etwa 15 ms auf mehrere hundert Millisekunden. Das ist Bufferbloat. Deshalb bricht ein Videoanruf während eines Uploads ab, obwohl dieser nur die „freie“ Kapazität nutzt.

Begrenzen Sie den Auftrag, statt auf einen günstigen Verlauf zu hoffen. Alle drei Tools akzeptieren ein Limit in Kibibyte pro Sekunde:

borg create --upload-ratelimit 900 ...
restic --limit-upload 900 backup ...
rsync --bwlimit=900 ...

900 KiB/s entsprechen ungefähr 7.4 Mbit/s. Bei einem Upstream mit 10 Mbit/s bleiben damit etwa 2.5 Mbit/s frei. Messen Sie das Ergebnis, statt sich auf den eingestellten Wert zu verlassen. Starten Sie die Sicherung und führen Sie anschließend auf einem Laptop ping -c 20 1.1.1.1 aus. Eine Latenz nahe dem Wert im Leerlauf zeigt, dass das Limit passt. Eine Latenz von mehreren hundert Millisekunden bedeutet, dass Sie den Puffer weiterhin füllen. Verringern Sie das Limit dann um ein Drittel und messen Sie erneut. Ein Router mit modernem Queue-Management (fq_codel oder cake, bei einigen Firmware-Versionen als SQM bezeichnet) behebt dieses Problem zuverlässig, weil er eine Überlastung signalisiert, bevor sich der Puffer füllt.

Planen Sie den Auftrag auf einem Linux-Rechner mit einem systemd-Timer:

[Unit]
Description=Nightly offsite backup of the NAS

[Timer]
OnCalendar=*-*-* 01:30:00
RandomizedDelaySec=1800
Persistent=true

[Install]
WantedBy=timers.target

Persistent=true führt einen verpassten Auftrag nach dem Boot aus. Das ist bei einem Rechner wichtig, der nicht rund um die Uhr eingeschaltet ist. RandomizedDelaySec verteilt die Startzeit, damit nicht zwei Rechner in derselben Sekunde auf das Repository zugreifen und um die Sperre konkurrieren. Aktivieren Sie den Timer mit sudo systemctl enable --now nas-offsite.timer. Prüfen Sie anschließend systemctl list-timers nas-offsite.timer. Dieser Befehl gibt den nächsten Lauf und das Ergebnis des letzten Laufs aus. DSM und QTS verwenden kein systemd. Dort ruft der Aufgabenplaner des Herstellers dasselbe Skript auf. Bewahren Sie die Befehle in einem Shell-Skript auf. Dadurch führen beide Pfade denselben Code aus.

Wenn die Verbindung mitten während einer Übertragung abbricht

Sie wird abbrechen. Ein Upload, der mehrere Tage dauert, übersteht Router-Neustarts, Wartungsarbeiten des Internetproviders und erzwungene Neuverbindungen. Die Möglichkeit zur Wiederaufnahme ist daher erforderlich und kein optionales Extra.

Borg schreibt standardmäßig alle 30 Minuten ein Prüfpunktarchiv (--checkpoint-interval 1800). Nach einem abgebrochenen Lauf sehen Sie ein Archiv, dessen Name mit .checkpoint endet. Der nächste borg create liest die Quelldateien erneut ein, lädt aber nur Blöcke hoch, die im Repository noch nicht vorhanden sind. Dadurch verlieren Sie bei einem Abbruch nur die Übertragung der letzten halben Stunde und nicht der letzten drei Tage. Ein abgeschlossener Lauf für dasselbe Archiv ersetzt den Prüfpunkt.

Restic lädt Pack-Dateien und Index-Dateien während des Laufs hoch. Bei einem erneuten Lauf werden daher Daten übersprungen, die bereits übertragen wurden. Wenn ein Absturz Pack-Dateien hinterlässt, auf die kein Index verweist, macht restic repair index diese wieder sichtbar. Sie werden dann wiederverwendet, statt ein zweites Mal hochgeladen zu werden. In Releases vor 0.16 lautet derselbe Befehl restic rebuild-index.

Ein beendeter Client hinterlässt eine Sperre. Der nächste Lauf wird dann mit Failed to create/acquire the lock beendet. Vergewissern Sie sich, dass tatsächlich kein Prozess mehr läuft. Entfernen Sie die Sperre anschließend mit borg break-lock oder restic unlock. Setzen Sie -o ServerAliveInterval=30 in BORG_RSH, damit eine unterbrochene TCP-Sitzung innerhalb einer Minute erkannt wird, statt bis zum Ablauf des Kernel-Timeouts zu hängen.

Aufbewahrung und Verhindern eines unbegrenzt wachsenden Repositorys

borg prune --list --keep-daily=7 --keep-weekly=4 --keep-monthly=12 --keep-yearly=2
borg compact

Borg 1.2 trennt diese beiden Aufgaben. prune entfernt Archiveinträge, und compact gibt Speicherplatz frei, indem es Segmente neu schreibt. Wenn Sie compact überspringen, wird das Repository niemals kleiner, unabhängig davon, wie oft Sie Archive bereinigen. Wenn das Repository Archive aus mehreren Quellen enthält, fügen Sie die von Ihrer Borg-Version unterstützte Option zur Auswahl passender Archive hinzu, weil prune ohne Filter jedes sichtbare Archiv berücksichtigt. Das entsprechende restic-Kommando lautet restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --keep-yearly 2 --prune.

Nach der ersten Kopie werden bei jedem nächtlichen Lauf nur geänderte Blöcke hochgeladen. Das Wachstum hängt daher vollständig von der Art der gespeicherten Daten ab. Eine Dokument- und Fotosammlung ändert sich pro Monat um wenige Gigabyte. Ein Verzeichnis mit Images virtueller Maschinen oder vollständigen Datenbank-Dumps ändert sich dagegen täglich fast vollständig. Bei derselben Aufbewahrungsrichtlinie kostet das dann ein Mehrfaches der Größe der Quelldaten. Führen Sie borg info nach zwei Wochen aus und dimensionieren Sie die VPS anhand dieses Werts, statt zu schätzen. Berücksichtigen Sie dabei die Kosten eines Terabytes als Block-Storage im Vergleich zu Object-Storage, wenn das Repository den gebuchten Tarif überschreitet. Beachten Sie außerdem, dass ein Snapshot der VPS ein anderes Werkzeug als ein Backup ist: Er schützt die Maschine, auf der sich das Repository befindet, nicht das NAS.

Backup überprüfen und daraus wiederherstellen

Ein nicht überprüftes Backup ist nur eine Annahme. Die folgenden Prüfungen verursachen sehr unterschiedlich viel Datenverkehr. Deshalb werden sie nach unterschiedlichen Zeitplänen ausgeführt.

• Wöchentlich auf dem VPS: borg check --repository-only /srv/borg/nas1. Der Befehl prüft die Segmentprüfsummen und den Repository-Index, ohne etwas zu entschlüsseln. Dafür werden weder der Schlüssel noch Bandbreite benötigt. Tragen Sie den Befehl in die Crontab von root auf dem VPS ein.
• Monatlich vom NAS aus: borg check --archives-only. Der Befehl liest die verschlüsselten Archivmetadaten. Dafür wird der Schlüssel benötigt, und die Metadaten werden über Ihre Leitung übertragen. Im Vergleich zu den eigentlichen Daten sind die Metadaten klein.
• Selten: borg check --verify-data entschlüsselt und hasht jeden Block. Dafür muss das gesamte Repository heruntergeladen werden. Bei einer langsamen Leitung dauert das selbst in Übertragungsrichtung mit hoher Geschwindigkeit mehrere Tage.

Restic teilt die Prüfung auf dieselbe Weise auf. restic check prüft die Struktur. restic check --read-data-subset=1/12 liest einmal im Monat ein Zwölftel der Daten. Dadurch wird das gesamte Repository innerhalb eines Jahres überprüft, ohne einen einzigen sehr großen Download auszuführen.

Die Überprüfung bestätigt, dass das Repository intakt ist. Sie bestätigt nicht, dass Sie eine Datei wiederherstellen können. Das ist eine andere Fähigkeit, die unter Zeitdruck ausfallen kann. Führen Sie einmal pro Quartal eine Wiederherstellungsübung durch und notieren Sie, wie lange sie gedauert hat.

borg list
borg extract --dry-run --list ::nas1-2026-09-05 volume1/documents/2026
mkdir -p /tmp/restoretest
cd /tmp/restoretest
borg extract ::nas1-2026-09-05 volume1/documents/2026
diff -r /volume1/documents/2026 /tmp/restoretest/volume1/documents/2026

Pfade innerhalb eines Archivs werden ohne führenden Schrägstrich gespeichert. borg extract schreibt sie relativ zum aktuellen Verzeichnis. Deshalb beginnt die Übung mit cd. Dass diff -r am Ende nichts ausgibt, ist das erwartete Ergebnis. Die Restic-Variante ist restic snapshots, gefolgt von restic restore latest --target /tmp/restoretest --include /volume1/documents/2026. Wenn Ihr Borg-Build FUSE unterstützt, stellt borg mount ::nas1-2026-09-05 /mnt/borg das Archiv als schreibgeschütztes Dateisystem bereit. Das ist der schnellste Weg, eine einzelne Datei wiederherzustellen.

Führen Sie eine Übung von einem Rechner aus, der nicht das NAS ist. An dem Tag, an dem Sie diese Wiederherstellung benötigen, könnte das NAS ausgefallen sein. Ein Laptop mit installiertem Borg, dem exportierten Schlüssel und der Passphrase reicht aus. Dieser Satz ist Ihr Notfallwiederherstellungsplan. Stellen Sie deshalb sicher, dass er tatsächlich zutrifft.

Einordnung in die 3-2-1-Regel

3-2-1 bedeutet: drei Kopien der Daten auf zwei unterschiedlichen Medientypen, davon eine Kopie an einem anderen Standort. Das NAS und das Repository auf dem VPS sind zwei Kopien in zwei Gebäuden. Die Verwendung eines VPS als Ziel für die externe Kopie deckt allgemein den Nutzen dieses Bestandteils ab. Wenn eine Datei nur auf dem NAS vorhanden ist, weil die Telefonfotos importiert und anschließend vom Telefon gelöscht wurden, haben Sie insgesamt nur zwei Kopien. Eine Beschädigung oder Löschung, die niemand bemerkt, bevor sie aus dem Aufbewahrungszeitraum herausfällt, betrifft dann beide Kopien.

RAID zählt nicht als eine der Kopien. Ein gespiegeltes Laufwerkspaar schützt vor dem Ausfall eines Laufwerks. Es schützt nicht vor einem gelöschten Verzeichnis oder einem Brand.

Die kostengünstige dritte Kopie ist eine USB-Festplatte zu Hause, die regelmäßig gewechselt und getrennt vom Stromnetz aufbewahrt wird. Sie ermöglicht außerdem eine schnelle Wiederherstellung. Mehrere Terabyte von einer lokalen Festplatte zu kopieren, dauert einen Nachmittag. Das Herunterladen vom VPS dauert dagegen entsprechend den oben genannten Download-Werten. Auch der Zustand des entfernten Systems ist wichtig. SMART-Daten und relevante Fehler überwachen, für die Benachrichtigungen ausgelöst werden sollten können Sie nur mit root auf dem System prüfen, auf dem sich Ihre letzte Kopie befindet.

FAQ

Wie lange dauert die erste NAS-Sicherung auf einen VPS?

Teilen Sie die Uploadrate in Megabit pro Sekunde durch 8. Rechnen Sie anschließend etwa 90 Prozent des Ergebnisses für den Overhead ein. Teilen Sie dann die Datenmenge in Megabyte durch diesen Wert. Bei 2 TB ergibt das 21 days kontinuierlichen Upload auf VDSL 50/10 und 5.1 days auf VDSL 250/40. Jede Bandbreitenbegrenzung verlängert die Dauer direkt proportional. Ein auf die halbe Leitungsrate begrenzter Job dauert daher doppelt so lange.

Kann ich Borg oder restic auf einem Synology NAS ausführen?

Auf x86-Modellen mit Container Manager können Sie beide Programme in einem Container gegen die freigegebenen Ordner ausführen. ARM-basierte Modelle bieten diese Möglichkeit häufig nicht. Die Installation von Binärdateien außerhalb des Paketsystems führt außerdem beim nächsten DSM-Update oft zu Problemen. Zwei Alternativen funktionieren gut: Richten Sie Hyper Backup auf ein rsync-Ziel auf dem VPS, oder führen Sie Borg auf einem kleinen, dauerhaft eingeschalteten Linux-Rechner aus, der die NAS-Freigaben einbindet. Dabei müssen Sie einen langsameren Scan und den Verlust von Eigentümer-Metadaten akzeptieren.

Ist rsync auf einen VPS für eine NAS-Sicherung ausreichend?

Sie erhalten eine externe Kopie, aber keine Versionshistorie. Eine auf dem NAS gelöschte oder verschlüsselte Datei wird beim nächsten Lauf auch auf dem Spiegel gelöscht oder verschlüsselt. Das bemerken Sie möglicherweise erst Wochen später. Verwenden Sie ein versioniertes Repository, also Borg, restic oder den eigenen versionierten Job des Herstellers. Beschränken Sie den Server-Key auf append-only, damit das NAS bereits gespeicherte Daten nicht löschen kann.

Was passiert, wenn das NAS und sein Verschlüsselungsschlüssel verloren gehen?

Bei der Verschlüsselung mit keyfile ist das Repository ohne die exportierte Schlüsseldatei und die Passphrase nicht lesbar. Bewahren Sie diesen Export daher an einem Ort auf, den keine der beiden Maschinen erreichen kann, beispielsweise in einem Passwortmanager oder als Ausdruck aus borg key export --paper. Bei repokey liegt der verschlüsselte Schlüssel im Repository. Die Passphrase allein stellt ihn wieder her. Testen Sie in beiden Fällen die Wiederherstellung, bevor Sie sie benötigen. Stellen Sie dazu ein Verzeichnis auf einem Laptop wieder her, der noch nie auf das Repository zugegriffen hat.