ZFS Pool "verschicken"

[Shihatsu]

Moin, komische Herausforderung:
Standort A hat einen ZFs Pool. Dieser soll encrypted werden und bei Bedarf entnommen, nach Standort B gebracht und dort in Betrieb genommen werden. Während des Transports müssen die Daten vor Zugriff sicher sein.
In den Standorten wird aber nicht noch weitere Sicherheit gebraucht. Wie würdet ihr das machen?

Meine grobe Idee dazu:
Ich erstelle den Pool encrypted und lege mir Key + passphrase ab. Diese transportiere ich zum andere Standort, doert binde ich den Pool nach Versand ein und entschlüssele ihn - bis hier hin ja kein Thema, oder? Habe mich noch nicht mit encrypted ZFS befasst, daher die "naive" Frage - bin noch ganz am Anfang der Recherche...

Bonusfrage: Geht einhängen und encrypten auch automatisch? Also ohne Benutzerinteraktion?

 

[Supaman]

Über welche Datenmenge reden wir ?
Um welche Art Quelldaten handelt es sich / welche Art Zielsysteme greifen auf den Datenbestand zu ? (Datenbank, Fileserver, whatever )

Was soll das eigentlich Ziel der Aktion sein ? Je nach Konstrukt / Datenmenge könnte man die Daten ggf. auf permanent syncen, dann stellt sich das problem mit dem Transport und verschlüsselung nicht.

 

[gea]

Moin, komische Herausforderung:
Standort A hat einen ZFs Pool. Dieser soll encrypted werden und bei Bedarf entnommen, nach Standort B gebracht und dort in Betrieb genommen werden. Während des Transports müssen die Daten vor Zugriff sicher sein.
In den Standorten wird aber nicht noch weitere Sicherheit gebraucht. Wie würdet ihr das machen?

Meine grobe Idee dazu:
Ich erstelle den Pool encrypted und lege mir Key + passphrase ab. Diese transportiere ich zum andere Standort, doert binde ich den Pool nach Versand ein und entschlüssele ihn - bis hier hin ja kein Thema, oder? Habe mich noch nicht mit encrypted ZFS befasst, daher die "naive" Frage - bin noch ganz am Anfang der Recherche...

Bonusfrage: Geht einhängen und encrypten auch automatisch? Also ohne Benutzerinteraktion?

Im Prinzip korrekt.
Das verschlüsselte Dateisystem entweder raw oder unterhalb eines verschlüsselten Pools auf einer Platte z.B. USB replizieren und sind damit verschlüsselt entweder mit den Original Key oder dem Key des verschlüsselten Parent Pools. Am besten mit copies=2 arbeiten damit Fehler auf der USB Platte nicht nur erkannt sondern repariert werden können.

Auf dem Ziel einen unverschlüsselten Pool anlegen. Darunter das verschlüsselte der unverschlüsselte Dateisystem hinreplizieren.

Alternative:
Netze oder Server per VPN koppeln und direkt replizieren

Zum automatischen Unlock eines verschlüsselten Dateisystems muss man den Key laden. Als Quelle kommen Datei oder https Webserver in Frage, als Methode ein Startscript. Hilfreich ist eine Web-GUI. Lokale Keys sollte man aber vermeiden, sonst kann jeder mit Zugriff auf das System ein unlock durchführen.

In meiner web-gui nutze ich remote keys auf https auch von öffentlichen HTTPS Servern mit gültigem Zertifikat und 3x keysplit um zu vermeiden dass ein admin (lokal oder webserver) Zugriff auf die Keys hat. Zudem geht dann Hochverfügbarkeit mit 2 Webservern von denen einer off sein darf. Grundsätzlich kann man einen Filekey immer per Prompt überschreiben. Wenn man mit guten Password Hashes arbeitet, kann man auch einfache, kurze Passworte nutzen aus denen der Keyhash erzeugt wird, https://www.napp-it.de/doc/downloads/napp-it_cs_encryption.pdf

 

[Shihatsu]

Über welche Datenmenge reden wir ?
Um welche Art Quelldaten handelt es sich / welche Art Zielsysteme greifen auf den Datenbestand zu ? (Datenbank, Fileserver, whatever )

Was soll das eigentlich Ziel der Aktion sein ? Je nach Konstrukt / Datenmenge könnte man die Daten ggf. auf permanent syncen, dann stellt sich das problem mit dem Transport und verschlüsselung nicht.

Permanentsync war auch mein erster Gedanke, daraufhin wurde instant abgewunken. Geht um ne Anforderung eines Kunden der das "immer schon so gemacht hat" - geht um nicht wenig Daten, zwischen 60 und 100 TB, und dabei wirklich verschiedenes - Messdaten, 4k Filme, Excelfiles, wildeste Mischung. 2 verteilte Standorte, einer erhebt Daten, einer verarbeitet sie. Sämtliche Hinweise auf "Man macht das heutzutage eigentlich ganz anders" wurden unsanft wegmoderiert.

Im Prinzip korrekt.
Das verschlüsselte Dateisystem entweder raw oder unterhalb eines verschlüsselten Pools auf einer Platte z.B. USB replizieren und sind damit verschlüsselt entweder mit den Original Key oder dem Key des verschlüsselten Parent Pools. Am besten mit copies=2 arbeiten damit Fehler auf der USB Platte nicht nur erkannt sondern repariert werden können.

Auf dem Ziel einen unverschlüsselten Pool anlegen. Darunter das verschlüsselte der unverschlüsselte Dateisystem hinreplizieren.

Alternative:
Netze oder Server per VPN koppeln und direkt replizieren

Zum automatischen Unlock eines verschlüsselten Dateisystems muss man den Key laden. Als Quelle kommen Datei oder https Webserver in Frage, als Methode ein Startscript. Hilfreich ist eine Web-GUI. Lokale Keys sollte man aber vermeiden, sonst kann jeder mit Zugriff auf das System ein unlock durchführen.

In meiner web-gui nutze ich remote keys auf https auch von öffentlichen HTTPS Servern mit gültigem Zertifikat und 3x keysplit um zu vermeiden dass ein admin (lokal oder webserver) Zugriff auf die Keys hat. Zudem geht dann Hochverfügbarkeit mit 2 Webservern von denen einer off sein darf. Grundsätzlich kann man einen Filekey immer per Prompt überschreiben. Wenn man mit guten Password Hashes arbeitet, kann man auch einfache, kurze Passworte nutzen aus denen der Keyhash erzeugt wird, https://www.napp-it.de/doc/downloads/napp-it_cs_encryption.pdf

Nee, Kopien sind auch nicht okay. Es sollen die Platten verschickt werden. Also quasi die Lösung mit dem Script, Key auf beiden Seiten verhanden machen. BOAH ist das scheiße....

 

[gea]

Also Standort A hat 100TB Daten die man einmalig oder regelmäßig zu Standort B bringen will. Ich nehme an dass auf A immer die "Master" Daten liegen.

Lösung
A hat einen ZFS Server mit einem 100 TB Pool und den "Originaldaten".
(Ich nehme nicht an, dass man den Originalpool verschicken will, ginge natürlich auch)

Daran schließt man zusätzlich ein SAS Jbod an (z.B. 8 Bay mit 20TB Platten als Z2) und repliziert das Daten Dateisystem (oder die Dateisysteme) hierher auf einen verschlüsselten Transport Pool (Key ist der Schlüssel des Transport Pools, Master Daten waren unverschlüsselt) oder raw auf einen unverschlüsselten Zielpool (Key ist der Schlüssel der Quell Dateisysteme) und verschickt das Jbod zu Standort B

Dort kann man entweder mit dem Jbod direkt arbeiten oder man hat da auch einen Server mit 100 TB und repliziert darauf die Dateisysteme des Transportpools. Zum Entschlüsseln muss man den Key eingeben, mitliefern oder zentral auf einem oder mehreren Webservern mit oder ohne Keysplit bereitstellen.

Soll das turnusmäßig passieren?
Dann den Transportpool zurück zu A, dort incrementell erneut syncronisieren, wieder damit zu B und dort den lokalen Pool mit dem Transport pool inkrementell syncronisieren.

100 TB initial umkopieren dauert Tage, ein incrementeller sync anschließend je nach Datenmenge nur Minuten.

Nur ein Datenspeicher und Client Zugriff per SMB und VPN wäre eleganter....

 

[Supaman]

Eine einfache Lösung wäre: NAS System mit TrueNAS, und dann verschlüsselte Pools anlegen. Zugriff auf die Daten über SMB / NFS / whatever, und dann Sync Tools.

Die Pools müssen nach booten des Systems manuell per Password übers Web GUI freigeschaltet werden oder Du könntest den Pool Automount auch scripten, in dem die Passphrase an beiden Standorten von einem Server im lokalen Netz geholt wird.

 

[gea]

Warum denn die gleichen Daten zweimal auf 2 Standorten?
Eigentlich ist man ja froh wenn man nur einmal Daten hat.

Man muss ja lediglich dafür sorgen dass Nutzer von beiden Standorten sicher und schnell darauf zugreifen können. Ein simples VPN mit Wireguard kann beides, kostet nichts oder fast nichts und ist extrem einfach einzurichten, egal ob per Software oder kleiner Hardware Appliance.

 

[Haldi]

Nee, Kopien sind auch nicht okay.

Dämliche Frage...
Aber wenn Kopien nicht erlaubt sind und die Originale verschickt werden. (Wohl kaum per UPS oder sonst nen Kurier) Wieso dann nicht einfach ein Kompakt NAS das komplett transportiert wird?
Dann kannste dir das ganze einrichten sparen.

 

[andrer250282]

Dämliche Frage...
Aber wenn Kopien nicht erlaubt sind und die Originale verschickt werden. (Wohl kaum per UPS oder sonst nen Kurier) Wieso dann nicht einfach ein Kompakt NAS das komplett transportiert wird?

Wäre auch mein Gedanke gewesen, aber ich nehme an, während der Datenstand von Zeitpunkt X verschickt wird soll an Standort A nahtlos weiter gearbeitet werden?

Der Vorschlag von @gea wäre noch am praktikabelsten, denke ich. Wobei gar nicht gesagt wurde ob Daten von Standort B überhaupt zurück gespielt werden sollen?

 

[sandreas]

Hier wurde schon viel zum theoretischen "wie wäre das möglich" gesagt, ich setze das tatsächlich praktisch so um:

• Tasmota Steckdose wird eingeschaltet
• Externe USB-Platte startet
• Backup-Pool auf der USB-Platte wird importiert
• zfs synchronisiert den pool inkrementell auf die USB-Platte
• Nach Erfolg wird der backup pool exportiert
• die Platte wird ausgeschaltet

Letzten Endes läuft das ganze dann auf folgende 2 Befehle raus...
Hinweise:

• durch das `--raw` kann man auch verschlüsselte Pools ohne den Schlüssel versenden
• das `pv |` ist nicht nötig (man muss das Tool installieren), man kann damit nur sehr gut überwachen, wie viele Daten schon gesendet wurden

# vollständiges backup anlegen (nur beim ersten Mal, wenn das Backup noch leer ist)
zfs send --raw -R "$SRC_POOL@$NEW_SNAP_NAME" | pv | zfs recv -Fdu "$DST_POOL"

# inkrementelles Backup (zwischen alles zwischen zwei Snapshots), wenn das erste Backup mal gelaufen ist
zfs send --raw -RI "$BACKUP_FROM_SNAPSHOT" "$BACKUP_UNTIL_SNAPSHOT" | pv | zfs recv -Fdu "$DST_POOL"

Die Platte könntest du dann auf dem Zielsystem an der anderen Location einfach mit diesem Befehl wieder zurück syncen (natürlich musst du dort Source und Destination umdrehen). Größter Vorteil: durch das inkrementelle Senden mit ZFS würdest du wirklich nur die Daten übertragen, die sich verändert haben, was extrem viel Zeit sparen würde und du hättest auf der externen Platte stets eine vollständige Kopie aller Daten inkl. Snapshots.

Der Vollständigkeit halber hier noch mal das ganze Backup-Script. Ist kein Meisterwerk, aber es läuft bei mir alle 3 Tage per cronjob. Wenns geiler werden muss, schau dir mal zsync an.

#!/bin/sh
# name of source pool
SRC_POOL="rpool"

# name of destination pool
DST_POOL="rpoolbak"

# tasmota shelly plug host
TASMOTA_HOST="http://192.168.1.55"


DATE="$(date +%F)"
BACKUP_PREFIX="backup-"
NEW_SNAP_NAME="$BACKUP_PREFIX$DATE"
NEW_POOL_SNAP="$SRC_POOL@$NEW_SNAP_NAME"

# helpful commands:

# destroy all backups and start with a fresh full backup
# zpool destroy rpoolbak
# zpool create rpoolbak /dev/sdb

# list all snapshots
# zfs list -H -o name -t snapshot -r rpoolbak
# zfs list -H -o name -t snapshot -r rpoolbak | xargs -n1 zfs destroy

# destroy datasets recursively
# zfs destroy -R -f rpoolbak/ROOT


echo "starting backup $NEW_POOL_SNAP"

echo "switching on tasmota: $TASMOTA_HOST"
curl "$TASMOTA_HOST/cm?cmnd=POWER+ON"
echo ""

# import destination pool, but do not mount
LAST_IMPORT_POOL="$(zpool list -o name | tail -1)"
if ! [ "$LAST_IMPORT_POOL" = "$DST_POOL" ]; then
    echo "importing $DST_POOL in 30 seconds..."
    sleep 30
    zpool import -N "$DST_POOL"
fi

# check import did work
LAST_IMPORT_POOL="$(zpool list -o name | tail -1)"
if ! [ "$LAST_IMPORT_POOL" = "$DST_POOL" ]; then
    echo "ERROR: failed to import $DST_POOL"
    exit 1
fi

# disable zfs-auto-snapshot for destination pool, if not done
DST_POOL_AUTO_STATE="$(zfs get com.sun:auto-snapshot $DST_POOL -o value | tail -1)"
if ! [ "$DST_POOL_AUTO_STATE" = "false" ]; then
    echo "disabling zfs-auto-snapshot for $DST_POOL"
    zfs set com.sun:auto-snapshot=false "$DST_POOL"
fi

# create daily snapshot, if not exists
DAILY_SRC_SNAP="$(zfs list -H -o name -t snapshot "$SRC_POOL" | grep "@$NEW_SNAP_NAME")"
if [ "$DAILY_SRC_SNAP" = "" ]; then
    echo "creating backup snapshot: $NEW_POOLSNAP"
    zfs snapshot -r "$NEW_POOL_SNAP"
fi

# check last snapshot, that has been synced
LAST_DST_SNAP="$(zfs list -H -o name -t snapshot "$DST_POOL" | grep "@$BACKUP_PREFIX" | tail -1 | cut -d '@' -f 2)"
if [ "$LAST_DST_SNAP" = "" ]; then
    echo "no existing snapshot found, full backup required"
    # no existing snapshot, full send
    zfs send --raw -R "$SRC_POOL@$NEW_SNAP_NAME" | pv | zfs recv -Fdu "$DST_POOL"
else
    BACKUP_FROM_SNAPSHOT="$SRC_POOL@$LAST_DST_SNAP"
    BACKUP_UNTIL_SNAPSHOT="$SRC_POOL@$NEW_SNAP_NAME"

    if [ "$LAST_DST_SNAP" = "$NEW_SNAP_NAME" ]; then
        echo "backup snapshot already exists on target, skipping"
    else
        echo "newest existing snapshot found: $SRC_POOL@$LAST_DST_SNAP"
        echo "incremental backup $BACKUP_FROM_SNAPSHOT -> $BACKUP_UNTIL_SNAPSHOT"
        # zfs send -RI --raw "$SRC_POOL@$LAST_DST_SNAP" "$SRC_POOL@$NEW_SNAP_NAME" | pv | zfs recv -Fdu "$DST_POOL"
        zfs send --raw -RI "$BACKUP_FROM_SNAPSHOT" "$BACKUP_UNTIL_SNAPSHOT" | pv | zfs recv -Fdu "$DST_POOL"
    fi
fi

echo "exporting pool and power off tasmota in 5 seconds..."
sleep 5
zpool export "$DST_POOL" && sleep 5 && curl "$TASMOTA_HOST/cm?cmnd=POWER+OFF"
echo ""
echo "done"