Ein zusätzliches, verschlüsseltes Backup in der Cloud kostet wenig, sowohl finanziell als auch hinsichtlich der Performance, wenn es die Vorteile von Btrfs-Snapshots nutzt.

Eine Backup-Strategie, die sich die Errungenschaften moderner IT zunutze macht, umfasst drei Stufen: Snapshots im Dateisystem (Abbildung 1) gestatten es, schnell auf Dateiversionen von vor einer Stunde, gestern oder letzter Woche zurückzugreifen. Eine Sicherung auf einem externen Gerät, einem zweiten Rechner oder einer USB-Festplatte springt ein, falls das Speichergerät mit den Originaldaten ausfällt. In Zeiten, in denen 1 TByte Speicher in der Cloud bereits für wenige Euro monatlich zu haben ist, liegt es nahe, unersetzliche Daten zusätzlich dort zu sichern.

Abbildung 1: Da Btrfs-Snapshots ressourcenschonend anzulegen sind, bilden sie die beste technische Basis für mehrstufige Backup-Strategien.

Wir befassen uns im Folgenden detailliert mit der dritten Stufe der Datensicherung, die wichtige Daten verschlüsselt in einen Cloud-Speicher spiegelt. Dafür kommt Rclone [1] zum Einsatz, das Schweizer Taschenmesser der Cloud-Speichertechnologie.

Stufenweise

Für Backups von einem Datenträger mit dem unter OpenSuse standardmäßig verwendeten Dateisystem Btrfs [2] nutzen Sie am besten die Vorteile der dort verfügbaren Btrfs-Snapshots: Sie garantieren die Integrität und Vollständigkeit der Daten. Verschieben Sie dagegen eine Datei von Verzeichnis A nach B, nachdem ein konventionelles Backup-Programm den Scan abgeschlossen hat, fehlt sie im Backup. Datensicherung auf Basis des Snapshot-Mechanismus von Btrfs funktioniert wesentlich zuverlässiger. Ein Btrfs-Snapshot entsteht in Millisekunden ohne Kopieren der referenzierten Daten. Zusätzlichen Speicherplatz belegt er erst, wenn die eingefrorenen Dateien und die Versionen außerhalb des Snapshots auseinanderdriften.

Ein weiteres Feature von Btrfs, die Subvolumes [3], bildet die Basis für das Erstellen von Snapshots. Dabei handelt es sich um ein Mittelding zwischen Festplattenpartition und normalem Dateisystemordner. Subvolumes lassen sich genauso wie das Basisverzeichnis des Dateisystems mounten. Für Backups relevant ist, dass ein Schnappschuss immer aus einem vorhandenen Subvolume entsteht. Außerdem spart jeder Schnappschuss Sub-Subvolumes aus.

Wir gehen für unser Beispiel davon aus, dass Sie die Dateien im Ordner Dokumente/ in der Cloud sichern wollen. Dann benennen Sie den Ordner zunächst in Dokumente_alt/ um und erstellen als Root im Home-Verzeichnis mit dem Kommando btrfs subvolume create Dokumente ein neues Subvolume (Abbildung 2).

Abbildung 2: Das Kommando btrfs subvolume list /home zeigt neben vom Installer und dem System erstellten Subvolumes das eben angelegte Dokumente/. Der Dateimanager betrachtet es als normales Verzeichnis.

Damit gibt es einen neuen Ordner Dokumente/, der sich im Dateimanager und in Speichern-unter-Dialogen nicht von einem herkömmlichen Verzeichnis unterscheiden lässt. Der als Root ausgeführte Befehl btrfs subvolume list / identifiziert ihn jedoch als Subvolume des Root-Dateisystems. Machen Sie mit chown User:users Dokumente den Benutzer, in dessen Home er liegt, zum Eigentümer des Ordners.

Verschieben Sie anschließend über den Aufruf mv Dokumente_alt/* Dokumente/ die Daten aus dem alten Ordner in den neuen. Dokumente_alt/ können Sie nun löschen. Für ein Verschieben innerhalb eines Dateisystems rührt Linux die eigentlichen Daten nicht an, sondern verändert lediglich die Verzeichnisstruktur, sodass keine Wartezeit anfällt. Möchten Sie Ordner innerhalb von Dokumente/ vom Backup ausschließen, richten Sie mit derselben Abfolge von btrfs subvolume create innerhalb des Subvolumes Dokumente zusätzliche Subvolumes ein (Abbildung 3).

Abbildung 3: Ein Btrfs-Snapshot eines Volumes spart eingebettete weitere Subvolumes grundsätzlich aus. Das lässt sich zum Ausschluss bestimmter Unterverzeichnisse nutzen.

Sicher festgehalten

Das Kommando aus Listing 1 konserviert jetzt die Daten aus dem Dokumente-Subvolume in einem Snapshot. Dabei entsteht ein neuer Ordner, der in Wahrheit ein Read-only-Volume (Parameter -r) ist. Der Sinn des Namenssuffixes _full zeigt sich später, wenn wir auf den festgehaltenen Daten einen differenziellen Snapshot anlegen.

# btrfs subvolume snapshot -r Pfad/zum/Backup-Volume Pfad/zum/Snapshot/Dokumente_full

Rclone stellt für die Datenübertragung in die Cloud Äquivalente für Konsolenbefehle zur Dateiverwaltung wie Cp, Mv, Rm oder Ls zur Verfügung. Damit könnte man die Daten aus dem Snapshot direkt in die Cloud kopieren. Doch Linux-Anwender mit Administratorkenntnissen wissen, dass es effizienter ist, eine ganze Festplattenpartition mit Dd am Stück zu übertragen, statt sich auf Dateisystemebene um Tausende Dateien einzeln zu kümmern (Abbildung 4).

Abbildung 4: Die Lowlevel-Datenblöcke einer Partition oder eines Btrfs-Volumes sequenziell auszulesen (“dumpen”), kostet weniger System-Performance als das Übermitteln zahlloser Einzeldateien.

Der Befehl Dd lässt sich ausschließlich auf ganze Festplattenpartitionen anwenden, doch es gibt mit btrfs send eine auf Btrfs-Volumes und Snapshots zugeschnittene Entsprechung. Sie verpackt den Inhalt des Volumes in ein einziges, kontinuierliches Datenpaket. Rclone kann das daraufhin in einem Stück übertragen, ohne für jede der vielen Dateien im Snapshot eine neue Verbindung zum Server aufbauen zu müssen. Neuere Versionen von Rclone unterstützen diese direkte Verkettung (Pipeline) mit der Ausgabe von btrfs send ohne lokale Zwischenspeicherung. Das Hochladen großer Datenmengen setzt dann nicht länger entsprechenden freien Speicherplatz voraus.

Rclone besticht zudem dadurch, dass es nach einer interaktiven Konfiguration für unterschiedlichste Cloud-Dienste eine einheitliche Bedienung (Abbildung 5) bereitstellt. Es unterstützt dabei eine stattliche Anzahl konkreter Dienste [4]. Cloud-Dienste, die auf Standardprotokolle wie WebDAV, SSH/SFTP, Rsync oder SMB/CIFS oder Cloud-Techniken wie Amazon S3 oder Ceph setzen, lassen sich gleichfalls nutzen.

Abbildung 5: Das Werkzeug Rclone gestattet es nach einer Ersteinrichtung mit Cloud-Speicher auf unterschiedlichster technischer Basis so zu arbeiten wie mit einem lokalen Dateisystem.

Sie starten den interaktiven Konfigurationsvorgang durch Aufruf von rclone config als der Benutzer, der Rclone später ausführt. Da Btrfs-Operationen auf Dateisystemebene wie btrfs send administrative Rechte voraussetzen, handelt es sich dabei in unserem Fall um root. Einschlägige Parameter wie die URL zum Server (host), den Benutzernamen und das Passwort sind alles, was Sie dafür wissen müssen. Allerdings unterstützen längst nicht alle Cloud-Speicherdienste wenigstens eines dieser freien Protokolle, viele setzen allein auf eine proprietäre Windows- und MacOS-Anwendung.

Testen Sie eine eingerichtete Verbindung mit dem Kommando aus der ersten Zeile von Listing 2. Der Befehl aus der zweiten Zeile dient zum Anzeigen des Cloud-Datenbestands und der Code aus der dritten Zeile stößt ein erneutes Herunterladen vom Server an.

$ rclone copy lokale/Datei remote:/Server/Pfad
$ rclone ls remote:/Server/Pfad
$ rclone copy remote:/Server/Pfad lokale/Datei

Funktioniert die unverschlüsselte Verbindung, dann fällt es in Rclone leicht, sie zu verschlüsseln. Legen Sie per rclone config eine neue Verbindung vom Typ 13 / Encrypt/Decrypt a remote an und wählen Sie bei deren Einrichtung die getestete Verbindung als Basis. Rclone empfiehlt, die verschlüsselten Daten auf dem Server in einem Unterverzeichnis abzulegen, um sie von unverschlüsselten Dateien auseinanderzuhalten.

Sie dürfen zusätzlich zum normalen Verschlüsselungspasswort ein zweites, alternatives Passwort definieren, müssen die Möglichkeit aber nicht wahrnehmen. Zudem fragt das Programm, ob es Datei- und Verzeichnisnamen ebenfalls verschlüsseln soll, was beim vorgestellten Szenario, das lediglich die Dateien /backup/full.img und /backup/diff.img ablegt, überflüssig erscheint. Da der Sinn eines zusätzlichen Cloud-Backups darin besteht, Daten bei Zerstörung der lokalen IT durch zum Beispiel Naturkatastrophen zu retten, empfiehlt es sich, dieses Verschlüsselungspasswort zusammen mit den Daten für den Cloud-Dienst an einem zweiten Standort aufzubewahren.

Sobald eine verschlüsselte Verbindung steht, funktioniert sie wie eine unverschlüsselte Verbindung ohne Passworteingabe. Müssen Sie später die Daten auf einem neuen Rechner wiederherstellen, brauchen Sie dort lediglich Rclone zu installieren und wie beschrieben einzurichten, um an die beiden Btrfs-Dumps full.img und diff.img zu gelangen. Wie später erläutert wird, lässt sich daraus auf jedem Linux-Rechner das gesicherte Volume in ein Btrfs-Dateisystem rekonstruieren.

Beam me up

Bei der Einrichtung speichert Rclone alle Konfigurationsparameter inklusive Passwörter für ein remote:, also für einen Cloud-Dienst, der in der Konfiguration per auf Doppelpunkt endendem Namen referenziert ist. Im Anschluss genügt daher der Aufruf aus der ersten Zeile von Listing 3, um den Snapshot unter dem nach remote: genannten Dateipfad zu speichern.

$ btrfs send Pfad/zum/Backup-Volume Pfad/zum/Snapshot/Dokumente_full | pv -tba | rclone rcat remote:/backup/full.img
$ btrfs filesystem du -s Pfad/zum/Snapshot

Der zwischen dem Aufruf von btrfs send und rclone eingefügte Zwischenschritt per pv ist optional. Er misst die verstrichene Zeit, übertragene Datenmenge und durchschnittliche Geschwindigkeit der Übertragung. Die Größe des Snapshots und damit grob der zu übertragenden Datenmenge fördert das Kommando aus der zweiten Zeile von Listing 3 zutage. Abbildung 6 fasst den gesamten Backup-Vorgang vom Volume Dokumente bis zur Ablage in der Cloud noch einmal zusammen.

Abbildung 6: Das Kommando btrfs subvolume snapshot erstellt einen nur lesbaren Abzug des Volumes Dokumente, der Befehl btrfs send übermittelt dessen Inhalt als Datenstrom an den Aufruf rclone rcat. Rclone legt das Resultat schließlich als Image-Datei in der Cloud ab.

Bisher bestand die Funktion des aus dem Volume Dokumente erzeugten Snapshots lediglich darin, eine ausschließlich lesbare Variante zu generieren: Aus gutem Grund weigert sich btrfs send, einen Datenauszug eines lesbaren Volumes zu erstellen. Allein das verlangt schon den Zwischenschritt des Read-only-Snapshots. Doch die wahre Stärke eines Btrfs-Snapshot-basierten Backups zeigt sich, wenn Sie im Volume Dokumente Dateien verändern oder hinzufügen.

Erstellen Sie danach von Dokumente einen neuen Snapshot der veränderten Daten (Listing 4, erste Zeile) und dumpen Sie ihn per btrfs send (zweite Zeile), während Sie mit der Option -p zusätzlich den Schnappschuss der Daten vor der Veränderung angegeben. So fallen nur die neuen Daten an. Der Code aus der zweiten Zeile lädt den Snapshot dokumente_diff in die Cloud hoch. Dabei gibt pv, wie dargelegt, eine geringere Datenmenge zum Hochladen aus (Abbildung 7). Das Ganze nimmt weniger Zeit in Anspruch als bei dokumente_full. Ist der Diff-Snapshot in der Cloud angekommen, was Sie mit dem Befehl aus der dritten Zeile des Listings prüfen, ist er lokal überflüssig. Sie können ihn also löschen (Zeile 4).

$ btrfs subvolume snapshot -r Pfad/zu/Dokumente Pfad/zum/Snapshot/dokumente_diff
$ btrfs send -p Pfad/zu/dokumente_full Pfad/zu/dokumente_diff | pv -tba | rclone rcat remote:/backup/diff.img
$ rclone lsl remote:/backup/
$ btrfs subvolume delete Pfad/zu/dokumente_diff
$ btrfs send -p Pfad/zu/Dokumente_full Pfad/zu/dokumente_diff | pv -b > /dev/null

Abbildung 7: Nennen Sie btrfs send per Parameter -p einen älteren Snapshot des Volumes Dokumente als parent, errechnet Btrfs blitzschnell die Differenz der Snapshots und liefert nur die veränderten Daten.

Bevor Sie ein neues Voll-Backup starten, entfernen Sie das Volume dokumente_full ebenfalls, sonst schlägt die erneute Snapshot-Erstellung wegen des schon bestehenden Read-only-Volumes fehl. Lokal muss der Snapshot dokumente_full allerdings erhalten bleiben, solange in der Cloud genug Platz für den mit jeder Datenveränderung im Volume Dokumente anwachsenden differenziellen Snapshot zur Verfügung steht und Sie ein Diff-Backup vornehmen. Um zu entscheiden, ob das noch der Fall ist oder ein neues Voll-Backup ansteht, müssen Sie die Größe des Diff-Anteils erst einmal kennen. Unglücklicherweise zählt jedoch die Berechnung der Platzbelegung in Btrfs-Dateisystemen zu den auch nach über 10 Jahren Entwicklung immer noch nicht zufriedenstellend gelösten Problemen.

Zwar gibt es eine Quota-Funktion, die wie in anderen Linux-Dateisystem Maximalgrößen für bestimmte Verzeichnisse festlegt und dafür im laufenden Betrieb die Größe aller Ordner, Subvolumes und Snapshots ermittelt. Doch sie gilt laut den Entwicklern gerade einmal als “weitgehend in Ordnung”. Es droht zwar kein Datenverlust, aber das System kann beim Löschen von Snapshots für etliche Sekunden einfrieren. Auf einem OpenSuse-System, bei dem der Hintergrunddienst Snapper laufend Systemzustände festhält und veraltete Snapshots löscht, sollten Sie auf diese Funktion also besser verzichten.

Einen differenziellen Snapshot anzulegen und wieder zu löschen, falls er doch keine Verwendung findet, gelingt praktisch ohne Wartezeit. In der Praxis hat es sich deshalb als die beste Lösung erwiesen, einen differenziellen Snapshot nach /dev/null/ zu senden und dabei die Größe mit Pv zu messen (Listing 4, Zeile 5).

Anhand der gemeldeten Größe entscheiden Sie gegebenenfalls, ob Sie den zu großen Diff-Snapshot und folglich zusätzlich den Snapshot dokumente_full löschen sollten. Dann legen Sie wie beschrieben den vollen Datenschnappschuss neu an und laden ihn als neue Version des Voll-Backups hoch.

Zurückspielen

Jedes Mal, wenn Sie btrfs receive die Daten liefern, die btrfs send erzeugt hat, entsteht ein Volume mit identischem Inhalt. Ein Wiederherstellen des Cloud-Backups gelingt daher auf jedem Linux-System mit ausreichend großer Btrfs-Partition und installiertem Rclone. Das Btrfs-Dateisystem ist seit über zehn Jahren ein allgemeines Linux-Feature, Rclone ein in sämtlichen Distributionen verfügbares Linux-Programm.

Wie schon beim Backup lassen sich btrfs receive die Daten aus der Cloud per Rclone direkt via Pipe zuspielen, ohne sie in einer lokalen Datei zwischenzuspeichern. Das Kommando aus der ersten Zeile von Listing 5 stellt das Basis-Backup wieder her, das aus der zweiten Zeile kümmert sich um das ergänzende Diff-Abbild. Ein Parent-Verhältnis müssen Sie nicht angeben – Btrfs erkennt es, solange beide Backups im selben Btrfs-Dateisystem landen.

$ rclone cat remote:backup/dokumente_full.img | btrfs receive Pfad/zu/Btrfs-Dateisystem
$ rclone cat remote:backup/dokumente_diff.img | btrfs receive Pfad/zu/Btrfs-Dateisystem
$ btrfs subvolume snapshot Wiederhergestelltes_Volume ./Ordner
$ chmod -R 755 Pfad/zum/RW-Snapshot

Das aus dem Diff-Image entstandene Volume enthält alle gesicherten Dateien in ausschließlich lesbarer Form. Legen Sie daher mit dem Aufruf aus der dritten Zeile davon einen beschreibbaren Snapshot an, die Datenmenge im Dateisystem wächst dabei nicht. Mit dem letzten Kommando aus Listing 5 passen Sie die Dateizugriffsrechte an. Die beiden Read-only-Snapshots (volles und Diff-Backup) können Sie löschen, ohne die Daten im angelegten beschreibbaren Schnappschuss zu beeinträchtigen.

Wer Backups manuell ausführt, läuft Gefahr, dass just beim Datenverlust die letzte Sicherung lang zurückliegt. Darum bietet es sich an, die drei Backup-Schritte (Read-only-Snapshot erstellen, in die Cloud laden, Diff-Snapshot löschen) in ein Skript zu packen und per Systemd-Timer täglich oder, falls Beschränkungen des Cloud-Dienstes es nicht häufiger erlauben, wöchentlich auszuführen. Listing 6 zeigt ein dafür ausgelegtes Skript.

#!/bin/sh
ionice -c 3 -p $$
renice +12  -p $$
# zu sicherndes Volume
volume="/home/peter/Dokumente/"
# Verzeichnis für Snapshots
backup_dir="/home/peter/Snapshots/"
# verfügbarer Cloud-Speicherplatz in Bytes
storage_limit=1099511627776
# Maximalgröße für Diff unabhängig vom Cloud-Speicherplatz
diff_limit=274877906944
#Remote-Backup-Pfad für Rclone
rclone_remote="Hetzner:/backup/"
current_diffsize=0
# Voll-Backup
full_backup () {
  # alten Voll-Backup-Snapshot löschen, wenn vorhanden
  if [ -f $backup_dir$(basename $volume)_full ]; then
    btrfs subvolume delete $backup_dir$(basename $volume)_full
  fi
  # Snapshot aus Backup-Volume erstellen
  btrfs subvolume snapshot  -r $volume  $backup_dir$(basename $volume)_full
  # btrfs send mit Pipe zu rclone
  btrfs send $backup_dir$(basename $volume)_full | pv -b| rclone rcat $rclone_remote/full.img
  # rclone lsl zeigt wie ls -l die Größe des Full-Images und schreibt sie in eine lokale Datei
  rclone lsl $rclone_remote/full.img  | awk '{print $1}' > $backup_dir/uploaded_full_size
  echo "######## finished full backup"
}
# Diff-Backup
diff_backup () {
  # zweiten Snapshot für Diff auf Basis des Voll-Backup-Snapshots
  btrfs subvolume snapshot  -r $volume  $backup_dir$(basename $volume)_diff
  # btrfs send mit Pipe zu rclone mit Volume für Diff
  btrfs send -p $backup_dir$(basename $volume)_full $backup_dir$(basename $volume)_diff | rclone rcat $rclone_remote/diff.img
  # zweiten Snapshot für Diff löschen
  btrfs subvolume delete $backup_dir$(basename $volume)_diff
  echo "######## finished diff backup"
}
# gegenwärtige Diff-Größe berechnen
diff_size () {
  # Diff-Snapshot nur für Größentest
  btrfs subvolume snapshot  -r $volume  $backup_dir$(basename $volume)_diff
  # wc (word count) zählt im -c-Modus Bytes aus btrfs send
  current_diffsize=$(btrfs send -p $backup_dir$(basename $volume)_full $backup_dir$(basename $volume)_diff
 | wc -c)
  ## Diff-Snapshot wird evtl. nicht gebraucht
  btrfs subvolume delete $backup_dir$(basename $volume)_diff
}
###########################
### Skript startet hier ###
###########################
# Wenn schon ein volles Backup existiert ...
if [ -f $backup_dir/uploaded_full_size ]; then
  diff_size
  fs=$(cat $backup_dir/uploaded_full_size)
  # ... die Gesamtgröße von Voll- und Diff-Backup berechnen
  gs=$(echo "$current_diffsize+$fs" | bc)
  # Wenn Gesamtgröße < max. Cloud-Speicher und < max. Diff-Größe ...
  if  (( gs < storage_limit )) && (( current_diffsize < diff_limit )); then
    # ... Diff-Backup
    diff_backup
  else
    # ... ansonsten volles Backup
    full_backup
  fi
else
  # Wenn noch kein volles Backup vorliegt
  full_backup
fi

Um die System-Performance möglichst wenig zu beeinflussen, setzt das Skript ganz zu Beginn seine eigene CPU- und I/O-Priorität herab. Daraufhin folgen vom Anwender zu konfigurierende Variablen: volume nennt die Lage des für das Backup bestimmten Btrfs-Volumes, backup_dir die Lage des für Diff- und Voll-Snapshots angelegten Verzeichnisses. Das storage_limit gibt an, wie viele Bytes der Cloud-Speicher fasst, diff_limit legt eine unabhängige Maximalgröße für das Diff-Image fest. Unabhängig vom freien Speicherplatz sollte das Diff-Image aus praktischen Erwägungen deutlich kleiner bleiben als das Voll-Backup. Ein rclone_remote schließlich nennt den Konfigurationsnamen des in Rclone konfigurierten Servers und, nach dem Doppelpunkt, den Cloud-Pfad zum Ablegen der Images.

Die drei folgenden Funktionen leisten die Hauptarbeit. Sie erstellen ein volles oder ein Diff-Backup und laden es in die Cloud. Der Befehl diff_size misst die Größe eines sogleich verworfenen Daten-Dumps und löscht auch den zugehörigen Snapshot sofort wieder.

Die Programmlogik ab Zeile 52 muss dann nur noch anhand der errechneten Größen entscheiden, ob das Skript ein volles oder ein Diff-Backup anlegen soll. Liegt bisher gar kein volles Backup vor, steht ein solches auf jeden Fall an. Ansonsten schätzt die Funktion diff_size in Zeile 53 die Größe der seit dem Voll-Backup veränderten Daten. Zeile 54 holt die von full_backup in einer Textdatei abgelegte Datenmenge des letzten Gesamt-Backups.

Zeile 56 addiert die beiden Werte mithilfe des in Shell-Skripten dafür üblichen Kommandozeilenrechners Bc. Die folgende If-Else-Verzweigung schließt aus der errechneten Gesamtgröße, ob ein weiteres Diff-Backup in den Cloud-Speicher passt und ob das Diff unterhalb der unabhängig davon konfigurierten Diff-Maximalgröße liegt. Ist beides der Fall, erfolgt ein Diff-Backup, ansonsten ein Voll-Backup.

Um das Skript per Systemd-Timer regelmäßig auszuführen, legen Sie es als Root unter /usr/local/bin/cloudbackup.sh ab und machen es mit chmod +x /usr/local/bin/cloudbackup.sh ausführbar. Erstellen Sie außerdem im Ordner /etc/systemd/system/ die beiden Dateien cloudbackup.service (Listing 7) und cloudbackup.timer (Listing 8). Dann laden Sie die Systemd-Konfiguration mit systemctl daemon-reload neu und aktivieren den Timer mit systemctl enable cloudbackup.timer.

[Unit]
Description=Cloud backup
[Service]
Type=simple
ExecStart=/usr/local/bin/cloudbackup.sh

[Unit]
Description=Run Cloud backup regularly
[Timer]
OnCalendar=daily
Persistent=true
[Install]
WantedBy=timers.target

Fazit

Den Inhalt eines Btrfs-Snapshots mit btrfs send direkt per Pipe an rclone rcat zu senden, stellt den Königsweg des Cloud-Backups dar. Die atomaren Snapshots garantieren die Konsistenz der Daten; die Diff-Backups entstehen, ohne den Rechner durch lähmendes Prüfen zahlloser Dateien auf Veränderung zu belasten. Das Versenden per Pipe erspart es, die Daten lokal zwischenzuspeichern und gelingt sogar, wenn eigentlich der Speicherplatz dafür fehlt.

Es bleibt der Wermutstropfen, dass Rclone die Funktion der Datenübernahme per Pipe nicht für alle Cloud-Typen garantiert. Beim Test mit einer Hetzner Storage Box per WebDAV, dem im Grunde elementarsten Datenversandprotokoll, funktionierte es. Laut Rclone-Dokumentation klappt es allerdings beispielsweise beim Zusammenspiel mit Owncloud und WebDAV nicht.

In einem solchen Fall bleibt nichts anderes übrig, als für ausreichend freien Zwischenspeicherplatz zu sorgen und die Ausgabe von btrfs send per -f-Parameter in eine temporäre Datei umzuleiten. Die verschieben Sie dann im zweiten Schritt mittels rclone move remote:/Pfad in die Cloud. (uba)