Absolute Daten Sicherheit bei Backup-Server - Wie? Eine Idee und viele Fragen...

  • Hallo zusammen,

    ich habe eine verrückte Idee und scheitere an deren (sicheren) Umsetzung - habt ihr damit Erfahrung oder könnt ihr mir Tipps geben?


    Das Grundkonzept:

    Es gibt einen Server A, welcher verschiedene Daten hat - dieser soll auf Server B diese Daten regelmäßig sichern. Server B soll dabei NIEMALS (also keine eigenen verschlüsselten Partitionen! [oder nur zusätzlich...]) mit den unverschlüsselten Daten in Kontakt kommen.


    Meine Umsetzungsideen:

    Version 1: Server B stellt einen SSH-Share von einem .img von einer virtuellen Festplatte bereit. Server A hängt nun diesen SSH-Share ein und hängt die .img ein. Dieses wird nun via LUKS geöffnet und hängt die eigentliche Partition ein.

    Dies erfordert einen eigenen service in systemd und nun... Was passiert bei Verbindungsproblemen?


    Version 2: Server B stellt einen SSH-Share von einem .img von einer virtuellen Festplatte bereit. Server A hängt nun diesen SSH-Share ein und hängt die .img ein. Dieses wird nun als ext4 mit Verzeichnisverschlüsselung eingehängt (Kernel 4.1+)...

    Dies erfordert einen eigenen service in systemd und nun... Was passiert bei Verbindungsproblemen? Außerdem zickt die Kernel-Schlüsselverwaltung rum. Und ist teilweise noch nicht implementiert (z.B. Gruppenschlüssel [meine ich])...


    Version 3: Server B stellt Nextcloud mit default encryption bereit und Server A verwendet webdav (...). - Ist aber lahm und verstößt gegen das Grundkonzept... Zudem bietet Server B nun eine zu große Angriffsfläche (sonst würde dort nur SSH laufen...)!


    Nebenbei:

    • Beide Server sind Debian (9)
    • Server A hat zudem eine schlechte Netzanbindung (sonst super CPU und ausreichend RAM 24G)
    • Server B hat einen lahmen Prozessor (ARM halt...) und kaum RAM (1G) aber super Netz
    • Bei Fragen ergänze ich gerne diese Rahmenbedingungen...


    Ich bin für alles offen - Fragen sind willkommen!

    Viele Grüße,

    Simonmicro

  • Bevor Du Dir selber was bastelsr schau Dir mal https://www.borgbackup.org/ an. Das legt verschlüsselte Backups auf dem Zielserver ab. Das ist eine erprobte Lösung, die benutze ich auch.


    Schlechte Netzwerkverbindung und schwache CPU sind für externe Backups generell ein Problem, es dauert dann halt länger. Auf jeden Fall kann borg inkrementell sichern.

  • Zitat

    duplicity?

    Scheint ein Multithreading Problem zu sein - zwei Personen haben gleichzeitig eine Ressource verwendet...

    Zitat

    Wir sind die Borg. Wiederstand ist zwecklos. Ihre pysiologischen und technologischen Eigenschaften werden den unseren hinzugefügt.

    ...ich kam nicht umhin daran zu denken :). Ich habe das Gefühl, dass ich mich mit meiner Lösung ein bieeeeschen verrant hatte...


    Aber ja, das scheit das zu sein, was ich suchte - Fragen, damit ich mir das Einlesen für heute Abend sparen kann: Klappt das mounten via fuse auch übers Netzwerk? Oder verstehe ich das falsch und der Server A hat borg und erstellt z.B. via SSH-Share auf Server B das Backup? Würde das Backup denn dann auch noch inkrementiell funktionieren? Muüssten dafür mehrere Shares existieren? :/ Und wie speichert Borg seine Daten - werden Pfade mit verschlüsselt, oder ist am Ende alles eine .borgcube-Datei 8o?


    ????


    Danke,

    Simonmicro

  • Hallo,

    Ich konnte es nicht lassen und habe angefangen mich mit Borg zu beschäftigen und JA! Es ist perfekt für meine Not! Zudem wird borg wahrscheinlich meine alten rsync Sicherungen gleich mit ablösen!


    Prinzipiell also Folgendes:

    • Server B kriegt ein Borgverzeichnis
    • Server A sichert via SSH-KeyfileAuth und eigenem Borg-KeyFile in das SSH-Verzeichnis von Server B und das für jeden Sicherungspfad!
    • Knallts mal bei Server A, so krallt man sich ein bestimmtes Backup via fuse und sucht sich das zu Rettende wieder raus.

    Himmel ist das einfach!


    Vielen Dank,

    Simon

  • Bash
    #!/bin/bash
    
    NOW=$(date +"%Y-%m-%d")
    FILE="backup-$NOW.enc"
    #mount 46.38.248.210:/voln112342a1 /mnt/backup
    sshfs backup: /mnt/backup/
    mksquashfs /var/backups/*****.h6g.de/ /var/backups/*****.h6g-server.net/ /var/backups/*****.h6g-server.net/ /var/backups/*****.com/ /var/backups/backup-today.sqfs -noappend -no-duplicates
    openssl enc -e -aes256 -pass file:/root/passphrase.txt -in /var/backups/backup-today.sqfs -out /mnt/backup/$FILE
    umount /mnt/backup
  • Bash
    #!/bin/bash
    
    NOW=$(date +"%Y-%m-%d")
    FILE="backup-$NOW.enc"
    #mount 46.38.248.210:/voln112342a1 /mnt/backup
    sshfs backup: /mnt/backup/
    mksquashfs /var/backups/*****.h6g.de/ /var/backups/*****.h6g-server.net/ /var/backups/*****.h6g-server.net/ /var/backups/*****.com/ /var/backups/backup-today.sqfs -noappend -no-duplicates
    openssl enc -e -aes256 -pass file:/root/passphrase.txt -in /var/backups/backup-today.sqfs -out /mnt/backup/$FILE
    umount /mnt/backup

    Das ist auch eine interessante Lösung, allerdings müsste ich somit einmal alle Daten zwischenspeichern, was evtl. nicht mehr aufs RAID passt, da evtl. zu wenig noch frei ist. Borg scheint zudem inkrementielle Sicherungen etc. zu unterstützen.


    Stelle nur sicher, dass das Passwort für die Verschlüsselung nicht verloren geht. Wenn Server A mal komplett kaputt gehen sollte, wäre das Backup sonst nicht mehr lesbar.

    Kein Problem - der Schlüssel landet mit verschlüsselt in nem zip auf Server B. Server B bekommt selbstverständlich nicht das PWD - aber ich :)


    Ich persönlich werde nun auf Borg umstellen, da es einige Vorteile mit sich bringt, die ich vorher gar nicht auf dem Schrim hatte. Dennoch danke an alle Tipps und Vorschläge!

  • "Abonnement verwalten"... nicht gerade intuitiv benannt.

    In den Foren, in denen ich seit 15 Jahren bin, nennt sich die Funktion aber fast immer "Abonnement", "Abo" oder nur schlicht "Thema abonnieren". Selten auch noch "[…] benachrichtigen".

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • In den Foren, in denen ich seit 15 Jahren bin, nennt sich die Funktion aber fast immer "Abonnement", "Abo" oder nur schlicht "Thema abonnieren". Selten auch noch "[…] benachrichtigen".

    Die Rechtfertigung des Bad User Interface Design durch den Schluss von Sein auf Sollen? Wir Informatiker werden's nie lernen...

  • Bezüglich Borg als Backuplösung:

    Bisher habe ich nur Beispiele gesehen, bei denen Backups vom Client zum Borg Backup remote gepusht wurden.

    Hat es jemand andersherum am Laufen? Ich stelle mir vor, dass sich der Server mit dem Borg Repo die Backup Daten von den Clients pulled. Dann kann man die Backuplogik an einer Stelle konfigurieren und muss es nicht auf jedem Client einzeln tun.

  • Bezüglich Borg als Backuplösung:

    ......

    Ich stelle mir vor, dass sich der Server mit dem Borg Repo die Backup Daten von den Clients pulled. Dann kann man die Backuplogik an einer Stelle konfigurieren und muss es nicht auf jedem Client einzeln tun.

    Wenn dann jemand ungefugten Zugriff auf deinen Backup-Server erlangt, könnte er aber ggf. darüber auch Zugang zu all deinen Backup-Clients erlangen. Ich für meinen Fall vermeide eine solche Zentralisierung. Lieber die Einstellungen Server für Server vornehmen, die Verbindung zum Backup-Server über Schlüssel herstellen, und auf Seite des Backup-Servers den Schlüssel auf die Verwendung für Borg begrenzen.

    9 von 10 Stimmen in meinem Kopf sagen ich bin nicht verrückt, die letzte summt ständig die Melodie von Tetris.

  • Bezüglich Borg als Backuplösung:

    Bisher habe ich nur Beispiele gesehen, bei denen Backups vom Client zum Borg Backup remote gepusht wurden.

    Hat es jemand andersherum am Laufen? Ich stelle mir vor, dass sich der Server mit dem Borg Repo die Backup Daten von den Clients pulled. Dann kann man die Backuplogik an einer Stelle konfigurieren und muss es nicht auf jedem Client einzeln tun.

    Wie RHA sagt: würde ich auch nicht so machen.


    Ich halte meine Borgeinstellungen über Ansible aktuell und kann ggf. Änderungen vornehmen.

  • Wenn dann jemand ungefugten Zugriff auf deinen Backup-Server erlangt, könnte er aber ggf. darüber auch Zugang zu all deinen Backup-Clients erlangen. Ich für meinen Fall vermeide eine solche Zentralisierung. Lieber die Einstellungen Server für Server vornehmen, die Verbindung zum Backup-Server über Schlüssel herstellen, und auf Seite des Backup-Servers den Schlüssel auf die Verwendung für Borg begrenzen.

    Du kannst deinem Backup-Server auch nur einen reinen SFTP-Zugang ohne Shell geben.

    https://www.linode.com/docs/to…ils-on-debian-and-ubuntu/


    mMn eins der unterschätztesten Features von OpenSSH.

    friendly chat by and for customers:

    irc.hackint.org:6697

    #nc-kunden

  • Verbindung zum Backup-Server über Schlüssel herstellen, und auf Seite des Backup-Servers den Schlüssel auf die Verwendung für Borg begrenzen.

    Und auch noch auf reines Schreiben begrenzen. Sonst kann ein Serverhack ja deine Backups löschen.