Verschlüsselter Backupserver und verschlüsseltes Zweitbackup auf externer Festplatte

[genghis]

Hallo,

neben mir läuft im Probebetrieb eine DS214+, meine erste NAS.

Die Tipps für die Erst- und Neuinstallation habe ich eben zustimmend gelesen. In dem Sinne hatte ich zuvor schon begonnen und auch Daten (Spieldaten und Konfiguration) verloren (Fußnote 1).

Ich finde attraktiv, was mit der DS alle möglich scheint (von Mailserver bis theoretisch beliebige App-Pakte).

Der Einsatzzweck bei mir ist, jedenfalls bei dieser DS214+, ausschließlich der eines Datei- und Backupservers im LAN.

Bisher läuft Backup bei mir so:

Mein Desktoprechner läuft unter Linux und hat derzeit eine 3-TB Datenfestplatte, die mit dm-crypt verschlüsselt ist. Dateisystem EXT3 oderr EXT4.

Ferner verwende ich abwechselnd zwei externe 3-TB-Festplatten (USB), die ebenfalls mit dm-crypt verschlüsselt sind (Dateisystem EXT4), zum Backup. Falls mitten im Backup-Prozess die Quellplatte ausfällt und dadurch vielleicht die Daten der Backup-Festplatte mit Müll der defekten Quellplatte (bzw. des defekten Quellsystems) beschrieben wird, habe ich noch die zweite Backup-Festplatte. Von Zeit zu Zeit ersetze ich eine Backup-Festplatte durch eine neue und lagere die ausgetauschte, intakte Festplatte räumlich aus.

Derzeit sind 2,5TB an Daten in 447.296 Dateien oder Verzeichnissen zu sichern.

Die DS soll quasi eine der beiden USB-Backupplatten ersetzen. Die andere USB-Backupplatte soll am NAS hängen und von diesem das Zweitbackup erhalten.

Während ich den letzten Satz schreibe, kommt mir der Gedanke, dass ich die zweite externe Paltte vielleicht besser direkt an den zu sichernden Rechner anschließe anstatt an die DS. Dann erübrigt sich auch eine meiner Fragen, nämlich die, wie die DS214+ dazu gebracht werden kann, die Daten auf die externe USB-Festplatte verschlüsselt zu speichern, und zwar so, dass die externe USB-Festplatte später an einen beliebigen (Linux-)Rechner angeschlossen werden kann, welcher die Daten wiederherstellen kann.

Bisher wird zum Zweck des Backups die USB-Platte individuell gemountet und dann ein sh-Skript ausgeführt, dessen Kernbefehl der folgende ist:

rsync -rlptgoDv --stats --progress -h --delete -b --backup-dir=$loesch $quelle  $ziel | tee  -a $ziel/rsync$Datum.log

Auf der DS habe ich im Probebetrieb zwei Freigaben:

. 1) unverschlüsselt
. 2) verschlüsselt

Auf die CIFS-Freigabe unverschlüsselt erreichte eine 10-GiB-Kopie bei mir einen Datendurchsatz von 72 MB/s.
Auf die CIFS-Freigabe verschlüsselt erreichte eine 10-GiB-Kopie bei mir einen Datendurchsatz von 22 MB/s.

Das bedeutet: Das erstmalige Backup auf die DS benötigt verschlüsselt mindestens (Fußnote 2) 36 Stunden.

NFS ist an der DS nicht aktiv. Mit NFS habe ich keine Erfahrungen. Dauerhaft auf Linux gewechselt bin ich vor knapp 10 Jahren, aber mit NFS habe ich mich bisher nicht anfreunden können (Fußnote 3).
AFP habe ich an der DS deaktiviert. Das Protokoll ist im Praxisbetrieb immer wieder mit "kFPMiscErr" ausgestiegen.
CIFS setze ich seit vielen Jahren beruflich und privat in Windows- und in Linux-Umgebungen für Imaging-Verfahren über LAN ein, ohne jemals auf ein Problem (im Sinne Abbruch/Fehler) gestoßen zu sein.

Mit folgendem Befehl verbinde ich mich auf die DS:

mount -t cifs -o username=backup,uid=1000,gid=1000 //192.168.0.12/verschluesselt /mnt/verschluesselt

uid und gid (Nummer des Benutzers und dessen Gruppe des Quellsystems) waren nötig, damit rsync vom Quellsystem auf der DS z.B. das Kommando settimestemp (oder so ähnlich) absetzen kann.

Natürlich werde ich auch noch den rsync-Server der DS ausprobieren. rsync ohne rsync-Server setze ich ja schon lange wie oben beschrieben ein, sogar (mit Cygwin) unter Windows anstelle von Robocopy. Allerdings las ich eben, dass damit keine Verschlüsselung am Ziel möglich sei (http://www.synology-forum.de/showth...erschl%FCsseln&p=468945&viewfull=1#post468945).

Hat jemand von Euch eine ähnliche Situation bereits gelöst und Anregungen für mich?

Vielen Dank im Voraus und Gruß

Genghis

Fußnote 1:
Ich hatte eine Platte eingesetzt und das vorgeschlagene RAID gewählt. Später wollte ich die Platte entnehmen und zuvor ordentlich abmelden. Ich erhielt eine Warnung, dass alle Daten gelöscht würden. Dabei wollte ich die Platte nur mit Daten entnehmen, um sie vielleicht genauso später wieder einzusetzen. Aber OK, ich bestätigte die Datenlöschung (da es ja ohnehin nur Spieldaten waren) und entnahm die Platte. Da war dann zu meiner Überraschung auf die Konfiguration weg. Ich hatte erwartet, dass die Konfiguration in einer Art BIOS der DS214+ gespeichert würde.

Fußnote 2:
Den zugrundeliegenden Datendurchsatz hatte ich mit einer 11-GiB-Datei gemessen. Die hochzurechnenden 2,5 TB verteilen sich aber auf knapp eine halbe Million Dateien.

Fußnote 3:
Ich kann über Zuverlässigkeit oder Geschwindigkeit nichts sagen. Die Konfiguration war mir (rein subjektiv) wegen Nameserver und Rechtekonzept zu aufwendig. Die Alternative SAMBA/CIFS war für mich einfacher und funktioniert.

Zum Posting:

Stichworte ("Es ist Ihnen nicht erlaubt, neue Stichworte zu erstellen. Sie dürfen nur bestehende Stichworte verwenden."):

Verschlüsselung,Backup, externe usb platte, rsync

Konkret durfte ich rsync nicht als Stichwort eintragen.

 

[genghis]

Nachtrag:

Die Verschlüsselung von der DS214+ ist nur mit ecryptfs möglich. Das hat diverse Einschränkungen gegen über dm-crypt auf ext4. Eine davon ist die maximale Dateinamenlänge von nur 146 Zeichen bei ecryptfs. Eine weitere ist der Zeichensatz. Über tausend Dateien können deswegen aus meinem Datenbestand (u.a. viele Aufsätze und Gerichtsurteile, die Autor, Datum, Aktenzeichen und Thema mit Stichworten im Dateinamen enthalten) nicht gesichert werden. Das Backup hat außerdem 75 Stunden gedauert.

Ohne Verschlüsselung ist das alles kein Problem, der gleiche Datenbestand: Alle Dateien konnten gesichert werden. Das hat nur 16 Stunden gedauert.

Unverschlüsselte Backups sind einerseits nicht inakzeptabel. Andererseits sind verschlüsselte Backups auf der DS214+ nicht möglich, bzw. wegen der Einschränkungen nicht praktikabel.

Ausweg wäre, die zu sichernden Dateien nicht auf den Backupserver zu spiegeln, sondern auf dem Quellsystem zu verschlüsseln und verschlüsselt auf den unverschlüsselten Backupserver zu übertragen.

Dann müsste aber bei jedem Backup der gesamte Datenbestand neu gesichert werden.Oder eine Backupsoftware müsste die zu sichernden Dateien mit zu entschlüsselnden Dateien auf dem Backupserver abgleichen (wenn das überhaupt geht).

Vielleicht kann ich in eine gigantisch (derzeict bis zu 6 TB) große Archivdatei (ZIP, TAR, ...) auf der DS schreiben. Mal sehen ...

Gruß

Genghis

 

[dil88]

Der Gedanke mit der komprimierten Datei liegt nahe. Aber bedenke dabei, was passiert, wenn die Datei einen Defekt hat. Für ein Backup würde ich von einer solchen Konstruktion abraten.

 

[Merthos]

...was passiert, wenn die Datei einen Defekt hat...

Für solche Fälle gibt es so was wie par oder par2, welches man problemlos als zusätzlichen Schritt in einen Backup-Lauf einfügen kann.

 

[dil88]

Cooler Hinweis! *merk* Und mit einer par1-/par2-Datei würdest Du den Ansatz für genauso sicher halten wie ein Backup der Files direkt ins Filesystem?

 

[Merthos]

Prinzipiell schon, natürlich auch abhängig davon, wie viel Redundanz man bei par einstellt.

Persönlich verwende ich das für manuelle Backups in die Cloud zum Zweck der Archivierung (also kein schneller Zugriff nötig). Verschlüsseltes Archiv erstellen, mit par2 Redundanz hinzufügen und dabei auch gleich noch in handliche Stücke aufsplitten und das ganze dann hochladen.

 

[dil88]

Sehr schlaue Anwendung, vielen Dank für die Ausführung!

 

[Merthos]

Eine davon ist die maximale Dateinamenlänge von nur 146 Zeichen bei ecryptfs.

Wenn Du selber über die Konsole mountest, kann man das auch weglassen. Falls die Namen also nicht so relevant sind, wäre das vielleicht eine Option.

 

[genghis]

Wenn Du selber über die Konsole mountest, kann man das auch weglassen. Falls die Namen also nicht so relevant sind, wäre das vielleicht eine Option.

Das habe ich nicht verstanden. Was kann man zu welchem Zweck weglassen.

Die Namen sind relevant. Beispiele:

2012-05-15_BAG_Urteil_3_AZR_11-10_Abloesung einer Versorgungsordnung - Drei-Stufen-Schema - Anhebung der gesetzlichen Regelaltersgrenze - Umstellung laufender Rentenleistungen auf Kapitalleistung_.pdf

OLG Stuttgart Beschluss vom 13.12.2010, 15 UF 238_10 Versorgungsausgleich_ Berücksichtigung der Unterschiedlichkeit von Versorgungsbausteinen bei der betrieblichen Altersversorgung.html

/usr/share/ca-certificates/mozilla/TÜB?TAK_UEKAE_Kök_Sertifika_Hizmet_Sa?lay?c?s?_-_Sürüm_3.crt

93_http___m_faz_net__artikel_bereich_galerie_aktuell_technik_motor_umwelt_technik_gefuerchtete_krankheitserreger_lauwarm_ist_den_legionellen_am_liebsten_12724906_html.pdf

 

[Merthos]

Du kannst die Namensverschlüsselung weglassen, die das Problem mit der Länge verursacht. Das heißt, dass man die dann weiterhin lesen kann und nur der Inhalt verschlüsselt wird. Halt die Frage, ob Du die Namen auch zwingend "verstecken" möchtest / musst.

/usr/syno/sbin/mount.ecryptfs /PATH/@NAME@ /PATH/NAME -o ecryptfs_cipher=aes,ecryptfs_key_bytes=32,ecryptfs_passthrough=n,no_sig_cache,ecryptfs_enable_filename_crypto=n,passwd=PASSWORD

Bei "ecryptfs_enable_filename_crypto" kann man das mit "y" oder "n" steuern.

 

[genghis]

Dankeschön für die Anregungen und die hilfreiche Information.

Von par2 habe ich zuvor noch nie etwas gehört - vielleicht, weil ich seit 2 Jahrzehnten noch keinen Ärger mit großen Archiven oder Images hatte. Aber das Programm werde ich wahrscheinlich bei künftigen Image basierten Backups einsetzen. Auch auf die DS214+.

Gruß

Genghis