mainstoreBackup - Support: sr #108653, storeBackup Verschlüsselung

 
 

sr #108653: storeBackup Verschlüsselung

Submitter:  None
Submitted:  Thu 18 Sep 2014 08:31:39 AM UTC
   
 
Category:  None Priority:  5 - Normal
Severity:  3 - Normal Status:  Done
Privacy:  Public Assigned to:  None
Originator Email:  -email is unavailable- Open/Closed:  Open
Operating System:  GNU/Linux
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 09 Dec 2014 08:00:28 PM UTC, comment #17: 

Nach Telefonat Fehler durch verwenden der aktuellen Version (3.5) behoben.

Heinz-Josef Claes <hjclaes>
Group administrator
Fri 28 Nov 2014 10:03:06 PM UTC, comment #16: 

Hallo Henning,

bei Dir muss irgendetwas schief laufen, aber ich kann den Fehler nicht nachvollziehen.

Daher die Frage, ob Du ein kleines Beispiel erzeugen kannst, bei dem das Problem auftritt. Das könnten z.B. die source-Daten (Mülldaten) in einem kleinen tar-File sowie die Kommandos, die Du darauf loslässt sein. Das Ganze könntest Du mit dann per email schicken.

Viele Grüße,
Heinz-Josef



Heinz-Josef Claes <hjclaes>
Group administrator
Tue 25 Nov 2014 08:04:51 AM UTC, comment #15: 

Hallo H-J,

>Ist das mit einem einfachen Beispiel reproduzierbar?


Was meinst du damit? Mit Hilfer der Autorepair Funktion funktioniert es. Die Fehlermeldung kommt aber weiterhin.

Viele Grüße
Henning

Anonymous
Sun 23 Nov 2014 06:28:28 PM UTC, comment #14: 

Hallo Henning,

hatte leider ein bisschen viel zu tun ...

> Wie oft empfiehlt es sich storeBackupCheckBackup einzusetzen? Nach jedem UpdateBackup?


Im Prinzip ist das egal. Ich mache es immer Nachts per cron.



> Das erwähnt Backup ist die erste Sicherung die ich auch schon mit der Option lateLinks angelegt habe. Laut Doku ist das wohl auch ok.


Ist das mit einem einfachen Beispiel reproduzierbar?
Kannst Du es mit der Option --autorepair korrigieren?

Grüße, Heinz-Josef

Heinz-Josef Claes <hjclaes>
Group administrator
Tue 18 Nov 2014 03:48:18 PM UTC, comment #13: 

Habe nun 2 Backups zum testen erstellt und auf beide UpdateBackup) laufen lassen. Beim zweiten erhalte ich dann eine Fehlermeldung:

ERROR     2014.11.18 16:45:28  4013     1 directory </...../2014.11.18_14.43.24> has no linkFrom entry

Das erwähnt Backup ist die erste Sicherung die ich auch schon mit der Option lateLinks angelegt habe. Laut Doku ist das wohl auch ok.

Anonymous
Tue 18 Nov 2014 01:48:41 PM UTC, comment #12: 


>Hallo Henning,


eventuell liegt eventuell ein Missverständnis vor.

Wenn Du mit lateLinks ein "inkrementelles" Backup erzeugst, werden (von hier irrelevanten Details mal abgesehen) die neuen Datein in das Backup kopiert / komprimiert.

Wenn Du danach storeBackupUpdateBackup laufen lässt, werden nur noch Hardlinks erzeugt, und die verbrauchen so gut wie keinen Plattenplatz.

Wenn Du direkt ein vollständiges (= full) Backup (ohne Option lateLinks) erstellst, passiert natürlich dasselbe - neue Dateien kommen ins Backup und für Dateien mit schon vorhandenem Inhalt (Deduplikation) wird nur ein Hardlinks angelegt.

Bei "blocked"-files passiert das auf Block-Ebene.

War da ein Missverständnis ohne war das klar? <

Das war ein Misverständnis! Wenn das so ist, sollte das ja gar kein Problem sein. Es ging eher um den Speicherplatz. Dann werde ich nach jedem Backup mit lateLinks einfach das storeBackupUpdate laufen lassen. Um das löschen alter Backups kümmert sich storeBackup ja dann auch.
Wie oft empfiehlt es sich storeBackupCheckBackup einzusetzen? Nach jedem UpdateBackup?

Bastellösungen sind beim Backuo eher kontraproduktiv.

Anonymous
Tue 18 Nov 2014 09:26:42 AM UTC, comment #11: 

Hallo Henning,

eventuell liegt eventuell ein Missverständnis vor.

Wenn Du mit lateLinks ein "inkrementelles" Backup erzeugst, werden (von hier irrelevanten Details mal abgesehen) die neuen Datein in das Backup kopiert / komprimiert.

Wenn Du danach storeBackupUpdateBackup laufen lässt, werden nur noch Hardlinks erzeugt, und die verbrauchen so gut wie keinen Plattenplatz.

Wenn Du direkt ein vollständiges (= full) Backup (ohne Option lateLinks) erstellst, passiert natürlich dasselbe - neue Dateien kommen ins Backup und für Dateien mit schon vorhandenem Inhalt (Deduplikation) wird nur ein Hardlinks angelegt.

Bei "blocked"-files passiert das auf Block-Ebene.

War da ein Missverständnis ohne war das klar?

----------------------------------------------

Bei meiner vorher für Dich avisierten Lösung (deren Anfrage ggf. auf ein Missverständnis basiert), meine ich natürlich auch die Verlinkung gegen alte Backups (also da das einen Monat alte).

-----

Ein neues Full Backup musst Du nicht ziehen, da Du die Korrektheit eines Backups (z.B. gegen Bitfehler der Platte) mittels storeBackupCheckBackup überprüfen kannst (und ggf. rechtzeitig reagieren kannst). Wenn Du den Fehler aber korrigieren können willst, solltest Du ein zweites Backup oder eine Replikation haben. (StoreBackupCheckSource kannst Du in dem Kontext "Bitfehler" zusätzlich noch verwenden.




Nur eine neue Serie anzufangen, bringt nichts, da die neue Series automatisch gegen das letzte Backup der anderen Serien verlinkt. Und das wäre in dem Szenario ein unvollständiges Backup (ohne Hardlinks).
Du musst also trotzdem "basteln".

--------

In der Doku gibt es übrigens ein Kapitel über Hardlinks, falls das unklar war / ist.

Viele Grüße,
Heinz-Josef

Heinz-Josef Claes <hjclaes>
Group administrator
Tue 18 Nov 2014 07:39:58 AM UTC, comment #10: 

Hallo Heinz-josef,

vielen Dank für deine Antwort. Nur noch einmal um das klar zu stellen: Angedacht ist es so, dass ich wirklich den vollen Speicherplatz des Backups verbrauche? D.h Backup 500 GB, bei täglichem Backup 15 TB? Entschuldige, aber so viel Speicher kann ich für ein Backup leider nicht entbehren.

Alternativ könnte man doch bestimmt (so wie du es glaube ich vorgeschlagen hast), alle 30 Tage ein neues Full Backup ziehen und anschließend die nächsten 29 Tage nur inkrementelle, sprich storeBackupUpdate nur im Bedarfsfall (der Wiederherstellung) ausführen.

Dafür müsste ich dann jedes Mal nach 30 Tagen eine neue Serie anlegen, geht das mit einer Variablen in der Konfig?

Die E-Mail Benachrichtigung werde ich mir dann mit Linux Bordmittel zusammen bauen. Danke!

Viele Grüße
Henning

Anonymous
Mon 17 Nov 2014 08:08:48 AM UTC, comment #9: 


> Ich benutze die Option lateLinks um nur eine inkrementelleSicherung übertragen zu müssen. Nun wird beim storeBackupUpdate jedes mal ein volles Backup generiert.


Die Idee von storeBackup ist es, immer Full-Backups zu haben. Hierdurch ergeben sich einige Vorteile, insbesondere durch die Möglichkeit, Backups "beliebig" löschen zu können. Mit lateLinks wird die Erstellung eines Full-Backups nur hinausgezögert, nicht aber überflüssig.
Wenn Du wirklich den Lauf von storeBackupUpdateBackup.pl vermeiden willst, ist die einzige effiziente Möglichkeit, die mir spontan einfällt, nach einem Monat eine neue Sicherung zu fahren und diese direkt gegen die "alte" Vollsicherung laufen zu lassen (über gezieltes Setzen von otherBackupSeries). Das "neue Vollbackup" darf nicht gegen eine "inkrementelle" Sicherung laufen, da sonst die Hardlinks nicht gesetzt werden können.
(Alternativ könntest Du auch die "inkremellen" Backups woanders hin verschieben (außerhalb des backupDir), dann das neu "vollständige" Backup mit Referenz auf das nun vorherige "alte vollstände Backup" laufen lassen und anschließen die "inkrementellen" Backups wieder an die "richtige" Stelle verschieben.)

Ich würde das nicht machen - es gibt da einige Möglichkeiten, wie Du Dir die Backups schießen könntest, wenn nicht alles perfekt läuft. Grundsätzlich funktioniert das von mir beschriebene Verfahren aber.
Ein weiterer Nachteil dieses Verfahrens ist, dass bei einer Rücksicherung alle "inkremetellen" Backups (mindestens bis zum gewünschten) vervollständigt werden müssen. Je nach Größe des Backups kann das dann durchaus dauern. Das Löschen der inkrementellen Backup müsstest Du Dir auch skripten. Einige Features, wie Replikation funktionieren dann natürlich auch nicht mehr (da auf storeBackupUpdateBackup basierend).


> Und noch eine Kleinigkeit: Ich vermisse die Funktion einer E-Mail Benachrichtigung über ein erfolgreiches/fehlgeschlagenes Backup. Gibt es diese Funktion irgendwo?


StoreBackup folgt da der Unix-Philosophie, eine Sache zu machen und nicht mehrere gleichzeitig - wenn sie ansonsten sowieso verfügbar ist. Du kannst einfach den exit-Status (oder die Log-Files) überprüfen und dann eine E-Mail verschicken.

Grüße,
HJC

Heinz-Josef Claes <hjclaes>
Group administrator
Thu 13 Nov 2014 08:31:10 AM UTC, comment #8: 

Und noch eine Kleinigkeit: Ich vermisse die Funktion einer E-Mail Benachrichtigung über ein erfolgreiches/fehlgeschlagenes Backup. Gibt es diese Funktion irgendwo?

Vielen Dank für Eure Unterstützung.

Anonymous
Wed 12 Nov 2014 07:07:27 PM UTC, comment #7: 

Hallo,

so ich habe nun endlich die Zeit gehabt mich etwas intensiver mit storeBackup zu beschäftigen und bin auch direkt sehr gut klar gekommen. Eine Frage habe ich aber noch:

Ich benutze die Option lateLinks um nur eine inkrementelle Sicherung übertragen zu müssen. Nun wird beim storeBackupUpdate jedes mal ein volles Backup generiert.

Wie verfahre ich am besten, wenn ich nur ein volles Backup pro Monat sichern möchte und die anderen Backups der vorherigen 30 Tage nach Bedarf generieren lasse?

Viele Grüße

Anonymous
Sat 20 Sep 2014 02:47:25 PM UTC, comment #6: 


> Oh okay, dass heißt ich muss jedes mal eine volle Sicherung durchführen?


Die erste Sicherung ist eine Vollsicherung. Alle weiteren sind vom Aufwand her inkrementelle Sicherungen, vom Ergebnis her aber auch Vollsicherungen.
Es wäre gut, wenn Du Dir mindestens das Kapitel
5 Die Idee hinter storeBackup
sowie Kapitel
7.6 Verwendung der Option lateLinks
durchlesen würdest. (Andere schaden natürlich auch nicht :-) .)

Für Deine Anwendung wäre wahrscheinlich die Verwendung von Option lateLinks (bei storeBackup.pl) sowie später auf dem Server die Verwendung von storeBackupUpdateBackup.pl sinnvoll.

Am Besten einfach lokal mit ein paar Beispieldateien ausprobieren.

Grüße, Heinz-Josef

Heinz-Josef Claes <hjclaes>
Group administrator
Sat 20 Sep 2014 08:30:43 AM UTC, comment #5: 


>Ob und wie man Sicherungen anstößt ist völlig egal. Das Löschen alter Backups ist auch problemlos, weil es keine inkrementellen Sicherungen gibt. Jede Sicherung ist im Resultat immer eine volle Sicherung.

Daher weiß ich nicht, was Du mit der Frage meinst!?
Oh okay, dass heißt ich muss jedes mal eine volle Sicherung durchführen? Das wäre schon ein ko für storeBackup. Ich transferiere über das Internet und die Datenmengen sind so groß, dass ich nur einmal ein volles Backup aller Dateien anstoßen kann welches dann auch mehrere Tage dauert.
Vom Backupplan habe ich mir vorgestellt, eine vollständige Sicherung zu haben und die täglichen, wöchtenlichen & monatlichen Sicherungen sichern jeweils nur die Veränderungen. Dabei sollte einmal jährlich eine neue Sicherung gemacht werden.

Henning <cdn>
Fri 19 Sep 2014 08:13:52 PM UTC, comment #4: 


> Der Hauptvorteil von storeBackup liegt im Vergleich zu duplicity wohl darin, dass bei einem Bitfehler nicht alle folgenden Dateien nicht wiederherstellbar sind oder?


Ich muss zugeben, dass ich nicht viel von duplicity weiß, außer dass es wohl häufiger Probleme mit Datenverlust gibt. Bitfehler (z.B. auf der Platte) betreffen bei storeBackup immer nur die direkt betroffene Datei, sonst nichts. Man kann derartige Fehler (oder welche aus anderen Gründen) über storeBackupCheckBackup.pl ermitteln. Für einen solchen Fehlerfall kann man als "Trumpf in der Hinterhand" dann noch eine (oder mehrere) Replikationen vorhalten.
Grundsätzlich ist die Philosophie von storeBackup, dass man auch ohne storeBackup wieder an seine Daten kommt. Das heißt, die Backups werden in einem möglichst einfachen, transparenten Datenformat gespeichert.

> Inkrementelle Sicherungen mit einer Täglichen Sicherung pro Woche (also nur tagesaktuell) + einer wöchentlichen und einer monatlichen sollte ja mit storeBackup möglich sein oder?


Ob und wie man Sicherungen anstößt ist völlig egal. Das Löschen alter Backups ist auch problemlos, weil es keine inkrementellen Sicherungen gibt. Jede Sicherung ist im Resultat immer eine volle Sicherung.
Daher weiß ich nicht, was Du mit der Frage meinst!?

Viele Grüße,
Heinz-Josef

Heinz-Josef Claes <hjclaes>
Group administrator
Fri 19 Sep 2014 08:52:08 AM UTC, comment #3: 

Vielen Dank für die schnelle Antwort & die Anleitung.

Ich denke ich werde mich für die Lösung mit gpg entscheiden.

Der Hauptvorteil von storeBackup liegt im Vergleich zu duplicity wohl darin, dass bei einem Bitfehler nicht alle folgenden Dateien nicht wiederherstellbar sind oder?

Inkrementelle Sicherungen mit einer Täglichen Sicherung pro Woche (also nur tagesaktuell) + einer wöchentlichen und einer monatlichen sollte ja mit storeBackup möglich sein oder?

Der Transport ist bis dato immer via ssh durch einen SSH Tunnel abgelaufen.

Viele Grüße,

Henning

Anonymous
Thu 18 Sep 2014 06:32:17 PM UTC, comment #2: 

Also man kann storeBackup einfach sagen, gpg statt eines Komprimierungsprogramms zu verwenden.:

also Setzen von:
compress=gpg <parameter>
uncompress=skriptZumEntschlüsseln

Eine Regel für die zu komprimierenden (=verschlüsselnden) Dateien schreiben,
die immer 'true' zurückliefert (d.h. alle Dateien werden komprimiert = verschlüsselt) :
comprRule=1

Den Rest der Optionen wie gehabt verwenden.



Nachteile:
- Die Dateinamen sind nicht verschlüsselt.
- Die md5 Summen der Originaldateien sind ebenfalls unverschlüsselt vorhanden.


Besser ist es, auf eine mit dm-crypt verschlüsselte Partition zu schreiben (das mach ich). Dann müssten man den Transportweg mit ssh oder z.B. openvpn verschlüsseln. Hierbei kommen die Daten natürlich unverschlüsselt aus dem vpn beim Remote Rechner an, der sich dann auf die Verschlüsselte Partition schreibt. Dem Remote-Rechner muss man dazu auch Vertrauen entgegen bringen können.
Schreiben kann man über NFS v4,(wichtig: Version 4), dass geht über lahme, miese Remote-Leitung auch ganz gut - jedenfalls bei meinen Tests).

Bei Verwendung von ssh können nicht alle Dateitypen remote angelegt werden, die müssen also entweder vom Backup ausgenommen werden (Option exceptTypes)  oder in ein cpio / tar Archiv gepackt werden (siehe Option specialTypeArchiver).

Hilft das irgendwie weiter?

Grüße, Heinz-Josef

Heinz-Josef Claes <hjclaes>
Group administrator
Thu 18 Sep 2014 08:38:25 AM UTC, comment #1: 

OK in english:

I'm looking for a way to use storeBackup together with a GPG encryption. Someone know how to handle?

greets

Anonymous
Thu 18 Sep 2014 08:31:39 AM UTC, original submission:  

Hallo,

gibt es die Möglichkeit die Backups vor der Sicherung auf ein Remotesystem via SSH zu verschlüsseln? Beispielsweise mit GPG.

Ich würde storeBackup gerne als Alternative zu Duplicity nutzen, nur ohne Verschlüsselung geht dies leider nicht.

Viele Grüße,

Henning

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by cdn (Posted a comment)
  • -email is unavailable- added by hjclaes (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-12-09 hjclaes StatusNone Done

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code