backup als nicht root-user

[thorben]

moin,
ich würde gerne einen rechner remote sichern mit rsnapshot. prinzipiell kein problem, rsnapshot loggt sich mit public-key per ssh ein und kopiert alle relevanten dateien. scheitern tue ich aber an dateien, die die benutzer nicht lesbar für andere gemacht haben (700 / 600).

ich möchte eigentlich kein root login auf dem rechner erlauben und trotzdem alle daten lesen. gibts da irgend einen workaround? ich hätte es mit dem backup benutzer probiert zu dem in /usr/share/doc/base-passwd/users-and-groups.txt.gz folgendes zu lesen ist

backup

Presumably so backup/restore responsibilities can be locally delegated to
someone without full root permissions?

HELP: Is that right? Amanda reportedly uses this, details?

ich bin also auf der suche nach einem "backup-operator" wie im windows.

gruß
thorben

[Geier0815]

Du brauchst auch keinen root-login zu erlauben um als user ein su abzusetzen. Danach dann dein gewünschtes Programm ausführen.

[Meillo]

Du brauchst auch keinen root-login zu erlauben um als user ein su abzusetzen.

Hat nur das Problem, dass das Backup dann interaktiv ist und nicht automatisiert werden dann (es sei denn, man legt das Passwort irgendwo ab).

Vermutlich funktioniert das aber auch deshalb nicht, da `rsnapshot' den Login vornimmt, und nicht der User.

Du könntest aber per root-cron auf dem Server alle Daten in ein Tar packen und das dann syncronisieren.

[thorben]

das würde beides das konzept vom meinem backup zunichte machen. ich will einen zentralen rechner, der sich von allen rechnern die daten holt. tar ist blöd zum restore und der rsync vorteil wäre auch dahin.

habs jetzt einfach mit root login per public key auf eine ip adresse eingeschränkt, das muss reichen.

bin aber nach wie vor an alternativen interessiert

gruß
thorben

[deadeye]

tar ist blöd zum restore und der rsync vorteil wäre auch dahin.

AFAIK stimmt das nicht. rsync kann sowohl tarballs syncen, also besser gesagt deren Inhalt. Ich habe das mal irgendwo gelesen, vermutlich in

Code: Alles auswählen

man rsync

[thorben]

moin,
hab grad mal die manpage durchsucht und mir wäre nix aufgefallen. angesichts der tatsache, dass tar streamkomprimierung verwendet kann ich es mir kaum vorstellen. aber selbst wenn, finde ich das eine bastellösung die beim restore nur lästig ist.

wenn ich schnell mal eine datei herstellen will, möchte ich nicht erst ein tar archiv entpacken, das ist nervig.

gruß
thorben

[Snoopy]

Hi

Ich habe auf meinem Server zu Hause backuppc laufen.
Das Teil kann man so einstellen, dass wenn ein Rechner eine Weile zur Verfügung steht (Abfrage per ping usw) automatisch eine Datensicherung (inkrementell oder Full...wie man es mag) angetriggert wird.

Soll heissen, der Server holt sich dann die Daten von der Wkst. und legt diese in einen Pool ab.

Sofern ich das richtig verstanden habe, ist dieser Pool für Alle Daten. Wenn also RechnerA eine Datei1 und RechnerB ebenfalls eine Datei1 hat, wird die einmalig auf dem Server abgelegt und dementsprechend intern "verlinkt".
Diese "Sortierung der Daten" erfolgt einmal pro Nacht auf dem Server, es wurde automatisch ein Cronjob angelegt, der das startet.

Manuelle Datensicherungen sind sicherlich ebenfalls möglich. Das kann man einfach (wie der Restore) über WebBrowser machen...

Als Vorgehensweise stehen tar und rsync zur Verfügung...

Einziges Problem (bzw was nun im krassen Gegenteil zu dem Topic steht)...das Teil werkelt als Root-User...

[audiolinux]

moin,

könnte man nicht auf den Clients mit ACL's arbeiten?

Man würde pro Client einen User anlegen, der die zu sichernden Dateien lesen darf. Mehr nicht. Und genau dieser User meldet sich dann per Key im rsync-Prozess von Backuppc an und schiebt die Daten auf den Backupserver ...

Was haltet ihr davon?

Gruß

Sebastian

[ckoepp]

Macht Sinn...das ist ein Fall für eine feingranulare Rechtevergabe. Mit ACL sollte es kein Problem mehr sein das Problem zu lösen.

Das Problem liegt ja nicht an irgendeiner Software, sondern an den Rechten. Irgendwo muss immer root werkeln zum Backup.

[audiolinux]

So theoretisch läuft die Sache mit den ACLs schon ganz gut.
Allerdings habe ich noch Probleme mit den Leseberechtigungen.

das Szenario:

Es gibt einen Backup-Benutzer namens "backuppc"
Ich habe ein Verzeichnis für die Profildaten der Netzwerkbenutzer:

netlogon/profiles

die Rechte sind dort wie folgt gesetzt

# file: profiles
# owner: root
# group: users
user::rwx
group::rwx
other::---
default:user::rwx
default:user:backuppc:r-x
default:group::rwx
default:rwx
default:other::---

blöder weise hat nun "backuppc" keinen Zugriff mehr auf dieses Verzeichniss.

Liegt das an der Default-Einstellung für other?
Ich will aber nicht allen anderen Lese und ausführ-Rechte geben, sondern ausschließlich dem Benutzer "backuppc"

[kultviech]

Der Thread steht zwar schon ein bischen, aber ich stehe eigentlich vor der gleichen Problematik.

Was mir zu dem oben gesagten - einen root-login auf dem zu sichernden Server per ssh zur Verfügung stellen zu müssen - nicht gefällt, ist, das ich auch auf dem Backupserver das Backup-Script mit root-rechten laufen lassen muß, damit auf dem Backupsystem die Dateien mit den richtigen uids/gids abgespeichert werden können. Damit hole ich mir eine Menge Software auf den Backuprechner, die ich da eigentlich gar nicht ausführbar haben möchte.

Eine Überlegung von mir wäre:

- Man macht eine lokale Sicherung oder Daten in eine Backup-Verzeichnis (mach ich sowieso, weil es praktisch ist, im Zweifelsfalle die rückzusichernden Daten nicht durchs Neitz nudeln zu müssen).
- Die Besitzer:Gruppe im Backupverzeichnis werden auf einen Backupuser geändert, die Rechte auf nur lesend gesetzt, damit gesicherte Software nicht ausführbar ist
- Der Remote-Backup-Client synct das Backupverzeichnis
- Man bräuchte nun ein Script, das die Orginal-Benutzer und -rechte in ein File schreibt und welches im Restore-Fall die Rechte wieder richtig zurückschreibt.

Kommt mir eigentlich recht logisch vor, deshalb wundere ich mich, das es das in der Form nicht gibt. Oder gibts das doch? Ist das eine gute Idee? Oder hab ich irgendetwas übersehen?

Grüße Axel

[schwedenmann]

hallo

Ev. ist mein vorschlag ja Schwachsinn, abr was ist, wenn man das backupscript als root im terminal aufruft, ich muß das so bei meinem Backup machen, da ich die Quell-Partitionen im Script mounten muß.
das sollte doh auch in inem bckupscript per ssh funktionieren.


mfg
schwedenmann

[audiolinux]

...wenn man das backupscript als root im terminal aufruft, ich muß das so bei meinem Backup ...

Aber dann muss sich doch root wieder am System authentifizieren (Passwortabfrage). Oder verstehe ich Dich falsch?

[audiolinux]

Hallo Axel,
dein Vorschlag gefällt mir. Das Skript kann man einfach mit dem Befehl

Code: Alles auswählen

getfacl -R * > acl-sicherung.txt

bauen. Um die Rechte nach einem Recovery neu zu setzen, müsste man nur wieder

Code: Alles auswählen

setfacl < acl-sicherung.txt

ausführen.

- Man bräuchte nun ein Script, das die Orginal-Benutzer und -rechte in ein File schreibt und welches im Restore-Fall die Rechte wieder richtig zurückschreibt.