Wie Backup am besten durchführen?

[MisterY]

Hi,

folgendes Szenario: Ich habe einen Homeserver mit OMV 2.1. Mein Bruder auch.
Nun möchten wir uns gegenseitig ~100GB Backupspeicher zur Verfügung stellen. Mit rsync kriege ich die Daten ja recht gut auf seinen Server und er auf meinen. Jedoch wie kann man das machen, dass weder er in meine noch ich in seine Dateien gucken kann? Ein verschlüsselter Container ist nicht möglich, da jedesmal 100GB übers Internet zu schieben Tage braucht. Ich habe schon an Rechteverwaltung gedacht, wo jeder User sich sein PW selbst aussuchen kann, jedoch kann ich als Admin natürlich immernoch dadrauf gucken. Habt ihr da ne Idee?

 

[underclocker2k4]

Wie wäre es ohne Adminrechte?

 

[sno0k]

Ein verschlüsselter Container wäre möglich. Da würde mir dann BitTorrent Sync einfallen. Das aktualisiert bei der Berarbeitung der Datei nur den geänderten Teil, anstatt die gesamte Datei neu zu übertragen. Das würde zumindest das Problem mit der nicht funktionierenden Rechteverwaltung bei Adminrechten vorbeugen. BTSync bietet außerdem noch die Möglichkeit Read-Only Rechte zu vergeben, sodass Änderung z. B. nur von deiner Seite aus übernommen werden.

Als Alternative und open source wäre da noch syncthing. Da bin ich mir aber nicht ganz sicher, ob aktualisierte Dateien wie bei BTSync behandelt werden. Müsste man nochmal im Detail nachlesen.

Edit: kurz Google befragt. Ist wohl mit Einschränkungen möglich.

• append something -> only appended parts are transfered
• replace something in the middle with something else that has the same length -> only changed part transfered
• adding/deleting parts in the middle -> everything after the changed part transfered because all blocks after this will be different (probably also only the changes are transfered if exactly one block (128 KiB) of the file is added/removed, but I think it's unlikely that this will happen)

As Far as I understand the current model, it works efficiently only in some specific cases:

• Data is appended at the end of a file
• An exact multiple of 128 kiB is added anywhere in the file (start/middle)
• Data is being replaced by different data with exactly the same size anywhere in the file
• An exact multiple of 128 kiB is deleted from anywhere in the file

In all these cases, this would cause only very few blocks to be transmitted.

 

[jdcr]

Oder du nimmst die manuelle Methode (die sich natürlich auch scripten lässt): Du erstellst inkrementelle Backups, verschlüsselst (und evtl. komprimierst) die und lädst sie hoch. Meines Wissens kann tar inkrementelle Archive erstellen, in denen nur die Dateien drin sind, die sich im Vergleich zu einem schon existierenden Archiv verändert haben.

Nachteil wäre, dass du die Backups auch lokal bei dir vorhalten musst (falls du das nicht ohnehin tust). Vorteil wäre, dass du nur Bordmittel brauchst und keine externe Software.

 

[rayze]

Wie gut das ganze läuft kann ich natürlich nicht sagen aber eine Idee wäre es vielleicht (von deiner Seite aus gesehen):

- cryptsetup Container auf der Box deines Bruders
- via NFS Client den Ordner des cryptsetup Containers bei dir im System einhängen und öffnen (Schlüssel ist nur dir bekannt)
- Dateien innerhalb des Containers mit rsync tauschen
- Container schließen und die NFS Freigabe aushängen

Wie gesagt, wie gut/schnell sich ein cryptsetup container übers Netz mounten lässt kann ich dir nicht sagen und auch nicht wie anfällig eher gegen Disconnects oder ähnliches ist oder ob der Container plötzlich corrupt werden würde in einem solchen Fall.

 

[MisterY]

@underclocker: wenn ich auf meinem Server keine Adminrechte hab, ist das irgendwie....doof

@snook: bei einem Container aber müsste doch der gesamte Inhalt gelesen werden? Wollte das eigentlich automatisch über OMV laufen lassen. Wenn nur read-only vorliegt - wer kann denn da was drauf schreiben? BTsync gibt es sogar als Paket in OMV. Aber wie man da einen Container erstellen kann, weiß ich nicht?

@jdcr: tar ist natürlich eine interessante Methode. Die Backups liegen aber nicht als Archiv vor und sooo viel Speicherplatz habe ich jetzt auch nicht über, dass ich die Normal + Getared haben kann.

@rayze: cryptsetup/LUKS kann in OMV wohl nur die gesamte HDD verschlüsseln.

Die Daten liegen auf meinem Server. Das Backup soll automatisch durchgeführt werden (mitten in der Nacht) und ich will das nicht über einen weiteren Rechner laufen lassen. Es muss also mit OMV Boardmitteln gehen.

 

[sno0k]

Das mit dem verschlüsselten Container war nur auf deine Aussage bezogen, dass jedesmal der ganz Container übertragen werden muss und dein Bruder dann zumindest nicht in deine Daten gucken kann.
Du kannst in den Ordner schreiben und der Server von deinem Bruder hat nur read-only. So meinte ich das. Falls ihr beide getrennte Ordner für eure Backups benutzt. Bei dem Ordner deines Bruders wäre es dann genau andersrum.
Das Plugin in OMV ist stark veraltet (v1.4). Vllt wird es mit der neuen Version aktualisiert. Zumindest wurde im Forum schon nachgefragt. Ich nutze derzeit BTSync als Docker Image. Mit der neusten Version 2.3 gibt es jetzt auch verschlüsselte Ordner. Habe ich allerdings noch nicht getestet, in wie weit die Daten auf der gegenüberliegenden Seite abgespeichert werden.

Ansonsten fällt mir im Moment keine "unkompliziert" Lösung ein, um das Rechteproblem zu umgehen. Als root kann man ja quasi alles umgehen, außer verschlüsselte Archive oder Container.

 

[MisterY]

Okay, Docker und dann BTSync 2.3 wäre natürlich eine Überlegung wert. Habe bisher 0 Erfahrung mit beiden, werden wir mal sehen

 

[jdcr]

@jdcr: tar ist natürlich eine interessante Methode. Die Backups liegen aber nicht als Archiv vor und sooo viel Speicherplatz habe ich jetzt auch nicht über, dass ich die Normal + Getared haben kann.

Hm, vielleicht solltest du mal die tar-Doku genauer anschauen. Ich bin mir nicht sicher, ob du wirklich das alte Archiv brauchst oder ob in dieser .snar-Datei vielleicht schon alles Nötige drinsteht.

Abgesehen davon verstehe ich nicht ganz wie dein Plan ist. Normalerweise macht man doch lokale Backups und dann zusätzlich externe. Zusätzlichen Platz brauchst du ja sowieso, allein schon weil du die Daten wohl kaum unkomprimiert über die Internetleitung schicken willst.

 

[sweetchuck]

Das hier könnte die Lösung sein:

duplicity: Main

Zumindest auf dem Papier - ich hab die Software noch nicht ausprobiert und auch keine Erfahrungsberichte. Auch weiß ich nicht, ob das mit OMV läuft.

 

[psw]

Hallo MisterY,

eine Lösung, der ich nachgehe ist zpaq:
Das Initialbackup erzeugt eine Indexdatei, die bei allen Folgebackups als Referenz genommen wird:

zpaq a /home/bckp/myBackup_part? /myFiles

// "part?" ist Platzhalter für die nächste Version und muss auch so mit dem Fragezeichen als Ziel angegeben sein. In der Indexdatei weiss der Packer, welche Nummer folgt

zpaq legt ähnlich zu tar ein Archiv an, dass mittels Schalter auch unterschiedlich stark komprimiert (-m0: keine Kompression, nur Deduplication; -m1 - -m5: verschiedene Kombinationen von Kompressionen; mit steigender Zahl steigender CPU-Bedarf). Hierbei werden aber auch bereits gespeicherte Fragmente nur referenziert und nicht neu ins Archiv geschrieben...
Die resultierenden Dateien
myBackup_part0 <- diese muss lokal weiter vorliegen, damit inkrementelle Backups machen kannst
myBackup_part1
Als Ergebnis hast Du also pro Backupvorgang ein File... Gelöschte Dateien werden im Backup nur als gelöscht markiert bis sie mit dem Schlater "-purge" aufgeräumt werden. (quasi ein neues Initialbackup aus allen Archiven)

Diese kannst Du dann remote ablegen... vor Ort brauchst Du dann nur das wenige hundert MB grosse (bei mir zumindest, und das bei derzeit etwa 3TB Sourcegrösse) Indexfile. In diesem sind die Hashwerte der bereits gespeicherten Fragmente abgelegt als auch eine Filelist. Bei jedem inkrementellen Backup lädst Du dann das neu erzeugte myBackup_partX auf den remote server hoch und löscht es lokal...

Die Wiederherstellung klappt natürlich nur wenn alle Archive sich im selben Verzeichnis befinden und kein Zwischenarchiv fehlt...
Ich persönlich bevorzuge die 6.6 Version, da diese in der Summary (zpaq l myBackupFile -sum) auch den Grad der Deduplizierung mit angibt... In den nachfolgenden wurde das aus dem Code leider wieder rausgenommen...

Deine Anforderung an Sicherheit: Das Archiv lässt sich natürlich mit einem PW versehen und ist AES-256 dann verschlüsselt.

"
zpaq v7.05 journaling archiver, compiled Apr 17 2015
zpaq archiver for incremental backups with rollback capability.
http://mattmahoney.net/zpaq
"