vServer backupen per rsync auf NAS. Root-Rechte?

[stefkey]

Hallo,

ich möchte verschiedene Verzeichnisse von meinem vServer gerne auf mein NAS zuhause backupen. Das NAS bietet eine App dafür. Das Backup wird per rsync gezogen. Ich habe für das Backup auf meinem vServer einen Benutzer angelegt. Nun kann dieser Benutzer aber zB nicht das Verzeichnis /var/vmail lesen um Mails zu sichern. Als root soll sich das NAS nicht mit dem Server verbinden.

Wie kann ich dem User Leserechte auf alles geben?
usermod -aG root backupuser

Es ist ein Ubuntu 16.04

Edit: Das Backup auf dem Server per rsync starten und zur NAS senden funktioniert, will es aber auch mal wie oben beschrieben testen.

 

[Deleted member 11740]

root@miranda ~ # ls -l /var/
total 44
drwxr-xr-x  2 root root  4096 Aug 27 06:25 backups
drwxr-xr-x  7 root root  4096 Jul 12  2017 cache
drwxr-xr-x  2 root root  4096 Feb 19  2017 empty
drwxr-xr-x 34 root root  4096 Aug  7  2017 lib
drwxrwsr-x  2 root staff 4096 Jul 20  2014 local
lrwxrwxrwx  1 root root     9 Oct 10  2014 lock -> /run/lock
drwxr-xr-x 10 root root  4096 Aug 27 06:25 log
drwxrwsr-x  2 root mail  4096 Jul  5  2017 mail
drwxr-xr-x  2 root root  4096 Oct 10  2014 opt
lrwxrwxrwx  1 root root     4 Oct 10  2014 run -> /run
drwxr-xr-x  6 root root  4096 Jan 28  2017 spool
drwxrwxrwt  8 root root  4096 Aug 27 11:09 tmp
drwxr-xr-x  4 root root  4096 Apr  4  2017 www

Bei Debian 9.5 hat die Gruppe mail vollen Zugriff.

usermod -G mail backupuser

Das sollte den User auch aus allen Gruppen entfernen und nur zur Gruppe mail hinzufügen.

Am besten mal nachsehen, zu welchen Gruppen die Unterverzeichnisse in mail gehören und welche Attribute gesetzt sind.

Ich vermute, dass das nicht alles gewesen ist. GGf. müssen noch Konfigurationen vom Mailserver angepasst werden. Schau mal einfach nach, welche Unterverzeichnisse in /var/mail sind. Ich habe keinen funktionierenden Mailserver (bin ich froh drüber).

 

[stefkey]

Vielen Dank. Das werde ich anschauen. Und wenn es in andern Verzeichnissen noch Zugriffsprobleme hat?
Z.B. /etc/shadow

Den Backupuser dann in die Gruppe root nehmen könnte problematisch werden, oder?

 

[Firewire2002]

Den Backupuser dann in die Gruppe root nehmen könnte problematisch werden, oder?

Auch das wird dir nicht auf alles Leserechte geben. Selbst wenn du ihn in alle vorhandenen Gruppen hineinpacken würdest, könntest du immer noch nicht alles lesen, weil es unter Garantie Datein und/oder Verzeichnisse gibt, die nur Rechte für den Eigentümer aber nicht für die Gruppe gesetzt haben.

Wenn du ein vollständiges Backup machen willst, kommst du um den Root-Account nicht drum herum.

 

[sbr2d2]

Backupverzeichnis auf dem Server anlegen auf dass das NAS leserechte hat. In dem legst Du das aktuelle Backup ab und holst es per rsync ab. Danach wieder löschen oder für inkrementelle Backups liegen lassen. Kann sein das Du für einige Dateien die Rechte anpassen mußt.
Alternativ kannst Du auch ein Backupscript vom Server aus auf das NAS zugreifen lassen. Wäre wahrscheinlich etwas einfacher und du mußt nicht lange rumfricklen mit Dateirechten usw.

 

[stefkey]

Danke an alle.

@sbr2d2: Leider hats nicht genug Platz dafür auf dem vServer. Und Backup-Script auf dem Server starten und aufs NAS senden klappt prima. Wollte es halt mal gerne andersrum haben, weil die Backup App auf dem NAS das schon schön macht wie die Apple TimeMachine. (Tägliches Backup ein Monat zurück und wöchentliches Backup wenns länger zurückliegt usw.)

@Firewire2002: Okay, ja, Backup mit root-rechten ist wohl erforderlich.

 

[d4f]

nd Backup-Script auf dem Server starten und aufs NAS senden klappt prima. Wollte es halt mal gerne andersrum haben, weil die Backup App auf dem NAS das schon schön macht wie die Apple TimeMachine.

Abseits von Bequemlichkeit gibt es noch einen sehr wichtigen Faktor warum man Backups pullen (Nas loggt auf Server ein) statt pushen (Server loggt auf Nas ein) soll.

Dein Backup ist die letzte Instanz zur Wiederherstellung. Wenn die Ursache der Backup-Notwendigkeit ein kompromittierter Server (gehackt, Cryptotrojaner, ...) ist, dann besteht eine gewisse Wahrscheinlichkeit dass der Angreifer vom Server auf das NAS zugreift und eigentlich unbehelligte Backups unbrauchbar macht oder manipuliert. Bei Pull müssen dagegen zwei unabhängige Systeme an zwei unterschiedlichen Standorten mit unterschiedlichen Unterbauten betroffen sein was durchaus unwahrscheinlich ist.
In diesem Fall bräuchtest du, zumindest für das Backup, auch keinen Port-Forward was Direktzugriff durch Dritte von aussen auf deinen NAS verhindert.

Security/Reliability by design ist generell etwas aufwendiger auf zu setzen aber dafür eine langfristig angenehme Lösung.

 

[greystone]

Ja. Das Backup Nur-Lesend zu halten ist eine grundsätzliche Empfehlung bei der Organisation der Datensicherung. Das war auch schon vor CryptoTrojanern so. Die CryptoTrojaner sind nur mal wieder eine schönes Beispiel für diese Notwendigkeit.

 

[stefkey]

@d4f Wunderbar. Danke! Ich hatte auch im Gefühl das "pullen" besser sei. Aber nachgedacht über einen konkreten Grund habe ich nicht. Stimmt ja sowas von! Danke sehr!

Ok, d.h. ich logge mich halt als root vom NAS aus ein. D.h. ich hinterlege auf dem NAS mein Schlüssel vom root. Uiiiiihhh
Ok, das NAS ist aber gepflegt.

Wäre es besser einen Benutzer auf dem vServer zu erstellen mit root-Rechten?
Wäre so etwas angebracht:
adduser backupuser sudo

@greystone: okay, beim Restore ist dann auch alles nur noch lesend?

 

[greystone]

@greystone: okay, beim Restore ist dann auch alles nur noch lesend?

Nein. Damit ist gemeint, dass die gesicherten Daten auf dem Sicherungsmedium bzw. in der Sicherungsumgebung nur lesend zugreifbar sind und damit gegen versehentliches Löschen, Softwarefehler und Schadsoftware geschützt.

Das kann man natürlich wie alles sehr weit treiben. Im Endeffekt handhabe ich das selbst aber auch nur mit dem Pull-Mechanismus, wie von d4f empfohlen, so dass man vom zu sichernden System oder allgemein von aussen keinen schreibenden Zugriff auf das Backup hat.

Im Windows Umfeld hatte ich das mal so umgesetzt, dass es da noch eine Freigabe gab, mit der jeder Nutzer auf die Datensicherung - aber eben nur lesend - zugreifen kann um seine eigenen Daten ggf. wiederherstellen zu können.

 

[d4f]

Wäre so etwas angebracht:
adduser backupuser sudo

Davon abgesehen dass es Backups verkompliziert, bringt das dir kaum Vorteile, ausser du könntest sicherstellen dass der Sudo-Benutzer nur Zugriff auf eine read-only rsync-Binary hätte.
Bei normalem rsync könnte er die sudoers überschreiben und hat -tadaa- schon Vollzugriff.

 

[stefkey]

ich danke allen. Dann halt rsync vom NAS aus starten und als root mit Key einloggen. Muss nur leider die Passphrase aus dem Key nehmen weil die Software nur Keys ohne Passphrase nimmt

 

[Deleted member 11740]

Vielleicht kennen das schon einige: https://borgbackup.readthedocs.io/en/stable/

Ich habe diese Software bis jetzt noch nicht getestet, sieht aber vielversprechend aus. Theoretisch könntest du damit auch zur NAS sichern. Was dir dann noch fehlt, ist eine statische IP, was du mit dyndns umgehen könntest. Ob du diesen Service auch auf der NAS installieren kannst, um Backups zu ziehen, hängt von der NAS ab. Ansonsten pusht der Server das Backup auf die NAS.