Wie eine sichere lokal Backup Routine bauen?

Also ich hänge irgendwie immer noch sehr fest in der Frage, wie ich mir ein gutes inkrementelles nicht Cloud Backup für meinen Laptop bauen kann. Einerseits kann ich wunderbar mit rsync oder borg backup meine Daten irgendwohin speichern, aber das „Festplatte ranhängen und backup starten“ Modell funktioniert irgendwie nicht realistisch in meinem Lebens/Workflow, also würde ich gerne einen Pi4 als Server einrichten und dann… ja was dann?

Wenn ich meine Daten vom Laptop darauf pushe, dann muss dieser zwangsläufig Schreibrechte haben auf das Backup Storage, keine gute Idee.

Wenn ich die Daten vom Pi4 pulle, muss das Pi zwangsläufig komplette Leserechte auf meine Laptop haben, für ein Gerät das die ganze Zeit irgendwo steht (Büro oder Zuhause) auch nicht so schön. Mit physischem Zugriff wäre das Gerät dann auch nicht wirklich sicher. Da wäre nur die Frage ob ich das als wirkliches ThreatModel identifiziere. Aber wenn irgendwann mal bei mir was geklaut wird und Pi und Festplatten weg wären, ich könnte nie sicher sein dass nicht doch jemand den Key aus dem RAM gezogen und meine Festplatte entschlüsselt hat. Soo schwer ist das nun auch nicht.

Eine Idee wäre, lokal auf dem Laptop ein Backup zu erstellen, das zu verschlüsseln und dann per ssh forced command nur dieses ziehen zu lassen. Aber dann kann ich kein inkrementelles Backup bauen sondern müsste immer alles in ein Archiv packen…

Warum dieses?
Es kommt wie immer darauf an, was man daraus macht.
Ansonsten: wenn Dein Haus abbrennt oder von etwas Unfreundlichem getroffen würde, wären alle Daten weg.
Ich habe Kopien der wirklich wichtigen Daten um die Welt verteilt. Allerdings lokal verschlüsselt.
Die Schlüssel haben jeweils die anderen BackUps.

Interessant sind in Summe: Benelux, Skandinavien, Schweiz, USA, Australien, Neuseeland und was „Lokales“ in D-Land. Dann bist Du für alle Fälle geschützt, außer, wenn der Planet explodiert und dann brauchst Du sie eh’ nicht mehr.

Es kommt drauf an, wie du das ganze aufziehen willst.

Ich habe bei mir nur Rechner unter Linux (PC, Laptop) oder BSD (Server). Auf dem Server existieren SMB-Freigaben, die ich aber mittels Script nur bei Bedarf einhänge. Sichern tue ich teilweise 2-gleisig. Auf meinem Haupt-Rechner sichere ich bestimmte Daten mittels Bash-Scripten auf entsprechende SMB-Shares auf dem Server, die Benutzerverzeichnisse und noch so einiges (u. a. die Virtualbox-Gäste) mittels borgbackup auf den Server – in dem Fall per ssh. Auf dem raspi passiert das nach dem selben Konzept. Die Standard-Sicherungsroutinen laufen (bis auf den Laptop) cron-gesteuert; das Ende der Sicherung löst den Shutdown aus. Alle Sicherungen schicken logfiles per Mail an mich. Also im Regelfall nur Kontrolle. Auf dem Laptop stoße ich die Sicherung an, borgbackup kümmert sich drum; danach fährt dann der Laptop runter.

Auslagerungen erfolgen mittels LUKS auf normale Festplatte (SSD erscheinen mir da unsicher). Auch das per bash-Script, allerdings händisch angestoßen. Immer alle auszulagernden Daten in ein Verzeichnis =Tagesdatum mit etwas logging, insbesondere über den letzten Zeitpunkt der Auslagerung und Vermerk welche Platte, was ist drauf. Bei Login wird auf das Datum der Datei geschaut (bash-Script) und spätestens nach 30 Tagen zetert der Rechner mich dann immer an.

Inkrementell ist technisch nicht möglich ohne irgendeine Art von Rückkanal. Oder du hast lokal eine Liste von Dateien die seit dem letzten Backup verändert wurden. Und machst eben lokal auch nur ein Backup dieser Dateien und kopierst es dann zu deinem Server.

Eben. Welche Art von Daten sind das, vor wem willst du sie schützen und wie wahrscheinlich ist das jemand kommt und dein RAM ausliest.
Auch sowas lässt sich je nach technischem Aufwand (den du betreiben musst) verhindern.

Objective-SeePee:
Inkrementell ist technisch nicht möglich ohne irgendeine Art von Rückkanal. Oder du hast lokal eine Liste von Dateien die seit dem letzten Backup verändert wurden.

Das mit dem „Rückkanal“ für das inkrementelle Backup macht normalerweise jedes Backup-Programm mit Hilfe des Archiv-Bits im Dateisystem. Allerdings gilt in Fällen inkrementeller Backups immer noch:
Ein Voll-Backup, ein oder mehrere inkrementelle Backups, danach wieder Vollbackup.
Denn die inkrementellen Backups nutzen dir nichts ohne das vorherige Voll-Backup. Von daher macht es überhaupt keinen Sinn, zu lange auf Vollbackups zu verzichten.

1 „Gefällt mir“

Wenn du sowieso einen Server einrichtest, dann mach doch eine Backuplösung für Server drauf, z.B. UrBackup oder BackupPC. Das sind durchdachte und seit sehr vielen Jahren bewährte Lösungen.

Ihr seid alle viel zu sehr in den Details. Ich kann ohne Probleme ein inkrementelles rsync Backup einrichten, in dem ich über --link-dest mir pro Backup einen gesamten Dateibaum mit Hardlinks baue und trotzdem nur die geänderten Dateien transferieren muss. Das ist simpel und Robust, dafür brauche ich erstmal keine Software Lösungen.

Meine Frage setzt ja an einer ganz anderen Stelle an: push oder pull. Beides hat Vor und Nachteile.

wie gesagt, falls es mal passiert das im Büro Festplatte und Pi geklaut werden, kann ich natürlich denken „den Aufwand macht schon keiner, die wollten nur die Hardware“, aber ehrlich gesagt werd ich da trotzdem nur schwierig mit ruhig schlafen können. (und wie gesagt, soviel Magie ist cold boot nicht gerade)

Ich hab nicht nachvollziehen können, machen SMB Freigaben irgendetwas „besser“ im Sinne der Push/Pull Probleme bzw. Schreib und Leserechte? Wenn es eine Möglichkeit gäbe Permissions so zu bauen wie in Mysql, dass ich nur Rechte für INSERT geben kann aber keine für DELETE und UPDATE wäre das natürlich sehr spannend.

Das Problem bei meinem bevorzugten Pull Prinzip (=keine Schreibrechte aufs Backup) ist ja, dass dann alle Schlüssel auf einem „laufenden“ System liegen. Hier könnte ich mir noch vorstellen sowas noch zu lösen mit:

  1. Pi ist normalerweise aus
  2. ich schalte es einmal am Tag ein und hacke per Tastatur und/oder yubikey eine Berechtigung ein
  3. es läuft los, macht Backup und schaltet sich wieder aus.

Macht ja im Grunde eh keinen Sinn, wenn der Pi an ist wenn ich (bzw. mein laptop) garnicht da ist zum backuppen.
Aber eine manuelle handlung zum Backup machen is immer blöde, auch wenn ich mir noch vorstellen könnte dass das so machbar wäre.

tja ehrlich gesagt, so eine konkrete Antwort hab ich darauf auch nicht mehr. Ich hab meine Daten schon gerne „in der Hand“ aber gute E2E Cloud Backuplösungen würde ich mir schon auch nochmal anschauen.

Durchaus machbar. Das Anschalten kannst du über ACPI Wakeup mit der in jedem PC verbauten Hardwareuhr automatisieren. Ausschalten ist ein bisschen aufwändiger zu automatisieren, aber geht natürlich auch. Mache ich beides so mit meinem HTPC. UrBackup kann sich sogar selbst beenden, wenn es mit den Backups durch ist.

Für die Entschlüsselung des Systems beim Booten legst du einen Schlüssel auf einem USB Stick ab und lässt den im Gerät stecken. Wenn du dann sicher gehen willst, dass niemand den Rechner booten kann, ziehst du den Stick ab. Mache ich so mit meinem Router.

1 „Gefällt mir“

ok, das würde das drücken des anschaltknops und warten auf loginprompt verhindern, vielleicht auch ganz gut M)

öh einfach ein shutdown -P now am ende des backups?

ja das wäre dann ja beliebig, usb stick, yubikey, passphrase…

Schützt natürlich alles auch nicht vor MITM wenn mir da wer da ein präpariertes Gerät hinstellt, aber das soll dann wirklich nich mein threat model sein.

Edit: mmh ich dachte grad noch, ich könnte auch die OS disk auf dem Pi unverschlüsselt lassen und dann kann ich ein ssh forced command von meinem Laptop auf den Pi zulassen, der die Festplatten entsperrt und dann das Backup startet :thinking: Dann hat der Laptop kein direktes Schreibrecht auf den Backupserver aber kann die Festplatte entschlüsseln. Ich befürchte aber, SSH ForcedCommand ist wirklich forced, also der Schlüssel müsste dann auch mit in dem Command in der authorized_keys auf dem Pi stehen

Du denkst ernsthaft, daß jemand, der in Privathäuser einbricht Kältespray, geeigneten Bootstick, PC-Werkzeug etc. mitführt, in der Hoffnung auf ein laufendes Computersystem zu treffen um mit einer Cold Boot Attack die Backups von Urlaubsbildern und Muttis besten Backrezepten zu erbeuten?

3 „Gefällt mir“

Bei den professionelleren Systemen laufen normalerweise im Hintergrund noch Aufräumarbeiten u.ä. Und evtl. will man ja auch mehr als ein System sichern. Aber kann man natürlich alles in einem Skript berücksichtigen.

Zugriffe auf Laufwerke regelt man über Nutzerrechte, dafür sind sie da. Backuplösungen wie Borg haben Dokumentation, wie man den Zugriff so einschränkt, dass nur die Backuproutinen auf die Dateien zugreifen können.

Ich verschlüssele meine wirklich wichtigen Daten komprimiert als eine Datei (ca. 1 GB) mit ccrypt und speichere sie dann auch in der Cloud oder nehme sie auf einer SD Karte im Portemonnaie mit. (einschließlich der unverschlüsselten Software für MAC OS und Windows.

https://ccrypt.sourceforge.net/
man ccrypt in Linux
https://packages.debian.org/bullseye/ccrypt

Ich gehe davon aus, dass die Daten auch unverschlüsselt auf verschlüsselten Systemen (verschlüsselte Festplatten unter Linux oder Mac OS und auf einem Iphone oder Android Smartphone) sicher sind?

Australien als Speicherort finde ich auch wichtig, falls man es vor dem möglichen nächsten Atomkrieg (diesmal in Europa und in den USA) noch dahin schafft.

Und wenn Elon Musk bald auf den Mars auswandert, könnte man könnte man seine Dateien natürlich auch auf dessen Mars-Servern speichern.

Ich beschreibe mal meinen Ansatz, wobei ich mir nicht sicher bin, ob VMs oder Storage bei z.B. Hetzner für dich „Cloud“ sind oder ob du damit eher „Dropbox“ oder „OneDrive“ vermeiden willst?

Ich habe eine Storagebox als Datenablage für „Backup ausser Haus“. Die Storagebox ist auf meiner VM bei Hetzner eingebunden und per syncthing lasse ich lokal → remote in genau diese Richtung synchronisieren („Send only“) und verbiete damit, dass von der remote-Seite zu meiner lokalen Seite gelöscht werden kann.
Wichtig ist ausserdem, dass ich zur Versionierung mehrere (kostenlose) Snapshots auf Storagebox-Ebene habe und dass „simple file versioning“ und „keep x versions“ in syncthing aktiv sind. Somit ist das auch grundsätlzich ransomware-„sicher“ und vor allem schützt das auch gegen (versehentliches und absichtliches) Löschen.

Somit synchronisiert mein 24x7 laufender Linux-Rechner zuhause ganz ohne mein Zutun alles vollautomatisch, was ich einmalig zum Synchronisieren/Sichern eingerichtet habe. Wenn man will, kann man das auch noch auf viele weitere syncthing Clients ausweiten (VM+Storagebox/ausreichend viel lokaler Speicher/Computer bei Menschen, denen man vertraut bzw. per „encryption password“ auf „untrusted devices“ verschlüsseln), um so mehrere externe Backups zu haben.

Weitere Lesetipps dazu:
https://www.heise.de/ratgeber/Raspi-Backup-Plattformunabhaengiges-Backup-mit-Syncthing-einrichten-6111168.html
https://www.heise.de/ratgeber/Raspberry-Pi-als-zentralen-Backup-Server-mit-Syncthing-einrichten-6109494.html

Das initiale „Backup“ ist halt je nach Datenmenge (z.B. Urlaubs- und Familien-Fotos) etwas langwierig je nach Internetanbindung. Aber danach läuft das alles völlig transparent und unauffällig im Hintergrund.

Nebenbei greife ich noch readonly über meine Nextcloud (per sftp-Mounts) darauf zu, so dass ich auch unterwegs auf dem Smartphone meine Fotos anschauen und zeigen kann :slight_smile:

Update:
Damit werden hier übrigens 223k files in 31k dirs (~554 GiB) gesichert. Im Büro sagte mir mal, dass 100k files mit OneDrive „nicht empfehlenswert“ seien, was ich schmunzelnd zur Kenntnis genommen habe (sei es weil es wirklich so ist oder wegen der unqualifizierten Aussage).