staging.inyokaproject.org

Ich gebe zu, dass ich jetzt erst auf den Artikel und diese Diskussion gestoßen bin - da hätte ich viel früher mal nachschauen müssen. Und dabei bin ich wohl "schuld" daran, dass Vortex dirvish benutzt 😉

Erste Anmerkung zum Artikel: Der Kasten über den möglichen Konflikt zwischen "dirvish-expire" und "dirvish-runall" scheint mir nicht nur überflüssig, sondern völlig zu Unrecht abschreckend: Zumindest in Ubuntu 18.04 LTS enthält das mitgelieferte Skript "/etc/dirvish/dirvish-cronjob" die beiden Aufrufe strikt sequentiell in der Zeile

1

/usr/sbin/dirvish-expire --quiet && /usr/sbin/dirvish-runall --quiet

Zweite Anmerkung: Die Initialisierung des Vault durch die Option "--init" erfolgt nicht vor dem, sondern beim ersten Backup. Sie besteht ja nur darin, dass nicht für das Setzen der Hardlinks nach dem vorangegangenen Backup gesucht wird, sondern dass die erste Fassung "einfach so" (= ohne Hardlinks) angelegt wird.

Den Kasten finde ich nicht so sinnlos. Auch wenn das Skript expire und runall hintereinander ausführt, könnte ein optimierungswütiger Nutzer auf die Idee kommen, mit beiden gleichzeitig Zeit zu sparen. 😉

Zustimmung bei --init, zudem der Satz dem zweiten Absatz darunter widerspricht. Ich habe jetzt einfach das „Vor“ gegen „Mit“ ersetzt. (Dein „Beim“ wäre genauso gut gewesen, ich erinnerte mich beim Bearbeiten allerdings nicht mehr an Deine genaue Wortwahl. 😇)

Danke für die Anregungen. Ob Du an meiner dirvish-Nutzung „schuld“ bist, kann ich nicht mehr genau sagen. Ich vermute, Du bist der passionierte dirvish-Promoter von u.a. Ubuntu Berlin? Dann wäre es gut möglich. Aber es kann auch sein, dass ich ursprünglich durch die uu.de-Wiki draufkam. So oder so war es auf jeden Fall einer der wichtigsten Funde meines Linuxlebens. 😀

Du hast natürlich recht, dass ein Benutzer sich durch (Skript-Änderung und daraus resultierende) überlappende Ausführung von runall und expire selbst ins Knie schießen kann. Mein Gesichtspunkt war, dass der Kasten dem Leser Angst machen kann, da sei eine Schwachstelle. Egal, lassen wir das.

Als "Promoter" würde ich mich nicht bezeichnen, aber ja: Ich bin der mit dem Vortrag "Backup in Soho" bei (u.a.) Ubuntu Berlin. Nach wie vor bin ich mit dirvish zufrieden. Derzeit will ich endlich meine Automatisierung drumherum verbessern - darum meine Frage im Anwendungs-Forum.

Ich habe den Artikel unter Focal Fossa getestet (da ich sowieso dirvish wiederbeleben wollte): M.E. fehlt bei der Initialisierung der Sicherung ein 'sudo', da das Sicherungs-Verzeichnis vorher auch mit 'root'-Rechten angelegt wurde.

muelux@LT76A-T430:/etc/dirvish$ dirvish --vault LT76A_T430_home --init
LT76A_T430_home:default:20210208: cannot create /media/muelux/Virt_Images/backup/dirvish/laptop/LT76A_T430_home/dirvish/lock_file
 

Ich habe ein ausführliches Protokoll der Aktion (in meinem Wiki) angelegt, besteht Interesse / Platz, es hier zu posten? Bei nicht ganz so einfachen Verhältnissen (externe USB-FP, unter '/media...' gemountet, Laptop-Name nicht 'Netz'-konform...) tue ich mir immer noch schwer, die Zusammenhänge der Konfig-Dateien (anhand der Beispiele im Wiki, 'laptop', '/backup') zu durchblicken.

Beim ersten Lauf ('--init') habe ich auch noch den Parameter --dry-run angehängt; um zu sehen, was passieren würde:

muelux@LT76A-T430:/etc/dirvish$ dirvish --vault LT76A_T430_home --init --dry-run
client: LT76A-T430
tree: /home
rsh: ssh
Server: LT76A-T430
Bank: /media/muelux/Virt_Images/backup/dirvish/laptop/
vault: LT76A_T430_home
branch: default
Image: 20210208
Reference: default
Image-now: 2021-02-08 13:52:12
Expire: +3 months == 2021-05-08 13:52:12
Expire-rule: *       *       *       *       *       +3 months
exclude:
        lost+found/
        proc/
        core
        muelux/download
SET permissions devices init numeric-ids stats xdev 
UNSET checksum sparse whole-file zxfer 

Command-Args: --vault LT76A_T430_home --init --dry-run
Configfiles:
        /etc/dirvish/master.conf
        /media/muelux/Virt_Images/backup/dirvish/laptop//LT76A_T430_home/dirvish/default.conf
bank:
        /media/muelux/Virt_Images/backup/dirvish/laptop/
expire-default: never
expire-rule:
        *       *       *       *       *       +3 months
        *       *       *       *       1       never
image-default: %Y%m%d
index: gzip
no-run: 1
summary: short

ACTION: rsync -vrltH --delete --stats -x -D -pgo --numeric-ids --exclude-from=/media/muelux/Virt_Images/backup/dirvish/laptop//LT76A_T430_home/20210208/exclude /home/ /media/muelux/Virt_Images/backup/dirvish/laptop//LT76A_T430_home/20210208/tree
muelux@LT76A-T430:/etc/dirvish$ 
 

Viele Grüße, mue.de

Hallo mue!

Du hast recht, im Artikel ist eine Unstimmigkeit bei den Zugriffsrechten: Wenn das Verzeichnis mit "sudo" angelegt wird, dann werden andere Benutzer dort wohl nicht schreiben dürfen. Das sollte man aber nicht dadurch beheben, dass nun auch das Backup dorthin mit Root-Rechten gemacht wird - dann reicht ein kleiner Fehler in der Konfiguration, und der Backup überschreibt wichtige Sachen. Die Lösung ist, dass nach dem "sudo mkdir" durch ein "sudo chown" oder ein "sudo chmod" das Verzeichnis für den Backup-Benutzer beschreibbar gemacht wird.

Die Konfig-Dateien finde ich sehr übersichtlich:
- In "/etc/dirvish/master.conf" steht, wo die Bank liegt, und sonst nur Default-Werte.
- in "$BANK/$VAULT/dirvish/default.conf" steht, was dorthin gesichert werden soll (Maschine und Pfad), und die Vault-spezifischen Angaben (besonders zum Expire).
Gerade bei einem externen Laufwerk als Bank (sehr sinnvoll, um sie z.B. gegen Bediener-Fehler und etwaige Trojaner zu schützen) ist so sichergestellt, dass für jeden Vault die Konfiguration und der Inhalt zueinander passen (weil die Konfiguration ebenfalls im Vault liegt).

Ich benutze als Medien etliche externe USB-Platten und USB-Sticks, jede hat "DIRVISH/" als lokales oberstes Verzeichnis, sie werden immer unter "/mnt" gemountet. Also gibt es nur eine Bank-Angabe "/mnt/DIRVISH", und alles weitere steht im gerade benutzten Medium in "$VAULT/dirvish/default.conf".

In Deinem Init-Protokoll sehe ich nichts Falsches. Den Bank-Pfad finde ich überraschend lang, und das "laptop/" in der Bank zusammen mit dem "LT76A_T430_home/" im Vault scheint mir doppelt gemoppelt, aber Du wirst Deine Gründe haben.

Viel Erfolg! Jörg

Hallo Jörg,

danke für die Hinweise und Infos. Es muss, glaube ich doch mit 'root'-Rechten gesichert werden, da die Konfiguration die Sicherung des '/home'-Vz. (bzw. der Partition) beschreibt, die ja mehrere Benutzer enthalten könnte. Bei einem Einzelplatz-System wird es zwar nur einen geben, dies sollte man dann aber extra erwähnen? Oder habe ich etwas überlesen? Mit dem Hinweis auf das doppelt gemoppelte 'laptop' / 'LT76A_T430' hast Du recht, es war etwas zu kurz gesprungen...

Viele Grüße Ewald

P.S.: Ich habe mir mal ein Blockschaubild (s.u.) davon gemalt; ich weiß, daß das Wiki nicht Bild-lastig sein soll (und barrierefrei), aber vielleicht hilft es doch?

Hallo Ewald!

Die notwendigen Rechte hängen davon ab, wie rsync aufgerufen wird:

• Beim direkten Aufruf "rsync Quelle Ziel" muss der Aufrufer Lese-Rechte auf der Quelle haben.
  Wenn es sich um "/home" auf einem System mit mehreren Benutzern handelt, muss der Aufrufer also root-Rechte haben oder auch den Gruppen der anderen Benutzer angehören, das sieht dann so aus:

joerg@trift:~$ id uid=1000(joerg) gid=1000(joerg) Gruppen=1000(joerg),4(adm),...,1001(ute)

• Bei Benutzung des rsync-Dämons liest nicht der Aufrufer, sondern der Dämon, und der läuft meist als root.
  Im default.conf zeigt das der Doppelpunkt vor dem Modul-Namen (Auszug):

client: 192.168.0.60
tree: :home

Die Konfiguration für den Dämon ist in /etc/rsyncd.conf (Auszug):

read only = true
hosts allow = 192.168.0.56 192.168.0.60
[home]
path = /
comment = Home directories of the local users
uid = 0
gid = 0
include = /home/ /home/joerg/ /home/ute/ /home/STATUS/ /home/lost+found/ - /* - /home/* - /home/*/.thumbnails/ - /home/**/Cache/ ...

In jedem Fall braucht der Aufrufer Schreibrechte im Ziel, aber das ist ja kein Problem. Der rsync-Dämon ist nicht trivial ("man rsyncd.conf"!), da wirst Du einige Versuche brauchen bis zur richtigen Konfiguration, aber es lohnt sich. Auf diese Weise kann ich mein ganzes System sichern, auch Dateien mit Lese-Recht nur für root, ohne dirvish als root zu starten.

Viel Spaß beim Experimentieren! Jörg

Ou, ou,

da gibt's ja noch einiges an unbekanntem Terrain zu erforschen!

Arbeit macht ja Spaß, aber wer kann soviel Spaß vertragen? 😉 Und dabei glaubte ich, nach meiner Odyssee über rsync, rsnapshot, duplicity, duplicati, owncloud, SparkleShare, OpenMediaVault endlich das passendste Backup-Werkzeug gefunden zu haben (wenn mir auch bei duplicati die Verschlüsselung und die Aufteilung in z.B. 50MB große Häppchen gut gefallen haben). Den ersten Artikel über Dirvish (c't 6/'07, S.212) habe ich noch vor mir ('Der mit der Platte tanzt'); so langsam sollte ich bei einem Backup-System bleiben. 😉

Na ja, es wird mir wohl nie langweilig! Ich werde mich mal da durchwurschteln.

Viele Grüße Ewald

Um das Ganze mal abzuschließen: Der derzeitige Artikel funktioniert auch in 20.04 und kann m.E. ein [[Vorlage(Getestet, Focal)]] erhalten.

Hinsichtlich der Rechte würde ich (kein Synonym für „jemand“, also durchaus ich selbst 😉) das Anwendungsbeispiel im Artikel auf eine Sicherung mit normalen Benutzerrechten umschreiben und in einem Hinweiskasten auf die Anwendungsfälle hinweisen, bei denen Rootrechte benötigt werden.

Ohne Veto bis morgen Abend mache ich das dann in der kommenden Woche.

Hallo,

das Anwendungsbeispiel im Artikel auf eine Sicherung mit normalen Benutzerrechten umschreiben und in einem Hinweiskasten auf die Anwendungsfälle hinweisen, bei denen Rootrechte benötigt werden.

+1

Gruß, noisefloor

Hallo,

V_for_Vortex schrieb: [...]

Ohne Veto bis morgen Abend mache ich das dann in der kommenden Woche.

von mir aus gerne, ich kam einige Tage nicht dazu, weiterzumachen, sorry. Außerdem hätte ich gerne jemandem mit fundierterem Wissen den Vortritt gelassen, den Artikel umzuschreiben.

Grüße

Ewald