Backup - Pfade der Repo / Neues Backup / Umfangreichere Betrachtung...
Posted: Wed 8. Sep 2021, 11:40
Hallo in die Runde,
nachdem ich unterschiedliche Szenarien für / mit den Backupfunktionen durchgespielt habe, stellen sich mehrere Probleme / Fragen.
Die Doku zum Keyhelp gibt als Verzeichnisstruktur für die "alte" Backupfunktion eine sinnvolle Struktur wieder, die erlaubt, alle Backups komplett auf bspw. einen NFS-Mount eines externen Servers auszulagern (Verzeichnis /backup/ auf NFS-Mount verlinken bspw.) und alle User-Backups laufen dorthin und es entsteht kein Problem mit abgebrochenen Backups wegen Speicherplatzüberlauf des lokalen Laufwerkes, versursacht durch User, deren Datenplatzbelegung über 50% des freien Speicherplatzes des lokalen Volumes liegt (gut - inwiefern es sinnvoll ist / war, alle Userdaten in ein Archiv zu packen ist ne andere Frage...ich finde getrennte Archive nach Mail, Datenbanken und Webverzeichnissen sinnvoller) - der User kann sich das / die Archive herunterladen und halt die Backups in seine eigene Verantwortung nehmen / man kann sie als Serverbetreiber in die ausschließliche Verantwortung des Users legen.
Nun ist ja aber beim neuen Backupsystem ein vollkommen anderer Ansatz da - prinzipiell sind Userbackups generell in der Verantwortung des Serverbetreibers oder der User muss sich selbst um externen Speicher kümmern. Bei Nutzung einer lokalen Repository läuft der verfügbare lokale Datenspeicherplatz in jedem Falle voll, wenn der vom User belegte Speicherplatz mehr umfasst, als freier Speicherplatz auf dem lokalen Volume vorhanden ist - die Erstsicherung auch vom restic umfasst ja in jedem Falle alle Daten des Users als einmaliges "Abbild"...es wird (nach meinem Kenntnisstand) nur der Cache der Repo in den Ordner /backup/<username> gespeichert, die Repo und die Sicherungsdaten als solches liegt physikalisch in /home/users/<username>/files/<dirname> gespeichert.
Es ist also nicht mehr möglich, ohne jedes Userdir manuell anfassen zu müssen bspw. die Usersicherungen auf einen externen Mount zu bekommen.
Ausserdem ist der User nun nicht mehr in der Lage, die Sicherung bei sich im Hause lokal vorzuhalten - das ist für manche Fälle ein Sicherheitskriterium und grundlegende Voraussetzung, ausserdem ist es für den Serverbetreiber (also hier für mich) ein Problem in Bezug auf die DSGVO und das BDSGneu...und ab Dez. 2021 dann noch in Bezug auf das TMGneu.
Wenn die Datensicherung ausschließlich in meiner Verantwortung liegt (was ja dadurch dann der Fall wäre/ist, weil ich a) dafür sorge tragen muss, dass die lokale Sicherung nochmal irgendwo von mir auf meine Kosten gesichert wird, weil ich die Datenintegrität sicherstellen muss und b) ich dem User auf meine Kosten und ohne Aufwandsentschädigung eine Möglichkeit bieten muss, die Daten für ihn in nuzbarer und ggf. bei ihm lokal wiederherstellbarer Form zur Verfügung zu stellen wenn ich nicht direkt Verantwortlicher oder Auftragsverarbeiter im Sinne der DSGVO ) ist das imho nicht sinnvoll.
Und es müsste dann mindestens ein AAV abgeschlossen werden - weil ja der User nicht mehr selbst verantwortlich ist; wenn es nicht sogar in die Richtung "gemeinschaftliche Verantwortlichkeit" geht (DSGVO-Sicht - Verantwortlichkeit aus dem dann BDSG ohnehin)
Ist es irgendwie möglich, dass die Möglichkeit geschaffen wird (oder dass es bei Anlage und Nutzung von lokaler Repo) diese wieder wie bisher in den Ordner /backup/users/<username> gelegt wird und darüberhinaus eine Möglichkeit / Auswahl geschaffen wird, die einzelnen Bereiche Datenbank, Maildomain, Userweb jeweils getrennt in ein Archiv (tar.gz) pro Snapshot zu packen und wie im alten Backupsystem dem User zum Download zur Verfügung zu stellen?
Aus meiner Sicht auf Datenschutzrelevanz ist der aktuelle Zustand ein K.O.-Kriterium für Keyhelp beim Einsatz auf Multiusersystemen mit unterschiedlichen Verantwortlichen (also Kunden / Usern) im Sinne der DSGVO/BDSG/TMG.
Als Hoster will man sicher nicht in die Verantwortung genommen werden, das wäre aber im vorligenden Falle bspw. bei einer Auskunftsanfrage eines MA eines Kunden nach den verarbeiteten pers. Daten (bspw. Mail und deren Sicherungen) der Fall. Da spielt es keine Rolle, dass die Daten verschlüsselt auf dem Server liegen - ausserdem ist die Datenintegrität/Datensicherheit durch den Domain- bzw. Keyhelp-User nicht zu gewährleisten, wenn er nicht noch einen zusätzlichen externen Speicher für die Backup-Repo betreibt (wozu ein User, der keinen Server selbst betreiben will meist nicht in der Lage ist und das nicht noch zusätzlich extern in Auftrag geben möchte).
Ergo - wenn das "alte" Backup wegfällt und das "neue" den jetzigen Stand beibehält, ist Keyhelp obsolet für "Gefälligkeits-Hoster" wie das bei mir der Fall ist. Das Risiko von Regressansprüchen und Datenschutzansprüchen steigt ins unüberschaubare...bzw,. der zu betreibende Aufwand pro User übersteigt den Rahmen des bei weitem.
Bitte - nicht falsch verstehen - ich meckere nicht rum und ich fordere nichts für lau - das ist auch kein UmJedenPreisKritisieren oder an allem Rummeckern (meine paar "kritischen" Kunden krieg ich sicher auch selbst per Script in downloadbare Archive), aber es soll einfach mal eine andere Sichtweise vermitteln...auch in Bezug auf Konsequenzen und Notwendigkeiten, die bei bestimmten Verfahren entstehen....
Mal kurz noch vermerkt, dass Elkar-Backup aktuell keine Alternative ist, eine festgestellte Sicherheitslücke hat die Entwickler veranlasst, die Nutzerverwaltung zu deaktivieren, es gibt im Elkar "nur" noch User mit Adminrechten, also für eine Verwaltung von Mulitusersytemen nicht (mehr) so richtig geeignet...
Vielleicht ein kurzer Verweis noch auf das tote iMSCP, dort ist das mit den Backups irgendwie imho recht gut gelöst gewesen, der User konnte per FTP sein automatisch erstelltes tägliches Backup (getrennte Archive nach DB / Mail / Webverzeichnis) downloaden und war so einfach selbst verantwortlich...
Und bitte - nicht jetzt wieder "dann bleib doch bei iMSCP" als beleidigte Antwort von irgendjemand, einfach mal Argumentationen anhören und vielleicht drüber nachdenken...und sachlich auf möglicherweise erkannte Denkfehler reagieren...Die Kultur der Diskussion und Suche nach Lösungen verkümmert leider immer mehr...
Viele Grüße aus dem aktuell sonnigen Erzgebirge
hempelr
----
Mod-Edit: Verschoben, da es hier im Folgenden darum geht, das Backup-System auf eine eigene Konfiguration umzubiegen.
nachdem ich unterschiedliche Szenarien für / mit den Backupfunktionen durchgespielt habe, stellen sich mehrere Probleme / Fragen.
Die Doku zum Keyhelp gibt als Verzeichnisstruktur für die "alte" Backupfunktion eine sinnvolle Struktur wieder, die erlaubt, alle Backups komplett auf bspw. einen NFS-Mount eines externen Servers auszulagern (Verzeichnis /backup/ auf NFS-Mount verlinken bspw.) und alle User-Backups laufen dorthin und es entsteht kein Problem mit abgebrochenen Backups wegen Speicherplatzüberlauf des lokalen Laufwerkes, versursacht durch User, deren Datenplatzbelegung über 50% des freien Speicherplatzes des lokalen Volumes liegt (gut - inwiefern es sinnvoll ist / war, alle Userdaten in ein Archiv zu packen ist ne andere Frage...ich finde getrennte Archive nach Mail, Datenbanken und Webverzeichnissen sinnvoller) - der User kann sich das / die Archive herunterladen und halt die Backups in seine eigene Verantwortung nehmen / man kann sie als Serverbetreiber in die ausschließliche Verantwortung des Users legen.
Nun ist ja aber beim neuen Backupsystem ein vollkommen anderer Ansatz da - prinzipiell sind Userbackups generell in der Verantwortung des Serverbetreibers oder der User muss sich selbst um externen Speicher kümmern. Bei Nutzung einer lokalen Repository läuft der verfügbare lokale Datenspeicherplatz in jedem Falle voll, wenn der vom User belegte Speicherplatz mehr umfasst, als freier Speicherplatz auf dem lokalen Volume vorhanden ist - die Erstsicherung auch vom restic umfasst ja in jedem Falle alle Daten des Users als einmaliges "Abbild"...es wird (nach meinem Kenntnisstand) nur der Cache der Repo in den Ordner /backup/<username> gespeichert, die Repo und die Sicherungsdaten als solches liegt physikalisch in /home/users/<username>/files/<dirname> gespeichert.
Es ist also nicht mehr möglich, ohne jedes Userdir manuell anfassen zu müssen bspw. die Usersicherungen auf einen externen Mount zu bekommen.
Ausserdem ist der User nun nicht mehr in der Lage, die Sicherung bei sich im Hause lokal vorzuhalten - das ist für manche Fälle ein Sicherheitskriterium und grundlegende Voraussetzung, ausserdem ist es für den Serverbetreiber (also hier für mich) ein Problem in Bezug auf die DSGVO und das BDSGneu...und ab Dez. 2021 dann noch in Bezug auf das TMGneu.
Wenn die Datensicherung ausschließlich in meiner Verantwortung liegt (was ja dadurch dann der Fall wäre/ist, weil ich a) dafür sorge tragen muss, dass die lokale Sicherung nochmal irgendwo von mir auf meine Kosten gesichert wird, weil ich die Datenintegrität sicherstellen muss und b) ich dem User auf meine Kosten und ohne Aufwandsentschädigung eine Möglichkeit bieten muss, die Daten für ihn in nuzbarer und ggf. bei ihm lokal wiederherstellbarer Form zur Verfügung zu stellen wenn ich nicht direkt Verantwortlicher oder Auftragsverarbeiter im Sinne der DSGVO ) ist das imho nicht sinnvoll.
Und es müsste dann mindestens ein AAV abgeschlossen werden - weil ja der User nicht mehr selbst verantwortlich ist; wenn es nicht sogar in die Richtung "gemeinschaftliche Verantwortlichkeit" geht (DSGVO-Sicht - Verantwortlichkeit aus dem dann BDSG ohnehin)
Ist es irgendwie möglich, dass die Möglichkeit geschaffen wird (oder dass es bei Anlage und Nutzung von lokaler Repo) diese wieder wie bisher in den Ordner /backup/users/<username> gelegt wird und darüberhinaus eine Möglichkeit / Auswahl geschaffen wird, die einzelnen Bereiche Datenbank, Maildomain, Userweb jeweils getrennt in ein Archiv (tar.gz) pro Snapshot zu packen und wie im alten Backupsystem dem User zum Download zur Verfügung zu stellen?
Aus meiner Sicht auf Datenschutzrelevanz ist der aktuelle Zustand ein K.O.-Kriterium für Keyhelp beim Einsatz auf Multiusersystemen mit unterschiedlichen Verantwortlichen (also Kunden / Usern) im Sinne der DSGVO/BDSG/TMG.
Als Hoster will man sicher nicht in die Verantwortung genommen werden, das wäre aber im vorligenden Falle bspw. bei einer Auskunftsanfrage eines MA eines Kunden nach den verarbeiteten pers. Daten (bspw. Mail und deren Sicherungen) der Fall. Da spielt es keine Rolle, dass die Daten verschlüsselt auf dem Server liegen - ausserdem ist die Datenintegrität/Datensicherheit durch den Domain- bzw. Keyhelp-User nicht zu gewährleisten, wenn er nicht noch einen zusätzlichen externen Speicher für die Backup-Repo betreibt (wozu ein User, der keinen Server selbst betreiben will meist nicht in der Lage ist und das nicht noch zusätzlich extern in Auftrag geben möchte).
Ergo - wenn das "alte" Backup wegfällt und das "neue" den jetzigen Stand beibehält, ist Keyhelp obsolet für "Gefälligkeits-Hoster" wie das bei mir der Fall ist. Das Risiko von Regressansprüchen und Datenschutzansprüchen steigt ins unüberschaubare...bzw,. der zu betreibende Aufwand pro User übersteigt den Rahmen des bei weitem.
Bitte - nicht falsch verstehen - ich meckere nicht rum und ich fordere nichts für lau - das ist auch kein UmJedenPreisKritisieren oder an allem Rummeckern (meine paar "kritischen" Kunden krieg ich sicher auch selbst per Script in downloadbare Archive), aber es soll einfach mal eine andere Sichtweise vermitteln...auch in Bezug auf Konsequenzen und Notwendigkeiten, die bei bestimmten Verfahren entstehen....
Mal kurz noch vermerkt, dass Elkar-Backup aktuell keine Alternative ist, eine festgestellte Sicherheitslücke hat die Entwickler veranlasst, die Nutzerverwaltung zu deaktivieren, es gibt im Elkar "nur" noch User mit Adminrechten, also für eine Verwaltung von Mulitusersytemen nicht (mehr) so richtig geeignet...
Vielleicht ein kurzer Verweis noch auf das tote iMSCP, dort ist das mit den Backups irgendwie imho recht gut gelöst gewesen, der User konnte per FTP sein automatisch erstelltes tägliches Backup (getrennte Archive nach DB / Mail / Webverzeichnis) downloaden und war so einfach selbst verantwortlich...
Und bitte - nicht jetzt wieder "dann bleib doch bei iMSCP" als beleidigte Antwort von irgendjemand, einfach mal Argumentationen anhören und vielleicht drüber nachdenken...und sachlich auf möglicherweise erkannte Denkfehler reagieren...Die Kultur der Diskussion und Suche nach Lösungen verkümmert leider immer mehr...
Viele Grüße aus dem aktuell sonnigen Erzgebirge
hempelr
----
Mod-Edit: Verschoben, da es hier im Folgenden darum geht, das Backup-System auf eine eigene Konfiguration umzubiegen.