Login
Login-Name Passwort


 
Newsletter
Werbung

Thema: Verschlüsselte Server-Backups mit Duply und Duplicity

15 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
1
Von He-Man am Do, 10. November 2016 um 19:02 #

wer sein Backup online stellt kann auch gleich auf die Verschlüsselung verzichten.

Alleine wenn ich mir die bsp. so durchlesen ... :shock:

... in die Amazon S3 Cloud oder sogar auf einen Online-Speicherplatz wie Dropbox und Megaupload

....

  • 1
    Von kamome umidori am Do, 10. November 2016 um 22:48 #

    Erklärst Du uns auch weshalb?

    • 1
      Von RipClaw am Do, 10. November 2016 um 23:19 #

      Er ist vermutlich der Meinung das Geheimdienste die Verschlüsselung quasi im Vorbeigehen knacken können.

      • 1
        Von Xtrello am Do, 10. November 2016 um 23:56 #

        Lol. Diese Meinung ist schlicht falsch. Geheimdienste können sicher nicht alles knacken.

        Ob GPG mit 2048 bit Schlüsseln noch gut genug ist, keine Ahnung, man kann auch 4096 oder noch höhere Schlüssel generieren.

        Solange GPG keine Hintertür in Form eines Bugs hat dürfte es unknackbar bleiben. So gesehen macht ein verschlüsseltes Backup schon viel Sinn!?

        • 1
          Von ..Antwort am Fr, 11. November 2016 um 08:46 #

          [...] keine Hintertür in Form eines Bugs [...] macht ein verschlüsseltes Backup schon viel Sinn!?

          Jein. Hintertüren müssen nicht zwangsläufig Bugs sein. Hoch sensible Daten sollte man unter keinen Umständen in die Wolke laden oder Servern mit Zugang zum Internet haben - WARUM?

          Die Geheimdienste brauchen
          1) nur irgendwie an den Schlüssel zu kommen - und
          2) diesen zu sich nach Hause zu übertragen (ohne dass der Angegriffene etwas merkt)

          zu 1) erpressbare Mitarbeiter, Trojaner, ... geheime Hintertüren in Intel Prozessoren
          zu 2) covert channels (mir fällt grad das deutsche Wort nicht ein) ,.... erpressbare Mitarbeiter (Stichwort Steganografie)

          Da kryptographische Schlüssel sehr kleine Daten sind, lassen sich diese auch auf anderen Medien (z.B. als ausgedruckter Barcode) aus dem Unternehmen schmuggeln. Wenn dann die verschlüsselten Daten (für hochkriminelle Subjekte) frei zugänglich sind - dann gute Nacht.

          • 0
            Von jekylhide am So, 13. November 2016 um 15:43 #

            Wer wirklich im Fokus der Behörden ist hat ganz andere Probleme als eine Verschlüsselung. Der bekommt auch schon mal Hausbesuche.

            Sehe die Verschlüsselung der Cloud eher als Schutz vor den "normalen" Hackern, Datenverlust bei Providern sowie Schutz vor den normalen Contentscannern.

    0
    Von Sie haben vergessen, Ihren Nam am Sa, 12. November 2016 um 18:05 #

    Unabhängig von der Verschlüsselungsthematik stellt sich die Frage nach der Zuverlässigkeit solcher Speicherorte.

0
Von Potz Blitz am Fr, 11. November 2016 um 08:28 #

Wenn es sich um eine Verschlüsselung auf Dateiebene handelt, könnte man auch überlegen mit einem Stacked-Filesystem wie encfs oder ecryptfs zu arbeiten. Dann sind die Daten auch gegen Diebstahl des Servers geschützt und man die verschlüsselten Dateien direkt in der Cloud sichern.

Wäre, wie gesagt, noch eine mögliche Option.

Auf jeden Fall finde ich Anleitungen dieser Art sehr hilfreich, da es immer interessant ist, auf welche Weise man das Problem lösen kann und wie andere es gemacht haben. Vielen Dank dafür!

0
Von Erwin Brunzhofer am Fr, 11. November 2016 um 08:33 #

Ich habe das mal mit deja-dup verwendet, das verwendet auch das darunterliegende duplicity. Verglichen mit anderen Backuplösungen ist es extrem lahm und rödelt wie blöd auf der Platte rum, braucht wohl u.U. sehr viel tempspace.
Packer kann man auch nicht angeben.

Ich finde dar besser, das kann auch differentiell, sowohl mit letzten Vollbackup als Bezug oder letztem diff. Packer kann beliebig gewählt werden, Verschlüsseln kann ich es auch mit beliebigem Verschlüsselungstool und hochladen auf entspr. Dienst kann ich auch mit dem jeweiligen Transporttool. Den Katalog kann man lokal vorhalten, wenn man nichttransparente Protokolle verwendet.

  • 0
    Von Erwin Brunzhofer der II. am Fr, 11. November 2016 um 08:59 #

    Nochmal nachgeschaut:
    Es kann auch noch dekremental Mode: D.h. das Vollbackup ist immer auf dem neuesten Stand die älteren Änderungen werden als deltas vorgehalten so dass man im Restorefall direkt aus dem Vollbackup restoren kann und nicht erst das uralte Vollbackup und dann einen Zoo an diffs restoren muss um auf den letzen Stand zu kommen.
    Verschlüsselung ist integriert, gängige Packer auch, zusätzlich kann man noch externe Tools angeben wenn man die nutzen will.

    Für Restore brauche ich im Notfall nur die statisch gelinkte dar_static Datei, duplicity usw. haben einen Zoo an Abhängigkeiten, das alleine schon ist ein nogo.

    Das Ding hat einfach viele clevere Features die ich in anderen Backuptools noch nicht gefunden habe. Irgendwelches Zeugs das auf rysnc und Hardlinks basiert ist eher als Hack anzusehen, deshalb gibts auch gefühlt 100 solcher Tools, ich habe selber mal früher eines dieser Art geschrieben.

    • 0
      Von ups am Fr, 11. November 2016 um 10:34 #

      Gut, nennt sich aber im allgemeinen reverse incremental.

      rdiff-backup arbeitet so, funktioniert rediffWeb oder JBackPack als GUI.

    0
    Von Nur ein Leser am Fr, 11. November 2016 um 09:07 #

    Ich habe auch eine Zeit lang mit deja-dup gesichert (Vollsicherung + wöchentliche inkrementelle Sicherungen). War ganz ok, wenn auch etwas langsam, ja.

    Ich war ganz zufrieden, bis zu dem Zeitpunkt, als eine Rücksicherung plötzlich bei ca. 25% der Daten ausgestiegen ist und einen schweren Fehler gemeldet hat. Ich habe alle mögliche versucht, auch direkt auf der Kommandozeile mit "--ignore errors" (oder so ähnlich), allein die Sicherung ließ sich nicht wieder herstellen.
    Um das klarzustellen: Es wurde nicht nur eines der "Päckchen" nicht wiederhergestellt (dann wäre eben eine Datei hinüber gewesen oder zwei), sondern aufgrund des Fehlers in einem Päckchen oder einem "Manifest" wurden 75% der Sicherungsdateien ignoriert und nicht weiter verarbeitet!
    Glücklicherweise waren die wichtigsten Daten unter den ersten 25% gewesen und für einige andere der nicht wiederherstellbaren Daten hatte ich noch andere Kopien.

    Seit dem Zeitpunkt stehe ich duplicity/deja dup sehr kritisch gegenüber. Was nützt der Komfort, wenn die Basics so leicht versagen? Es darf nicht sein, das ein einzelner Fehler ein ganzes Backup lahm legt - zumal gerade 2 oder 3 Wochen vorher ein "Check" stattgefunden hatte, den duplicity ja regelmäßig macht, um die Integrität zu überprüfen.

    Ich benutze jetzt rsync/rdiffbackup mit backintime als Oberfläche. Und hoffe, das damit im Ernstfall die Daten zur Verfügung stehen.

    0
    Von HCIJra am Fr, 11. November 2016 um 10:17 #

    Habs gerade mal versucht. Das Backup startet schnell und die 700MB sind recht schnell gesichert (lokal in ein Verzeichnis). Jetzt versuche ich einen Restore von einer PNG Datei. 11 min dauert der Restore schon... Keine Fehlermeldung nichts!

    • 0
      Von Nur ein Leser am Fr, 11. November 2016 um 10:30 #

      ... Keine Fehlermeldung nichts!
      Falls sich das auf meinen Beitrag bezieht: Ich hatte auch nie eine Fehlermeldung, bis zu dem beschriebenen Ereignis. Dann aber so, das es nicht behoben werden konnte.

      Der Punkt ist auch nicht, das es mal einen Fehler hat. Der Punkt ist, das durch einen Fehler das komplette Backup ab einer bestimmten Stelle nicht mehr wiederhergestellt werden konnte!
      Scheinbar ist duplicity da nicht robust.

      • 0
        Von HCIJra am Fr, 11. November 2016 um 10:58 #

        Scheinbar ist duplicity da nicht robust.

        ^^ Genau das ist der Punkt! Da ist mein vertrauen schon weg.

        Ich habe gerade noch Borg gefunden. https://borgbackup.readthedocs.io/en/stable/index.html

Pro-Linux
Traut euch!
Neue Nachrichten
Werbung