Hi,
ich habe heute früh bei heise über die ChimeraMaleware gelesen, eine Software, die Dateien verschlüsselt und die Passphrase für Geld anbietet. In diesem Zuge habe ich generell über eine geeignete Backuplösung nachgedacht, um diesem Problem und Datenverlust im Allgemeinen vorzubeugen. Da ich in dieser Thematik neu bin, wollte ich eure Meinung zu meinen Überlegungen hören.
Momentaner Aufbau:
Meine Frau, ein guter Freund und ich haben alle wichtigen Daten in einem Ordner, der mit Hilfe von owncloud mit meinem Heimserver synchronisiert wird. Auf diesem Server läuft debian und ich betrachte diesen im folgenden als sicher und beschäftige mich mit Möglichkeiten, die Datenverlust bei Befall der Clienten zu verhindern. Gespeichert werden größtenteils Dokumente und einige Bilder. Die Größe des gesamten owncloud Verzeichnisses auf dem Server beträgt lediglich 8,9GB und wächst nur sehr langsam. Eine tägliche Sicherung würde in diesem privaten Anwendungsfall ausreichen. Die Daten sind serverseitig nicht verschlüsselt.
Angriffsszenario
Schadsoftware (oder auch Fehler seitens der Nutzer) löscht oder verschlüsselt Daten, die daraufhin verloren sind. Die Synchronisationssoftware überträgt diesen Datenstatus an den Server, auf dem die Daten dann ebenfalls gelöscht, oder durch verschlüsselte Container ersetzt werden.
Lösungsansatz:
Inkrementelles Backup!
Ein Vollständiges Backup belegt jeden Tag den Speicherbedarf des gesamten owncloud Verzeichnisses aufs Neue. Alte Backups sollte aber lange vorhanden sein, da Schadsoftware mitunter so programmiert ist, dass sie verschlüsselte Dateien über längere Zeit entschlüsselt und dem Nutzer die Manipulation der Daten nicht auffällt.Der Speicherbedarf ist dann aber zu groß!
Ein differentielles Backup tauscht veränderte Dateien aus. Manipulierte Dateien würden dazu führen, dass Originaldateien verloren gehen. Ebenfalls nicht geeignet!
Ein inkrementelles Backup speichert die Veränderten Dateien zum letzten Backup erneut ab. Manipulierte Dateien würden somit zusätzlich zu den Originaldateien gespeichert werden. Der Speicherbedarf wächst daher stetig, abhängig von der Frquenz der Veränderungen. Bei seltenen und kleinen Änderungen sollte der Speicherbedarf deutlich unter dem des Vollständigen Backups liegen.
Umsetzung unter debian:
rsync!
rsync führt das inkrementelle Backup durch. Unveränderte Daten werden per Hardlink gespeichert. Backups können somit zu beliebigen Zeitpunkten einfach durch Kopieren des Ordnerinhalts wiederhergestellt werden. Das Backup dann auf einen anderen Datenträger und fertig.
Schutz bei Kompromitierung des Servers:
Sollte nun aber mein Server ausfallen (Vorus befällt Server und macht Dateien, sowie Backup platt)! Ich habe noch einen Raspberry Pi 2 rumliegen. Den könnte ich in die zweite LAN Buchse meines Servers stecken, so dass er nicht mit dem normalen Netzwerk verbunden ist. rsync schreibt das Backup dann über einen eigenen Benutzer per ssh auf den raspberry pi. Ein cronscript entzieht dem Benutzer von rsync die Schreibrechte für fertige Backups. rsync kann dann weiterhin neue Backups anlegen und alte Backups lesend überprüfen, alte Backups allerdings nicht mehr Verändern.
Was denkt ihr, sinnvolle Variante, oder Lücken in meinen Überlegungen?
Vielen Dank für eure Hilfe
ich habe heute früh bei heise über die ChimeraMaleware gelesen, eine Software, die Dateien verschlüsselt und die Passphrase für Geld anbietet. In diesem Zuge habe ich generell über eine geeignete Backuplösung nachgedacht, um diesem Problem und Datenverlust im Allgemeinen vorzubeugen. Da ich in dieser Thematik neu bin, wollte ich eure Meinung zu meinen Überlegungen hören.
Momentaner Aufbau:
Meine Frau, ein guter Freund und ich haben alle wichtigen Daten in einem Ordner, der mit Hilfe von owncloud mit meinem Heimserver synchronisiert wird. Auf diesem Server läuft debian und ich betrachte diesen im folgenden als sicher und beschäftige mich mit Möglichkeiten, die Datenverlust bei Befall der Clienten zu verhindern. Gespeichert werden größtenteils Dokumente und einige Bilder. Die Größe des gesamten owncloud Verzeichnisses auf dem Server beträgt lediglich 8,9GB und wächst nur sehr langsam. Eine tägliche Sicherung würde in diesem privaten Anwendungsfall ausreichen. Die Daten sind serverseitig nicht verschlüsselt.
Angriffsszenario
Schadsoftware (oder auch Fehler seitens der Nutzer) löscht oder verschlüsselt Daten, die daraufhin verloren sind. Die Synchronisationssoftware überträgt diesen Datenstatus an den Server, auf dem die Daten dann ebenfalls gelöscht, oder durch verschlüsselte Container ersetzt werden.
Lösungsansatz:
Inkrementelles Backup!
Ein Vollständiges Backup belegt jeden Tag den Speicherbedarf des gesamten owncloud Verzeichnisses aufs Neue. Alte Backups sollte aber lange vorhanden sein, da Schadsoftware mitunter so programmiert ist, dass sie verschlüsselte Dateien über längere Zeit entschlüsselt und dem Nutzer die Manipulation der Daten nicht auffällt.Der Speicherbedarf ist dann aber zu groß!
Ein differentielles Backup tauscht veränderte Dateien aus. Manipulierte Dateien würden dazu führen, dass Originaldateien verloren gehen. Ebenfalls nicht geeignet!
Ein inkrementelles Backup speichert die Veränderten Dateien zum letzten Backup erneut ab. Manipulierte Dateien würden somit zusätzlich zu den Originaldateien gespeichert werden. Der Speicherbedarf wächst daher stetig, abhängig von der Frquenz der Veränderungen. Bei seltenen und kleinen Änderungen sollte der Speicherbedarf deutlich unter dem des Vollständigen Backups liegen.
Umsetzung unter debian:
rsync!
rsync führt das inkrementelle Backup durch. Unveränderte Daten werden per Hardlink gespeichert. Backups können somit zu beliebigen Zeitpunkten einfach durch Kopieren des Ordnerinhalts wiederhergestellt werden. Das Backup dann auf einen anderen Datenträger und fertig.
Schutz bei Kompromitierung des Servers:
Sollte nun aber mein Server ausfallen (Vorus befällt Server und macht Dateien, sowie Backup platt)! Ich habe noch einen Raspberry Pi 2 rumliegen. Den könnte ich in die zweite LAN Buchse meines Servers stecken, so dass er nicht mit dem normalen Netzwerk verbunden ist. rsync schreibt das Backup dann über einen eigenen Benutzer per ssh auf den raspberry pi. Ein cronscript entzieht dem Benutzer von rsync die Schreibrechte für fertige Backups. rsync kann dann weiterhin neue Backups anlegen und alte Backups lesend überprüfen, alte Backups allerdings nicht mehr Verändern.
Was denkt ihr, sinnvolle Variante, oder Lücken in meinen Überlegungen?
Vielen Dank für eure Hilfe
