Binfort
Well-Known Member
Moin!
Das gewünschte Setup:
Das Volume kann jetzt einen weiteren Zpool erhalten, allerdings machten die Backups mit zfs send/recv Probleme. Im eng Forum fand sich außerdem ein Hinweis auf Dead Locks bei Zpools innerhalb Zvols. Also:
So würde die Dead Lock Problematik umgangen. Die Backups mit zfs send/recv funktionieren zwar, jedoch nicht inkrementell. Da zfs snap vom eigentlichen Volume erstellt wird, kann das doch gar nicht gehen, oder? Nächster Versuch:
Das funktioniert dann und das Setup wäre erreicht. Ein paar Schritte verstehen sich von selbst und wurden übersprungen.
Wäre dies eine denkbare Herangehensweise für einen produktiven Server? Was würdet ihr anders lösen oder wo seht ihr Probleme?
Mir gefällt die Flexibilität des ZFS im Unterbau, sollte es in Zukunft eine andere Lösung geben, könnte ich das Volume auch flott umkonfigurieren bzw. die Jails in verschlüsselte FS Datasets stecken.
Alternativ kann meine Anforderung natürlich auch herkömmlich mit GPT Partitionen erfüllt werden.
Das gewünschte Setup:
- FreeBSD 11 mit ZFS
- Hostsystem unverschlüsselt
- Jails auf ZFS Volume mit Geli verschlüsselt
- inkrementelles Backup der Jails
Code:
zfs create -V 100G zroot/jails
geli init -s 4096 -K jails.key /dev/zvol/zroot/jails
geli attach -k jails.key /dev/zvol/zroot/jails
Code:
newfs -O2 -U -f 4096 /dev/zvol/zroot/jails.eli
mount /dev/zvol/zroot/jails.eli /data/jails
Code:
dump -0 -Lauf lvl0_jails /data/jails
dump -1 -Lauf lvl1_jails /data/jails
Wäre dies eine denkbare Herangehensweise für einen produktiven Server? Was würdet ihr anders lösen oder wo seht ihr Probleme?
Mir gefällt die Flexibilität des ZFS im Unterbau, sollte es in Zukunft eine andere Lösung geben, könnte ich das Volume auch flott umkonfigurieren bzw. die Jails in verschlüsselte FS Datasets stecken.
Alternativ kann meine Anforderung natürlich auch herkömmlich mit GPT Partitionen erfüllt werden.