Filesysteme remote gemounted

Warum Debian und/oder eine seiner Spielarten? Was muss ich vorher wissen? Wo geht es nach der Installation weiter?
Antworten
scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Filesysteme remote gemounted

Beitrag von scientific » 11.05.2017 10:30:33

Hi Leute!

Ich möchte jetzt meine backupsuite für btrfs netzwerkfähig machen, und bin dabei infos zu sammeln, wie ich das am besten lösen könnte.

Prinzipiell muss das ziel-fs auch btrfs sein. Das ist grundvoraussetzung.

Btrfs send|receive kann direkt über ssh gepiped werden.
Aber ich frag mich gerade, wie ich das am besten realisiere, sodass ich auch mit einem fuse-filesystem regelmäßig drauf zugreifen kann.

Ich finde ja sshfs ansich eine gute lösung, da dann das remote-fs ganz "normal" für alle anwendungen zugänglich ist. Und solange das fs gemountet ist, brauchts nicht für jedes stat einen ganzen ssh-login-prozess.

Im skript gibts nämlich mehrere aufrufe des zielfs. Ich hab diese soweit reduziert, wie irgendwie möglich. Aber diese sind jetzt unbedingt notwendig.
Sshfs ist halt als fuse-fs etwas langsamer. Das könnte bei größeren datenmengen (wie sie bei einem backup auftreten können)ja durchaus störend werden.

Oder nfs...
Wenn ich ein fs mit nfs freigebe, wird das am client als spezielles fs angezeigt, oder erkennt der das als z. B. Btrfs und kann es vollumfãnglich nutzen?

Und nfs hat ja auch so seine tücken. Seit es sun nicht mehr gibt, ist die Entwicklung eingeschlafen. Und die sicherheit ist anscheinend in v3 nicht so berauschend...

Ich möchte mein programm nämlich um die möglichkeit erweitern, es auch bei clouddiensten (eigener server) als 2. Ebene zu sichern die geographisch vom ersten standort verschieden ist.

Lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

r4pt0r
Beiträge: 1237
Registriert: 30.04.2007 13:32:44
Lizenz eigener Beiträge: MIT Lizenz

Re: Filesysteme remote gemounted

Beitrag von r4pt0r » 11.05.2017 14:59:02

Wozu willst du das remote-dataset mounten? Das ist doch das backup wenn ich dich richtig verstehe...
Zumindest mit ZFS erstelle ich snapshots und sende dann nur einen inkrementellen stream zum backup-pool.
Ein backup sollte _NIEMALS_ schreibend irgendwo eingehängt werden - 1. ist der Sinn von backups, dass sie nicht verändert werden und 2. weicht der pool bzw die datasets sonst vom original ab und es werden keine inkrementellen snapshots mehr akzeptiert bis man alles wieder in sync mit dem original bringt (=die änderungen verwirft).

Für Systeme ohne ZFS sammelt bei mir AMANDA wie gewohnt die backups ein. Die Verzeichnisse der vtapes liegen auf einem eigenen dataset von dem abschließend ein snapshot erstellt wird, der dann per send|receive zum backuppool übertragen wird. Das ist zwar nicht wirklich optimal und lässt sich sicherlich weiter optimieren; da die Anzahl der Systeme ohne ZFS aber sowieso immer weiter Richtung 0 läuft ist das für mich eher zu vernachlässigen da mittelfristig ohnehin obsolet...

Zum Thema NFS: wenn du deinem eigenen LAN bzw dem VLAN das für backups genutzt wird nicht trauen kannst, ist NFS dein kleinstes Problem...
NFS arbeitet auf Dateiebene - der Client hat keine Ahnung welches Dateisystem darunter liegt. Um das Dateisystem am Client direkt einzuhängen und zu nutzen, muss das gesamte Blockgerät exportiert werden (z.B. per iSCSI oder FC).

scientific
Beiträge: 3020
Registriert: 03.11.2009 13:45:23
Lizenz eigener Beiträge: Artistic Lizenz
Kontaktdaten:

Re: Filesysteme remote gemounted

Beitrag von scientific » 11.05.2017 17:15:01

Ich kenne zfs nicht.

Bei btrfs ist es zumindest so, dass ich von einem subvolume einen snapshot mache.
Diesen snapshot (readonly) kann ich dann per send/receive auf ein zweites btrfs übertragen.
Ist für send eine parent ausgewählt, werden nur die differenzen vom snapshot zum parent (ein älterer snapshot) übertragen.
Dieser ältere snapshot muss am ziel ebenfalls vorhanden sein, dann erzeugt receive mit den übertragenen differenzen den neueren snapshot aus dem älteren.
Dazu muss der pool aber beschreibbar sein, wenngleich die einzelnen snapshots aber nur readonly sein dürfen.

Ich kann natürlich auch mit send die differenz erstellen un in ein file schreiben lassen.
Dieses File lässt sich dann per wechseldatenträger zum backupsystem tragen, oder mit irgen einem dateiübertragungsprogramm, und wird am backuosystem entweder so abgelegt, oder mit receive in den backupdatenträger eingebunden.

Ich hab für meine Situation hier einen kleinen Platinenrechner im Sinn, auf dem ein minimales debian läuft, und in das ich an wohldefinierter stelle eine große btrfs-platte einhänge (usb). Dieser mountpunkt wird dann per LAN an die beiden Laptops im Netz weitergereicht, um die Backups von diesen per LAN/WLAN auf den Rechner zu schicken.

Als zweite Ebene soll das ganze dann später auf einen zweiten Rechner "in der cloud" erfolgen. Aber vom backuprechner weg.

Ev. wäre sogar der Weg mit der zwischenspeicherung sogar der bessere... Dann kann das zoelsystem nach erfolgreicher übertragung ein differentialfile nach dem anderen einlesen...

Lesenden zugriff auf dateisystemebe e brauch ich am zielsystem trotzdem, um die notwendigen infos zu bekommen, was vorhanden ist, und was nicht...

Ich glaub, mir erscheint gerade die lösung vor dem geistigen auge.

Lg scientific
dann putze ich hier mal nur...

Eine Auswahl meiner Skripte und systemd-units.
https://github.com/xundeenergie

auch als Debian-Repo für Testing einbindbar:
deb http://debian.xundeenergie.at/xundeenergie testing main

Antworten