Kaltes Archiv: Wie mein NAS-Back-up von Google nach Frankreich umgezogen ist

Es gibt Dienste, die man aus Überzeugung betreibt, und solche, die man aus Trägheit weiterlaufen lässt. Mein Backup gehörte in die zweite Kategorie. Jede Nacht um drei schickte ein rclone-Skript den Inhalt meines NAS verschlüsselt zu Google Drive – eingerichtet vor Jahren, seither nie wieder angefasst. Es funktionierte. Das ist das Tückische daran.

Gestört hat mich das schon länger. Nicht erst seit es die Initiative um den Digital Independence Day gibt, bemühe ich mich, mehr und mehr meiner Daten eben nicht bei US-amerikanischen Diensten zu lagern. Ja, Apple ist da eine Ausnahme, mindestens mal für meine Fotos und Videos. Aber die iCloud-Fotomediathek ist einfach zu praktisch, um sie nicht zu benutzen. Und: Noch ist mein Vertrauen in Apple nicht erschüttert. Dennoch nutze ich inzwischen für alle mir wirklich wichtigen Daten beispielsweise eine lokal betriebene OpenCloud-Instanz statt iCloud. Egal.

Ich habe mich also nach Back-up-Alternativen umgesehen. Herausgekommen ist ein Back-up, das monatlich weniger als 6 Euro kostet, und auf Magnetbändern in französischen Rechenzentren liegt. Gekostet hat mich der ganze Spaß des Umzugs keine halbe Stunde – mal abgesehen vom eigentlichen Datentransfer. Und das, zugegeben, sicherlich auch, weil ich rclone eben schon konfiguriert hatte und jetzt nur noch anpassen musste.

Die sympathischste Lösung ist leider keine

Am Anfang stand Jottacloud. Ein norwegischer Anbieter, eigene Rechenzentren, unbegrenzter Speicher für rund zwölf Dollar im Monat. Dazu eigene Tools und Apps. Das klang erst mal super verlockend!

Beim Lesen der Nutzungsbedingungen (OK, ich habe eine KI prüfen lassen, ob’s da potenzielle Stolpersteine gibt) änderte sich das schon etwas: Konten für Einzelpersonen und Familien sind ausdrücklich nicht für kommerzielle Zwecke vorgesehen – ich habe hier aber durchaus auch geschäftliche Daten. Oberhalb von fünf Terabyte wird außerhalb die Uploadgeschwindigkeit gedrosselt. Und wenn das Abonnement endet (bspw. wegen eines Verstoßes gegen die Nicht-für-kommerzielle-Zwecke-Regel gekündigt wird), werden sämtliche Daten oberhalb von fünf Gigabyte gelöscht.

Der entscheidende Punkt war aber ein anderer, und er hat mit den Bedingungen nichts zu tun. Jottacloud spiegelt. Was lokal verschwindet, verschwindet auch in der Cloud. Was einen davor bewahrt, sind fünf Dateiversionen und ein Papierkorb mit dreißig Tagen. Jottacloud ist damit gar kein perfekter Ort für meine Back-ups, sondern wäre eher ein Ersatz für die iCloud. Diesen habe ich mir ja aber mit meinem NAS gebaut.

Wenn du also keinen Bock mehr auf Daten in der iCloud hast, aber auch keine Lust verspürst, deine eigene Cloud zu betreiben: Schau dir mal Jottacloud an! Macht einen guten Eindruck!

Objektspeicher, kurz erklärt

Damit landet man bei Objektspeicher. Wer bei einem Cloud-Anbieter unter „Storage“ nachsieht, findet dort meistens drei Alternativen nebeneinander, und nur eine davon ist für meinen Zweck wirklich brauchbar.

Block Storage ist eine virtuelle Festplatte, die an eine Serverinstanz angeschlossen wird. Ohne laufenden Server beim Anbieter kommt man gar nicht daran.

File Storage ist eine verwaltete Dateifreigabe, ebenfalls für Instanzen gedacht – und teuer. Bei OVHcloud kostet sie etwa das Achtzigfache der günstigsten Archivklasse. Für drei Terabyte wären das rund 480 Euro im Monat.

Object Storage ist das Richtige: ein Speicher, der über die S3-Schnittstelle angesprochen wird, ohne eigenen Server dahinter, mit Bezahlung nach Volumen. rclone spricht diese Schnittstelle nativ, ebenso Arq (falls ich mal meinen Mac direkt dorthin sichern möchte) und praktisch jedes andere Backup-Werkzeug.

In die engere Wahl kamen zwei europäische Anbieter. Scaleway aus Frankreich mit der Klasse Glacier, OVHcloud ebenfalls aus Frankreich mit Cold Archive.

	Scaleway Glacier	OVHcloud Cold Archive
Preis bei 5 TB	12,70 €	9,90 €
Ausgehender Traffic	75 GB frei, dann 0,01 €/GB	kostenlos
Voller Restore 5 TB	~94 €	~54 € Datenabruf
Mindestspeicherdauer	keine	180 Tage
Speicherort	Paris, Amsterdam, Warschau	Frankreich, vier Rechenzentren

Ausschlaggebend war der kostenlose Traffic in beide Richtungen. Bei einem Backup zahlt man nicht für den Alltag, sondern für den einen Tag, an dem etwas schiefgeht – und an dem will ich keine Rechnung sehen, die mit dem Datenvolumen skaliert.

Der Preis, den ich dafür zahle, steht in der letzten Zeile. Die 180 Tage Mindestspeicherdauer bedeuten: Was ich hochlade und vier Wochen später überschreibe, wird anteilig für die verbleibenden Monate nachberechnet. Bei einem überwiegend statischen Bestand ist das verschmerzbar. Bei Daten, die sich täglich ändern, wäre es das nicht – dazu später mehr.

Der eigentliche Hebel steckt in den Speicherklassen. Dieselben Daten kosten je nach Klasse völlig unterschiedlich viel, weil sich Zugriffsgeschwindigkeit und Redundanz unterscheiden. Bei OVHcloud sah die Rechnung für fünf Terabyte so aus, alle Preise inklusive Mehrwertsteuer:

Klasse	Zonen	pro Monat
Cold Archive	3-AZ	9,90 €
Infrequent Access	1-AZ	23,80 €
Active Archive	3-AZ	26,80 €
Standard	1-AZ	42,22 €
Infrequent Access	3-AZ	56,51 €
Standard	3-AZ	83,26 €

Zwischen der günstigsten und der teuersten Zeile liegt der Faktor acht. Cold Archive liegt auf Magnetband: Die Daten sind nicht sofort verfügbar, eine Wiederherstellung dauert bis zu 48 Stunden und wird berechnet. Für ein Backup, das man hoffentlich nie anfasst, ist genau das die richtige Wahl.

Bemerkenswert an dieser Tabelle ist die Reihenfolge. Die günstigste Klasse ist gleichzeitig die mit drei Verfügbarkeitszonen – man muss also nicht zwischen Preis und Redundanz abwägen, sondern könnte die Daten direkt von OVHcloud noch einmal spiegeln lassen. Darauf habe ich verzichtet. Meine Daten sind schon auf dem NAS dank RAID redundant vorhanden. Für den Moment reicht mir die einfache Sicherung in der Cloud.

Der Container

Beim Anlegen des Containers gibt es einige Entscheidungen, von denen sich eine nachträglich nicht mehr korrigieren lässt.

Typ: S3-kompatible API. Die ältere Swift-Variante wird bei OVHcloud zurückgebaut, und rclone kommt mit S3 besser zurecht.

Region: Paris 3-AZ Hier gibt es keine Wahl. Cold Archive ist derzeit ausschließlich in dieser Region verfügbar. Wer bspw. Frankfurt nimmt, bekommt die Klasse gar nicht erst angeboten und landet bei Standard oder Infrequent Access.

Offsite-Replikation: aus. Das kopiert alles in eine zweite Region, und man zahlt den Speicher zweimal. Für ein Backup, das selbst schon die Auslagerung ist, ist das nicht zwingend das Original liegt ja noch auf dem NAS.

Object Lock: aus. Das ist die Einstellung, die man später nicht mehr ändern kann. Sie sorgt für echte Unveränderlichkeit, wie sie gegen Verschlüsselungstrojaner hilft, und sie funktioniert mit Cold Archive schlicht nicht. Wer sie will, braucht Active Archive und zahlt bei fünf Terabyte fast das Dreifache. Dazu setzt Object Lock Versionierung voraus, und dann bleibt jede überschriebene Datei als alte Version liegen und zählt weiter mit, was sich mit einer Mindestspeicherdauer schlecht verträgt.

Serverseitige Verschlüsselung: an, kostet nichts extra. Sie schützt gegen den physischen Zugriff auf ein Band, nicht gegen den Betreiber, denn der hält den Schlüssel. Wer seine Daten ohnehin clientseitig verschlüsselt, bekommt dadurch wenig dazu. Schaden tut sie nicht.

Sackgasse eins: Wo ist Cold Archive?

Container steht, Klasse auswählen, aber das beworbene „Cold Archive“ ist nirgends zu sehen. Unter „Storage“ stehen Block Storage, File Storage, Volume Backup, Volume Snapshot, Object Storage und Cloud Archive. Von Cold Archive keine Spur.

Die Auflösung besteht aus zwei Teilen.

Erstens: Cloud Archive ist nicht Cold Archive. Zwei Produkte, deren Namen sich um einen Buchstaben unterscheiden. Cloud Archive ist die alte, auf Swift basierende Variante. Cold Archive ist die S3-Klasse auf Magnetband.

Zweitens: Cold Archive ist keine eigene Produktkategorie mehr, sondern eine Speicherklasse innerhalb von Object Storage. Seit November 2025 gibt es die Funktion in zwei Ausprägungen. Die ältere archivierte ganze Container am Stück und wird Neukunden nicht mehr angeboten – deshalb taucht sie im Menü nicht auf. Die aktuelle arbeitet auf Objektebene innerhalb eines gewöhnlichen Containers, und dort wählt man die Klasse entweder beim Hochladen oder über eine Lifecycle-Regel.

Wer nach „Cold Archive“ als Menüpunkt sucht, sucht also vergeblich. Der Weg führt über Object Storage.

Sackgasse zwei: Die 30-Tage-Falle

Nun die Klasse setzen. Der dokumentierte Weg führt über eine Lifecycle-Regel: Objekte kommen in der Standard-Klasse an und werden nach einigen Tagen automatisch nach Cold Archive verschoben. Also im Container die Lifecycle-Verwaltung öffnen, Übergang anlegen, einen Tag eintragen, und die Oberfläche antwortet: The Transition must be at least 30 days.

Das ist keine Kleinigkeit. Dreißig Tage in der Standard-Klasse bedeuten bei fünf Terabyte rund 83 Euro, bevor die Daten überhaupt dort ankommen, wo sie hinsollen.

Die Lösung: Man braucht die Lifecycle-Regel gar nicht. Objekte lassen sich direkt in der Zielklasse hochladen. Nötig ist dafür nur die richtige Bezeichnung, denn OVHcloud bildet seine Klassen auf die von AWS eingeführten Werte ab. In 3-AZ-Regionen entspricht DEEP_ARCHIVE dem Cold Archive und GLACIER_IR dem Active Archive. (In der Konfiguration steht deshalb die Zeile storage_class = DEEP_ARCHIVE.)

Kurze Einführung: rclone und crypt

Ich hatte diesen Teil bereits stehen, weil mein Google-Back-up seit Jahren so lief. Wer neu einsteigt, findet hier den ganzen Weg und sollte einen Satz vorweg ernst nehmen: Bei clientseitiger Verschlüsselung gibt es keine Wiederherstellung des Passworts. Kein Anbieter, kein Support, keine Hintertür. Wer die beiden Passwörter verliert, hat mehrere Terabyte unlesbaren Datenmüll in Frankreich liegen. Das ist der Preis dafür, dass niemand außer einem selbst die Daten lesen kann.

rclone ist ein Kommandozeilenwerkzeug, das Dateien zwischen lokalen Verzeichnissen und rund siebzig Cloud-Diensten abgleicht. Man definiert sogenannte Remotes – benannte Ziele mit Zugangsdaten – und arbeitet dann mit ihnen wie mit Verzeichnispfaden.

crypt ist kein eigenes Ziel, sondern eine Schicht, die man über ein bestehendes Remote legt. Schreibt man in das crypt-Remote, verschlüsselt rclone Inhalt und Dateinamen und legt das Ergebnis im darunterliegenden Ziel ab. Liest man daraus, geschieht das Umgekehrte. Der Anbieter sieht nur Datenblöcke mit Namen wie perg7824m2n7fplrj6qlhgeelk und kann daraus weder Inhalte noch Ordnerstrukturen ableiten.

Beim Anbieter liegen also zwei Remotes übereinander: „ovh:“ spricht mit dem Objektspeicher, „ovhcrypt:“ ist das, womit man tatsächlich arbeitet.

Installation

Auf den meisten Systemen genügt:

curl https://rclone.org/install.sh | sudo bash

Auf einem NAS mit eigenem Paketsystem lohnt vorher ein Blick, ob rclone dort schon mitgeliefert wird. Eingerichtet wird rclone dann mit:

rclone config

Damit startet man einen interaktiven Prozess zur Konfiguration von rclone. Ich habe lieber direkt in die Konfigurationsdatei geschrieben – die kenne ich bereits von meinem Google-Back-up-Set-up. Deren Pfad verrät rclone config file

Zwei Abschnitte gibt es dort. Der erste spricht mit OVHcloud, der zweite legt die Verschlüsselung darüber:

[ovh]
type = s3
provider = Other
access_key_id = DEIN_ACCESS_KEY
secret_access_key = DEIN_SECRET_KEY
endpoint = s3.eu-west-par.io.cloud.ovh.net
region = eu-west-par
storage_class = DEEP_ARCHIVE
acl = private

[ovhcrypt]
type = crypt
remote = ovh:mein-container/docker
password = <verschleierter Wert>
password2 = <verschleierter Wert>

Die Zugangsdaten für den ersten Abschnitt erzeugt man im OVHcloud-Backend über einen eigenen S3-Benutzer. Ich habe ihm bewusst nur die Rolle für Objektspeicher gegeben und nicht die des Administrators – der Schlüssel liegt schließlich im Klartext in einer Datei auf einem Gerät, das dauerhaft am Netz hängt.

Darunter folgt die Verschlüsselungsschicht [ovhcrypt]:

Das darunterliegende Ziel wird als remote angegeben, und zwar inklusive Container und Zielpfad: ovh:mein-container/docker. (Weil ich hier alle meine Docker-Container sichern möchte.) Wichtig ist, hier einen Unterordner zu wählen und nicht die Container-Wurzel – dann bleibt’s übersichtlich, falls später ein zweites Backup dazukommt. Beispielsweise von einem Mac aus.

Dateinamenverschlüsselung:  Zur Wahl stehen standard, obfuscate und off. Ich empfehle standard. Mit off sieht der Anbieter zwar keine Inhalte, aber sämtliche Datei- und Ordnernamen und wer eine Verzeichnisstruktur lesen kann, weiß oft schon genug. Der Nachteil von standard: Die Namen werden länger. Bei Objektspeicher ist das unkritisch, weil S3 sehr lange Schlüssel erlaubt; bei manchen anderen Zielen mit einer Grenze von 255 Zeichen kann es bei tiefen Pfaden eng werden. Standard muss hier nicht gesondert angegeben wird.

Passwörter: rclone braucht hier zwei. Das erste als eigentliches Passwort, das zweite dient intern als Salt. Du kannst dir eigene ausdenken oder welche generieren lassen. Wichtig ist, dass du sie hier nicht im Klartext einträgst, sondern als verschleierten Wert.

rclone obscure "mein-passwort"

Die Klartext-Passwörter gehören natürlich trotzdem in deinen Passwortmanager!

Dass die Passwörter in der Konfigurationsdatei verschleiert stehen, ist keine Sicherheit, sondern nur Schutz vor Schulterblicken, denn jeder mit Lesezugriff auf die Datei kann sie zurückrechnen. Die Datei gehört entsprechend behandelt:

chmod 600 ~/.config/rclone/rclone.conf

Funktionstest, in beide Richtungen

Hochladen allein beweist nichts. Man will wissen, ob man wieder herankommt:

rclone copy /pfad/zum/testordner ovhcrypt:test --s3-storage-class STANDARD
rclone copy ovhcrypt:test /tmp/rueckweg
diff -r /pfad/zum/testordner /tmp/rueckweg
rclone purge ovhcrypt:test

Läuft diff ohne Ausgabe durch, funktioniert die ganze Kette aus Zugangsdaten, Verschlüsselung und Passwörtern in beide Richtungen. Das ist der eigentliche Beweis.

Die Angabe –s3-storage-class STANDARD überschreibt für diesen Test die Archivklasse — sonst landet auch die Testdatei auf Band und ließe sich nicht ohne Wartezeit zurückholen. Danach greift wieder der Wert aus der Konfiguration.

Der Sicherungsbefehl

rclone sync gleicht ab: Was in der Quelle fehlt, wird am Ziel gelöscht. Das ist gewollt, sollte einem aber bewusst sein, denn ohne Versionierung gibt es dort keinen Papierkorb. Wer ein Netz möchte, ergänzt –backup-dir und lässt gelöschte Dateien in ein datiertes Verzeichnis verschieben, statt sie zu entfernen – das kostet zusätzlichen Speicher und verträgt sich schlecht mit einer Mindestspeicherdauer.

Für den laufenden Betrieb packt man das Ganze in ein kleines Skript mit Protokolldatei und einer Sperrdatei, die verhindert, dass sich zwei Läufe überschneiden. Das ist besonders dann nötig, wenn ein Durchlauf länger dauern kann als der Abstand zwischen zwei Terminen im Zeitplan – bei einem mehrtägigen Erstlauf also immer.

In meinem Fall sieht das so aus, mit ein paar Ausnahmen für Ordner, die nicht gesichert werden müssen:

#!/bin/bash

QUELLE="/volume1/docker/"
ZIEL="ovhcrypt:"
LOGFILE="/var/log/rclone-backup.log"
LOCKFILE="/tmp/rclone-backup.lock"

if [ -f "$LOCKFILE" ]; then
echo "=== Backup läuft bereits, Abbruch: $(date '+%Y-%m-%d %H:%M:%S') ===" >> "$LOGFILE"
exit 1
fi
touch "$LOCKFILE"
trap "rm -f $LOCKFILE" EXIT

echo "" >> "$LOGFILE"
echo "=== Backup gestartet: $(date '+%Y-%m-%d %H:%M:%S') ===" >> "$LOGFILE"

rclone sync "$QUELLE" "$ZIEL" \
--log-file "$LOGFILE" \
--log-level INFO \
--transfers 8 \
--fast-list \
--order-by size,ascending \
--bwlimit 18M \
--exclude "/jellyfin/**" \
--exclude "/localai/**" \
--exclude "/freshrss/**" \
--exclude "/adguard/work/**" \
--exclude "*.tmp" \
--exclude ".DS_Store"

EXIT=$?
echo "=== Backup beendet: $(date '+%Y-%m-%d %H:%M:%S') | Exit-Code: $EXIT ===" >> "$LOGFILE"

Zwei Optionen verdienen eine kurze Erklärung.

–bwlimit 18M deckelt auf rund 150 Mbit/s. Bei gut 200 Mbit/s Upstream, die meine Leitung hergibt, bleibt damit genug Luft, dass die Leitung tagsüber nutzbar ist. Ohne Begrenzung ist der Anschluss über Tage belegt. Und ja, das lasse ich so für das initiale Back-up stehen. Danach werde ich sicherlich härter drosseln.

–order-by size,ascending sortiert nach Dateigröße aufsteigend. Die Konfigurationen, Dokumente und Datenbanken sind damit nach wenigen Stunden gesichert, die großen Videoblöcke kommen zuletzt. Das hat keinen echten Vorteil und ist mehr so Geschmacksache.

Praktisch nebenbei: Weil das Skript ein Lockfile setzt, kann der nächtliche Zeitplan, der von meinem Google-Back-up existiert, unverändert weiterlaufen. Er prallt jede Nacht daran ab und schreibt eine Zeile ins Protokoll. Sobald der Erstlauf durch ist, übernimmt er von selbst.

Aufräumen, solange es billig ist

Vor dem Erstlauf lohnt ein Blick auf das, was man da eigentlich hochlädt. Eine Mindestspeicherdauer von 180 Tagen verändert die Rechnung: Was einmal oben liegt, kostet ein halbes Jahr, auch wenn man es morgen löscht.

sudo du -sh /volume1/docker/* | sort -h

Bei mir waren das rund 2,9 Terabyte, verteilt auf zehn Verzeichnisse – mit einem sehr ungleichen Bild. Zweieinhalb Terabyte entfielen auf OpenCloud. 229 Gigabyte auf Hörbücher. Der ganze Rest zusammen kam auf weniger als zwei Gigabyte.

Aussortiert habe ich, was sich regenerieren lässt: die Metadaten und Bildcaches des Medienservers, die Modelldateien der lokalen KI, den Feedreader-Bestand, die Abfrageprotokolle des DNS‑Filters. Zusammen nur gut ein Gigabyte, aber es sind genau die Daten, die sich ständig ändern, und jede geänderte Datei löst bei einer Mindestspeicherdauer die anteilige Nachberechnung aus.

Bewusst drin geblieben sind die winzigen Verzeichnisse mit den Konfigurationen. Die Reverse-Proxy-Konfiguration meines Servers ist 60 Kilobyte groß und enthält Lösungen für Probleme, an denen ich einen halben Tag gesessen habe. Solche Dateien sind das Wertvollste im ganzen Backup und fallen bei der Volumenbetrachtung durch jedes Raster.

Wichtiger Rat dabei: Man arbeitet mit Ausschlüssen, nicht mit einer Positivliste. Wer in einem halben Jahr einen neuen Dienst anlegt, hat ihn dann automatisch im Backup. Bei einer Positivliste merkt man die Lücke erst, wenn man sie braucht.

Vor dem echten Lauf ein Trockenlauf:

sudo rclone sync /volume1/docker/ ovhcrypt: --dry-run \
--transfers 8 --fast-list --order-by size,ascending \
--exclude "/jellyfin/**" \
--exclude "/localai/**" \
--exclude "/freshrss/**" \
--exclude "/adguard/work/**" \
--exclude "*.tmp" \
--exclude ".DS_Store"

Die Zusammenfassung nannte 2,690 TiB in 82.551 Dateien, bei 102.599 gelisteten. Die Differenz sind die Ausschlüsse – und ein guter Moment, die Zeilen mit „Deleted“ genau zu lesen. Bei einem noch leeren Ziel sollte dort außer Testdateien nichts stehen.

Der erste Durchlauf

Und dann kann’s endlich losgehen! Damit ein Verbindungsabbruch den Lauf nicht abwürgt, gehört er in eine abgekoppelte Sitzung – hier schlicht nohup.

sudo nohup /usr/local/bin/rclone-backup.sh &
sudo tail -f /var/log/rclone-backup.log

Bilanz

Vorher: Verschlüsseltes Back-up im Google Drive für etwa 23 Euro pro Monat. Allerdings limitiert auf maximal 5 TB, dafür inklusive eines Abos für Googles KI „Gemini“, die ich aber überhaupt nicht nutze.

Nachher: 2,69 TiB auf Magnetband in französischen Rechenzentren, geschätzt rund 6 Euro im Monat. Dazu ein aufgeräumter Datenbestand, weil die Mindestspeicherdauer einen zwingt, über jedes Gigabyte nachzudenken.

Der Umzug hat mich einen Nachmittag Recherche und Einrichtung gekostet, dazu zwei Tage Laufzeit im Hintergrund. Die Sackgassen waren dabei der zeitraubende Teil. Wer diesen Text gelesen hat, spart sich das hoffentlich.

Teil der Wahrheit ist aber auch: Bestandteil des Google-Abos war auch YouTube Premium Light. Und ich weiß schon jetzt, dass das etwas sein wird, das ich schmerzlich vermissen werde. Hier werde ich also sicherlich ein gesondertes Abo abschließen, zu noch mal 6 Euro im Monat.

Dennoch: Unter dem Strich lande ich so bei 12 Euro im Monat. Das sind 11 gesparte Euro im Monat oder 132 gesparte Euro im Jahr. So habe ich quasi schon mal die Kosten für mein Dyn-Handball-Abo raus und das gute Gefühl, mein NAS-Back-up vollständig verschlüsselt auf europäischen Servern zu wissen.