Snapshots fuer Datensicherung

[Alexander Goetzenstein]

Hallo,
für die Datenablage und -sicherung verwende ich Synology DiskStations
resp. RackStations. Dabei mache ich mittlerweile die Erfahrung, dass
inkrementelle Datensicherung über Gebühr lange dauert (derzeit 12h für
unter 1GB geänderter Daten), was vermutlich an der Größe der Daten
liegt, die überdies in Zukunft nicht kleiner wird. Daher denke ich
darüber nach, mit Snapshots zu arbeiten, auch weil ich aufgeschnappt
habe, dass eine gängige Lösung sei, nach einer initialen
Komplettsicherung nur noch die Snapshots zu sichern. Dazu habe ich
einige Fragen, die ich nicht beantwortet gefunden habe:

1.
Soweit ich verstehe, nutzt Synology für Snapshots das Dateisystem BTRFS.
Man kann aber bei der Einrichtung des NAS bspw. auch EXT4 wählen, was
keine Snapshots bietet, und ich fürchte, das habe ich seinerzeit getan
-genau weiß ich es aber nicht mehr. In der Oberfläche finde ich aber
keine Auskunft darüber. Schaue ich einfach nur falsch, oder muss ich
anders herangehen?

2.
Falls ich bei der Einrichtung EXT4 gewählt haben sollte: wie kann ich es
in BTRFS konvertieren?

3.
Laut Synology Knowledgebase sind maximal 256 Snapshots möglich. Das
reicht bei täglicher Nutzung nicht weit. Wie geht man damit um?

4. Die Fragen 2. und 3. stellen sich bei dem per iSCSI von einem
Linux-Server genutzten "Laufwerk", nur eben nicht mit
Synology-Werkzeugen, sondern von Linux aus.


Oder bin ich hier komplett auf dem Holzweg?


--
Gruß
Alex

[Marcel Mueller]

Am 12.05.23 um 13:01 schrieb Alexander Goetzenstein:

> für die Datenablage und -sicherung verwende ich Synology DiskStations
> resp. RackStations. Dabei mache ich mittlerweile die Erfahrung, dass
> inkrementelle Datensicherung über Gebühr lange dauert (derzeit 12h für
> unter 1GB geänderter Daten), was vermutlich an der Größe der Daten
> liegt, die überdies in Zukunft nicht kleiner wird.

Die Größe der Dateien _sollte_ bei einem inkrementellen Backup egal
sein. Normalerweise werden nur die Metadaten gewälzt, um zu entscheiden,
was gesichert werden soll. Das kann aber bei _sehr vielen_ Dateien und
konventionellen Festplatten auch schon erkleckliche Zeit dauern.

> Daher denke ich
> darüber nach, mit Snapshots zu arbeiten, auch weil ich aufgeschnappt
> habe, dass eine gängige Lösung sei, nach einer initialen
> Komplettsicherung nur noch die Snapshots zu sichern. Dazu habe ich
> einige Fragen, die ich nicht beantwortet gefunden habe:
>
> 1.
> Soweit ich verstehe, nutzt Synology für Snapshots das Dateisystem BTRFS.
> Man kann aber bei der Einrichtung des NAS bspw. auch EXT4 wählen, was
> keine Snapshots bietet, und ich fürchte, das habe ich seinerzeit getan
> -genau weiß ich es aber nicht mehr. In der Oberfläche finde ich aber
> keine Auskunft darüber. Schaue ich einfach nur falsch, oder muss ich
> anders herangehen?

Konnte man auf die Synologys nicht irgendwie per Konsole drauf? Das sind
doch Linux-Kisten. Die sollten bei Eingabe von "mount" neben allerlei
Kram auch die Dateisysteme der Datenträger anzeigen.

> 2.
> Falls ich bei der Einrichtung EXT4 gewählt haben sollte: wie kann ich es
> in BTRFS konvertieren?

Nein.
Löschen und neu bespielen heißt die Konvertierung.

> 3.
> Laut Synology Knowledgebase sind maximal 256 Snapshots möglich. Das
> reicht bei täglicher Nutzung nicht weit. Wie geht man damit um?

Wenn du einen Snap nicht mehr brauchst kann er weg. Das ist auch
wichtig, denn da Dateisystem müsste ja sonst auch alle Daten von damals
auf ewig speichern. Ein Snap ist logisch gesehen ein Vollbackup, nur
eben ohne anderen Datenträger, was entsprechend nur gegen einige
Fehlerszenarien schützt.

Üblicherweise kann der Snap direkt nach dem Backup wieder weg. Der dient
nur der Sicherung eines konsistenten Standes. Sichert man ohne Snap,
bekommt man ja Daten verschiedenen alters.
Verschiebe ich während des Backups eine Datei von einem Ordner, dessen
Backup noch nicht gelaufen ist in einen, der schon gesichert wurde,
fehlt die Datei vollständig im Backup. Lauft während des Backups eine
Softwareaktualisierung, liegen im Backup jetzt aktualisierte und nicht
aktualisierte Dateien wild durcheinander. Das Programm ist vielleicht
neu, die Libraries noch alt. Dann läuft nach dem Restore wenn man Pech
hat gar nichts mehr.
Genau da setzen die Snaps an. Die stellen zwar auch keine 100%
Datenkonsistenz sicher, denn Anwendungen haben ja Dateien geöffnet, aber
das Zeitfenster ist um Größenordnungen kleiner. Ein Snap ist wie ein
Stromausfall. Er spiegelt den aktuell persistierten Stand des Systems
wieder. Wenn er auf Dateisystemebene erfolgt ist er sogar noch etwas
besser, denn er berücksichtigt auch noch im Write-Back-Cache liegende Daten.

> 4. Die Fragen 2. und 3. stellen sich bei dem per iSCSI von einem
> Linux-Server genutzten "Laufwerk", nur eben nicht mit
> Synology-Werkzeugen, sondern von Linux aus.

iSCSI ist immer noch ein Disc-Device, nur dass es nicht lokal eingebaut
ist. Das ändert genau gar nichts.

> Oder bin ich hier komplett auf dem Holzweg?

Nein, aber mir drängt sich auch nicht auf, wie das dein Problem mit den
lahmen, inkrementellen Backups lösen sollte. Selbst wenn du den Snap vom
letzten Backup noch hättest, müsste man trotzdem alle Dateien checken,
um herauszufinden, welche neu gesichert werden müssen. Normalerweise
läuft das über die Metadaten, also nur das, was in den I-Nodes
(Directories) steht. Falls irgendwie Prüfsummen im Spiel sind, wären
natürlich auch andere Sicherungsverfahren denkbar, die auch die Daten
brauchen.


Marcel

[Alexander Goetzenstein]

Hallo,

Am 12.05.23 um 16:26 schrieb Marcel Mueller:

> Am 12.05.23 um 13:01 schrieb Alexander Goetzenstein:
>> für die Datenablage und -sicherung verwende ich Synology DiskStations
>> resp. RackStations. Dabei mache ich mittlerweile die Erfahrung, dass
>> inkrementelle Datensicherung über Gebühr lange dauert (derzeit 12h für
>> unter 1GB geänderter Daten), was vermutlich an der Größe der Daten
>> liegt, die überdies in Zukunft nicht kleiner wird.
>
> Die Größe der Dateien _sollte_ bei einem inkrementellen Backup egal
> sein. Normalerweise werden nur die Metadaten gewälzt, um zu entscheiden,
> was gesichert werden soll. Das kann aber bei _sehr vielen_ Dateien und
> konventionellen Festplatten auch schon erkleckliche Zeit dauern.

mir deucht, dass bei der Datensicherung die Quelldaten noch einmal
durchforstet werden, ob etwas neu zu sichern dabei ist. Das geht zwar um
Größenordnungen schneller (die erste Komplettsicherung hat >1.000h
gedauert), dauert aber für den täglichen Betrieb dennoch zu lange.
Effektiv nutzbare Betriebspause ist derzeit 6h täglich, die Sicherung
braucht das doppelte.

>> 1.
>> Soweit ich verstehe, nutzt Synology für Snapshots das Dateisystem BTRFS.
>> Man kann aber bei der Einrichtung des NAS bspw. auch EXT4 wählen, was
>> keine Snapshots bietet, und ich fürchte, das habe ich seinerzeit getan
>> -genau weiß ich es aber nicht mehr. In der Oberfläche finde ich aber
>> keine Auskunft darüber. Schaue ich einfach nur falsch, oder muss ich
>> anders herangehen?
>
> Konnte man auf die Synologys nicht irgendwie per Konsole drauf? Das sind
> doch Linux-Kisten. Die sollten bei Eingabe von "mount" neben allerlei
> Kram auch die Dateisysteme der Datenträger anzeigen.

Inzwischen habe ich ein Tool von Synology zum Nachinstallieren gefunden,
das diese Auskunft gibt. In einem NAS habe ich bereits BTRFS, in einem
anderen EXT4, und die Quelle (iSCSI) läuft auch unter EXT4. Das hört
sich nach Arbeit an...

>> 2.
>> Falls ich bei der Einrichtung EXT4 gewählt haben sollte: wie kann ich es
>> in BTRFS konvertieren?
>
> Nein.
> Löschen und neu bespielen heißt die Konvertierung.

Ich hab's befürchtet. Hätte ja sein können, dass es ein Tool für eine
Online-Konvertierung o.ä. gibt.

>> 3.
>> Laut Synology Knowledgebase sind maximal 256 Snapshots möglich. Das
>> reicht bei täglicher Nutzung nicht weit. Wie geht man damit um?
>
> Wenn du einen Snap nicht mehr brauchst kann er weg. Das ist auch
> wichtig, denn da Dateisystem müsste ja sonst auch alle Daten von damals
> auf ewig speichern. Ein Snap ist logisch gesehen ein Vollbackup, nur
> eben ohne anderen Datenträger, was entsprechend nur gegen einige
> Fehlerszenarien schützt.> Üblicherweise kann der Snap direkt nach dem Backup wieder weg.

"Weg" heißt, er wird sozusagen in den Snap #0 integriert, oder wie muss
ich mir das vorstellen?

> Genau da setzen die Snaps an. Die stellen zwar auch keine 100%
> Datenkonsistenz sicher, denn Anwendungen haben ja Dateien geöffnet, aber
> das Zeitfenster ist um Größenordnungen kleiner. Ein Snap ist wie ein
> Stromausfall. Er spiegelt den aktuell persistierten Stand des Systems
> wieder. Wenn er auf Dateisystemebene erfolgt ist er sogar noch etwas
> besser, denn er berücksichtigt auch noch im Write-Back-Cache liegende Daten.

BTW: wie werden dabei gelöschte Dateien gehandhabt? Enthält der Snap
dann so etwas wie einen negativen Dateieintrag, oder wie läuft das ab?

>> 4. Die Fragen 2. und 3. stellen sich bei dem per iSCSI von einem
>> Linux-Server genutzten "Laufwerk", nur eben nicht mit
>> Synology-Werkzeugen, sondern von Linux aus.
>
> iSCSI ist immer noch ein Disc-Device, nur dass es nicht lokal eingebaut
> ist. Das ändert genau gar nichts.

Eines schon: die Handhabung. Bei Synology habe ich das DSM mit seiner
Oberfläche und Tools, bei Linux dafür andere und vermutlich mehr und
ausgefeiltere. Oder umgekehrt. Da wären Hinweise auf die Tools, über die
ich mich belesen sollte, hilfreich. Bislang -man merkt es vermutlich-
bin ich in dem Thema noch ziemlich unbeleckt und suche den Überblick und
Anfang.

>> Oder bin ich hier komplett auf dem Holzweg?
>
> Nein, aber mir drängt sich auch nicht auf, wie das dein Problem mit den
> lahmen, inkrementellen Backups lösen sollte. Selbst wenn du den Snap vom
> letzten Backup noch hättest, müsste man trotzdem alle Dateien checken,
> um herauszufinden, welche neu gesichert werden müssen.

Meine Vorstellung wäre, dann eben jeweils nur den letzten Snap zu
sichern. Da das deutlich weniger Datenmenge ist, sollte das dann schnell
gehen. Bei einem Komplett-Restore könnte sich das zwar ins Gegenteil
verkehren, aber das ist mir persönlich noch nie vorgekommen, und
außerdem hat man dann wohl noch ganz andere Probleme und ist froh, es
überhaupt hinzubekommen... ;-)

> Normalerweise
> läuft das über die Metadaten, also nur das, was in den I-Nodes
> (Directories) steht. Falls irgendwie Prüfsummen im Spiel sind, wären
> natürlich auch andere Sicherungsverfahren denkbar, die auch die Daten
> brauchen.

Dazu müsste ich nochmal die Backup-Software näher beleuchten (auch die
setze ich erstmalig ein).


--
Gruß
Alex

[Marcel Mueller]

Am 12.05.23 um 17:52 schrieb Alexander Goetzenstein:

>> Die Größe der Dateien _sollte_ bei einem inkrementellen Backup egal
>> sein. Normalerweise werden nur die Metadaten gewälzt, um zu entscheiden,
>> was gesichert werden soll. Das kann aber bei _sehr vielen_ Dateien und
>> konventionellen Festplatten auch schon erkleckliche Zeit dauern.
>
> mir deucht, dass bei der Datensicherung die Quelldaten noch einmal
> durchforstet werden, ob etwas neu zu sichern dabei ist. Das geht zwar um
> Größenordnungen schneller (die erste Komplettsicherung hat >1.000h

Ach herrje. Ich würde sagen der Durchsatz des Backupverfahrens ist
schlicht der Datenmenge nicht gewachsen.

> gedauert), dauert aber für den täglichen Betrieb dennoch zu lange.
> Effektiv nutzbare Betriebspause ist derzeit 6h täglich, die Sicherung
> braucht das doppelte.

Für /dieses/ Problem können Snaps tatsächlich die Lösung sein. Aber wenn
es irgendwann 24h dauert, hilft das natürlich auch nicht mehr.

>>> 2.
>>> Falls ich bei der Einrichtung EXT4 gewählt haben sollte: wie kann ich es
>>> in BTRFS konvertieren?
>>
>> Nein.
>> Löschen und neu bespielen heißt die Konvertierung.
>
> Ich hab's befürchtet. Hätte ja sein können, dass es ein Tool für eine
> Online-Konvertierung o.ä. gibt.

Nicht wirklich. Die Dateisysteme verwenden komplett unterschiedliche
Datenstrukturen auf dem Datenträger.
Nur für sehr ähnliche Systeme wie ext2/3/4 gab es das. Aber selbst da
war das Ergebnis suboptimal, vor allem weil ext2/3 keine brauchbaren
Datenstrukturen für die Speicherung sehr großer Dateien hatten.

>>> 3.
>>> Laut Synology Knowledgebase sind maximal 256 Snapshots möglich. Das
>>> reicht bei täglicher Nutzung nicht weit. Wie geht man damit um?
>>
>> Wenn du einen Snap nicht mehr brauchst kann er weg. Das ist auch
>> wichtig, denn da Dateisystem müsste ja sonst auch alle Daten von damals
>> auf ewig speichern. Ein Snap ist logisch gesehen ein Vollbackup, nur
>> eben ohne anderen Datenträger, was entsprechend nur gegen einige
>> Fehlerszenarien schützt.> Üblicherweise kann der Snap direkt nach dem Backup wieder weg.
>
> "Weg" heißt, er wird sozusagen in den Snap #0 integriert, oder wie muss
> ich mir das vorstellen?

Nein, der wird einfach gelöscht.
Das sind keine Block-Device Snaps wie bei VMs. Ein Snap ist in erster
Näherung ein Reflink auf das Root-Verzeichnis und alles darunter. Und
jede nachfolgende Änderung triggert CopyOnWrite, die geänderten Daten
einschließlich Verzeichniseinträgen werden also einfach an eine andere
Stelle auf dem Datenträger geschrieben. Primär wird also die Freigabe
der im Haupt-Volume nicht mehr benötigten Blöcke verhindert. Das löschen
des Snaps gibt die Bereiche dann wieder frei, sofern sie nicht noch von
einem anderen Snap oder im Haupt-Volume gebraucht werden.

>> Genau da setzen die Snaps an. Die stellen zwar auch keine 100%
>> Datenkonsistenz sicher, denn Anwendungen haben ja Dateien geöffnet, aber
>> das Zeitfenster ist um Größenordnungen kleiner. Ein Snap ist wie ein
>> Stromausfall. Er spiegelt den aktuell persistierten Stand des Systems
>> wieder. Wenn er auf Dateisystemebene erfolgt ist er sogar noch etwas
>> besser, denn er berücksichtigt auch noch im Write-Back-Cache liegende Daten.
>
> BTW: wie werden dabei gelöschte Dateien gehandhabt? Enthält der Snap
> dann so etwas wie einen negativen Dateieintrag, oder wie läuft das ab?

Nein, der Snap enthält das alte Verzeichnis, wo die Datei noch
existiert. Es gibt kein diff. Eigentlich ist es nur die
Weiterentwicklung von RefLinks auf Verzeichnisebene.

>>> 4. Die Fragen 2. und 3. stellen sich bei dem per iSCSI von einem
>>> Linux-Server genutzten "Laufwerk", nur eben nicht mit
>>> Synology-Werkzeugen, sondern von Linux aus.
>>
>> iSCSI ist immer noch ein Disc-Device, nur dass es nicht lokal eingebaut
>> ist. Das ändert genau gar nichts.
>
> Eines schon: die Handhabung. Bei Synology habe ich das DSM mit seiner
> Oberfläche und Tools, bei Linux dafür andere und vermutlich mehr und
> ausgefeiltere.

Andres OS, andere Tools. Das war schon immer so. Mit iSCSI hat das nicht
wirklich etwas zu tun.

> Oder umgekehrt. Da wären Hinweise auf die Tools, über die
> ich mich belesen sollte, hilfreich. Bislang -man merkt es vermutlich-
> bin ich in dem Thema noch ziemlich unbeleckt und suche den Überblick und
> Anfang.

iSCSI ist vor allem eines: riskant. Wenn das Netzwerk nur einmal hustet,
entstehen Fehler die mit einem Festplattenausfall vergleichbar sind. Die
können kaum sinnvoll behandelt werden. Und von diesen Fehlern ist es
nicht sonderlich weit zur Kernel-Panic, zumindest wenn wichtige Sachen
wie swap darauf liegen. Die Profis haben deshalb üblicherweise eine
komplett unabhängige Netzwerkinfrastruktur für Storage.

In der Amateur-Klasse würde ich immer versuchen, alle Dateisysteme lokal
zu halten und auf die Daten über höhere Protokollebenen wie NFS oder
Samba zuzugreifen.

>>> Oder bin ich hier komplett auf dem Holzweg?
>>
>> Nein, aber mir drängt sich auch nicht auf, wie das dein Problem mit den
>> lahmen, inkrementellen Backups lösen sollte. Selbst wenn du den Snap vom
>> letzten Backup noch hättest, müsste man trotzdem alle Dateien checken,
>> um herauszufinden, welche neu gesichert werden müssen.
>
> Meine Vorstellung wäre, dann eben jeweils nur den letzten Snap zu
> sichern. Da das deutlich weniger Datenmenge ist, sollte das dann schnell
> gehen.

Der Snap ist exakt so groß wie dein zu sicherndes Volume zum Zeitpunkt
des Snaps. Physikalisch belegt er nur deshalb weniger Platz auf dem
Datenträger, weil er sich viele, unveränderte Blöcke mit dem Hauptvolume
teilt.

Die Sicherung nur der veränderten Daten macht ja bereits das
inkrementelle Backup. Nur wenn ein Vollbackup 1½ Monate dauert, ist es
kaum verwunderlich, dass auch die täglichen Änderungen mal einen halben
Tag brauchen. Du brauchst einfach mehr Durchsatz.
Bei meinem Heimserver (der auch Fileserver ist) braucht ein Vollbackup
eher so 4 Stunden. Das ist handhabbar. Ich ziehe die Daten allerdings
auch noch auf eine alte Ultrium-Tape-Library und habe nicht so viele Tera.

> Bei einem Komplett-Restore könnte sich das zwar ins Gegenteil
> verkehren, aber das ist mir persönlich noch nie vorgekommen, und
> außerdem hat man dann wohl noch ganz andere Probleme und ist froh, es
> überhaupt hinzubekommen... ;-)

Noch nie getestet? Dann funktioniert es erfahrungsgemäß auch nicht, weil
irgendeine Kleinigkeit, die aber essentiell ist, fehlt.


Marcel

[Ulli Horlacher]

Marcel Mueller <news.5...@spamgourmet.org> wrote:

>>>> Falls ich bei der Einrichtung EXT4 gewählt haben sollte: wie kann ich es
>>>> in BTRFS konvertieren?
>>>
>>> Nein.
>>> Löschen und neu bespielen heißt die Konvertierung.
>>
>> Ich hab's befürchtet. Hätte ja sein können, dass es ein Tool für eine
>> Online-Konvertierung o.ä. gibt.
>
> Nicht wirklich.

Kann denn keiner von euch eine Suchmaschine bedienen?

Latuernich gibts das:

root@juhu:~# type btrfs-convert
btrfs-convert is /bin/btrfs-convert

root@juhu:~# dpkg -S btrfs-convert
btrfs-progs: /bin/btrfs-convert

root@juhu:~# btrfs-convert --help
btrfs-convert from btrfs-progs v5.16.2

usage: btrfs-convert [options] device
options:
-d|--no-datasum disable data checksum, sets NODATASUM
-i|--no-xattr ignore xattrs and ACLs
-n|--no-inline disable inlining of small files to metadata
--csum TYPE
--checksum TYPE checksum algorithm to use (default: crc32c)
-N|--nodesize SIZE set filesystem metadata nodesize
-r|--rollback roll back to the original filesystem
-l|--label LABEL set filesystem label
-L|--copy-label use label from converted filesystem
--uuid SPEC new, copy or user-defined conforming UUID
-p|--progress show converting progress (default)
-O|--features LIST comma separated list of filesystem features
--no-progress show only overview, not the detailed progress

Supported filesystems:
ext2/3/4: yes



--
Ullrich Horlacher Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart E-Mail: horl...@tik.uni-stuttgart.de
Allmandring 30a Tel: ++49-711-68565868
70569 Stuttgart (Germany) WWW: https://www.tik.uni-stuttgart.de/

[Alexander Goetzenstein]

Hallo,

Am 13.05.23 um 08:59 schrieb Marcel Mueller:

>> mir deucht, dass bei der Datensicherung die Quelldaten noch einmal
>> durchforstet werden, ob etwas neu zu sichern dabei ist. Das geht zwar um
>> Größenordnungen schneller (die erste Komplettsicherung hat >1.000h
>
> Ach herrje. Ich würde sagen der Durchsatz des Backupverfahrens ist
> schlicht der Datenmenge nicht gewachsen.

es ist schon das beste, was wirtschaftlich durchsetzbar war. Mehr war
einfach nicht drin.

>> gedauert), dauert aber für den täglichen Betrieb dennoch zu lange.
>> Effektiv nutzbare Betriebspause ist derzeit 6h täglich, die Sicherung
>> braucht das doppelte.
>
> Für /dieses/ Problem können Snaps tatsächlich die Lösung sein. Aber wenn
> es irgendwann 24h dauert, hilft das natürlich auch nicht mehr.

Dann müsste ich mir wirklich etwas neues einfallen lassen. Aber erst
einmal müsste es hinzubekommen sein, dass die maximal ein paar GB pro
Tag anfallenden neuen Daten in passender Zeit zu sichern sind. So könnte
ich noch mit der Kompression spielen, aber Größenordnungen erwarte ich
da nicht.

>>>> 3.
>>>> Laut Synology Knowledgebase sind maximal 256 Snapshots möglich. Das
>>>> reicht bei täglicher Nutzung nicht weit. Wie geht man damit um?
>>>
>>> Wenn du einen Snap nicht mehr brauchst kann er weg. Das ist auch
>>> wichtig, denn da Dateisystem müsste ja sonst auch alle Daten von damals
>>> auf ewig speichern. Ein Snap ist logisch gesehen ein Vollbackup, nur
>>> eben ohne anderen Datenträger, was entsprechend nur gegen einige
>>> Fehlerszenarien schützt.> Üblicherweise kann der Snap direkt nach dem Backup wieder weg.
>>
>> "Weg" heißt, er wird sozusagen in den Snap #0 integriert, oder wie muss
>> ich mir das vorstellen?
>
> Nein, der wird einfach gelöscht.

Das heißt dann:
1. komplettes Backup
2. Snapshot erstellen
3. arbeiten, neue Daten produzieren
4. Backup des Snapshots
5. Snapshot löschen
6. zurück zu 2.

Soweit richtig?

Falls ja: Wie sähe dann das Restore aus: Hauptdaten aus 1. zzgl.
"tausender" Snapshots? Und dann wie weiter?

Die Versionsverwaltung des Backupprogramms wäre dann vermutlich hinfällig.

> Andres OS, andere Tools. Das war schon immer so. Mit iSCSI hat das nicht
> wirklich etwas zu tun.

Die Erwähnung von iSCSI sollte nur darauf hinweisen, dass der Speicher
von einem anderen OS verwaltet wird, nämlich Linux statt Synologys DSM.

> iSCSI ist vor allem eines: riskant. Wenn das Netzwerk nur einmal hustet,
> entstehen Fehler die mit einem Festplattenausfall vergleichbar sind.

Das habe ich auch schon einmal festgestellt, als ich versehentlich das
Netzwerkinterface abgeschaltet hatte... :-\

> Die Profis haben deshalb üblicherweise eine
> komplett unabhängige Netzwerkinfrastruktur für Storage.

Na, dann bin ich ja gewissermaßen Profi: zwischen der Pizzabox (Server)
und dem Plattenstapel besteht nur eine exklusive 10GE-Verbindung ohne
ein Gerät dazwischen. ;-)

> In der Amateur-Klasse würde ich immer versuchen, alle Dateisysteme lokal
> zu halten und auf die Daten über höhere Protokollebenen wie NFS oder
> Samba zuzugreifen.

Mit dem Nightmare File System habe ich schon früher einmal Erfahrungen
gemacht, die ich ungern wiederholen möchte, und SMB will ich gar nicht
erst einführen, weil das hier sonst niemand braucht. Außerdem wüsste ich
nicht, wie das mit dem eingesessenen LUKS funktioniert... Ich denke auch
nicht, dass es daran scheitern sollte.

>> Meine Vorstellung wäre, dann eben jeweils nur den letzten Snap zu
>> sichern. Da das deutlich weniger Datenmenge ist, sollte das dann schnell
>> gehen.
>
> Der Snap ist exakt so groß wie dein zu sicherndes Volume zum Zeitpunkt
> des Snaps. Physikalisch belegt er nur deshalb weniger Platz auf dem
> Datenträger, weil er sich viele, unveränderte Blöcke mit dem Hauptvolume
> teilt.

Das heißt, für die Datensicherung mit Snaps zu arbeiten, würde nur wenig
bringen?

> Die Sicherung nur der veränderten Daten macht ja bereits das
> inkrementelle Backup. Nur wenn ein Vollbackup 1½ Monate dauert, ist es
> kaum verwunderlich, dass auch die täglichen Änderungen mal einen halben
> Tag brauchen. Du brauchst einfach mehr Durchsatz.

Vermutlich hat es auch nur deshalb so lange gedauert, weil eben täglich
nur 6 Stunden zur Verfügung stehen und die Datensicherung dann
unterbrochen werden musste. Fertiggeworden ist es vielleicht überhaupt
nur, weil ich in einer Woche fast durchgehend sichern konnte. Deshalb
ist meine Idee, nur die Daten von dem Programm sichern zu lassen, die
auch wirklich geändert bzw. neu hinzugekommen sind. Das wären dann
höchstens ein paar GB (die Clients brauchen alle zusammen keine 5
Minuten via rsync über WLAN), aber nicht dutzende TB, die offenbar
jedesmal auf Sicherungsbedarf geprüft werden müssen. Aber mir schwant,
dass das mit Snapshots so nicht hinzukriegen ist.

> Noch nie getestet? Dann funktioniert es erfahrungsgemäß auch nicht, weil
> irgendeine Kleinigkeit, die aber essentiell ist, fehlt.

Dochdoch, das kommt schon noch. Aber erst einmal muss ich eine Methode
gefunden haben, das überhaupt richtig sichern zu können. Mit der ersten
Sicherung bin ich ja gerade eben erst durch und stelle fest, dass das so
noch nicht funktioniert.



--
Gruß
Alex