• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[Gelöst] Backup von /snap

f.gruber

Hacker
Hallo,
ich mache die Datensicherung eines Servers im Internet mit einem Script per rsync.
Ich habe das Verzeichnis /snap bisher nie wirklich beachtet. Aber rsync hat mir jetzt folgendes gemeldet:

Code:
skipping non-regular file "snap/core20/1242/dev/null"
skipping non-regular file "snap/core20/1242/dev/random"
skipping non-regular file "snap/core20/1242/dev/urandom"
skipping non-regular file "snap/core20/1242/dev/zero"

Eine Möglichkeit wäre natürlich, alle dev/ Verzeichnisse zu excluden ...

Ich möchte aber gerne wissen, wie ich mit dem Verzeichnis /snap bezüglich der Sicherung umgehen soll. Das Verzeichnis /snap habe ich anscheinend dem Letsencrypt Projekt zu verdanken. Sonst wüßte ich nicht, wozu ich auf dem Server Snap-Pakete brauche.

Hier der Inhalt von /snap:
Code:
drwxr-xr-x 2 root root 4096  8. Dez 09:16 bin
drwxr-xr-x 4 root root 4096  8. Dez 09:16 certbot
drwxr-xr-x 4 root root 4096  8. Dez 09:16 core20
-r--r--r-- 1 root root  548  5. Feb 2021  README
drwxr-xr-x 4 root root 4096 22. Nov 15:49 snapd

Was soll man von diesem Verzeichnis sichern und was nicht? Muss man das Verzeichnis /snap überhaupt sichern?

Im Verzeichnis
Code:
/snap/core20/1270
sehe ich z.B., dass da eigentlich das ganze Wurzelverzeichnis (/) aufscheint. Manche der hier aufgelisteten Unterverzeichnisse sind aber leer, z.B homes. Blicke da nicht durch.

Danke für Infos.
 

josef-wien

Ultimate Guru
"Snap" kann auch in der Datenverarbeitung alles und nichts sein: https://en.wikipedia.org/wiki/Snap. Bei https://en.wikipedia.org/wiki/Let%27s_Encrypt lese ich nichts davon.

Was zeigt:
Code:
cat /proc/self/mountinfo
Code:
cat /snap/README


P. S. Die fiktiven Verzeichnisse /dev, /proc und /sys befinden sich im Hauptspeicher und werden bei jedem Systemstart neu erstellt. Auch /run ist oft im Hauptspeicher zu finden.
 
OP
F

f.gruber

Hacker
Ich verwende seit Jahren auf dem openSuse-Server Zertifikate von LetsEncrypt. Die LetsEncrypt Zertifikate müssen immer wieder (per Cronjob) erneuert werden.

Bei jedem Renew kam seit einiger Zeit dann die Meldung, dass certbot-auto nicht weiter mit Updates versorgt wird. Daher habe ich also vor einigen Monaten certbot als Snap installiert. Es klappt alles und ich erhalte keine Warnung mehr von wegen Updates.

Ich lasse also Certbot als Snap, es funktioniert ja.
Infos dazu: https://eff-certbot.readthedocs.io/en/stable/install.html#id5
 
OP
F

f.gruber

Hacker
josef-wien schrieb:
Was zeigt:
Code:
cat /proc/self/mountinfo
Code:
122 95 7:1 / /snap/certbot/1582 ro,nodev,relatime shared:67 - squashfs /dev/loop1 ro
125 95 7:3 / /snap/core20/1242 ro,nodev,relatime shared:73 - squashfs /dev/loop3 ro
126 95 7:4 / /snap/snapd/14066 ro,nodev,relatime shared:75 - squashfs /dev/loop4 ro
129 95 7:5 / /snap/snapd/13640 ro,nodev,relatime shared:77 - squashfs /dev/loop5 ro
568 95 7:6 / /snap/core20/1270 ro,nodev,relatime shared:312 - squashfs /dev/loop6 ro
123 95 7:2 / /snap/certbot/1670 ro,nodev,relatime shared:69 - squashfs /dev/loop2 ro

Daraus schließe ich, dass die Unterverzeichnisse von /snap nur eingehängt sind und daher nicht gesichert werden müssen.

Bleibt nur das Verzeichnis bin. Soll das ins Backup oder wird das auch vom System wieder neu erstellt?
 

josef-wien

Ultimate Guru
Nachdem jetzt geklärt ist, was läuft, muß Deine Fragen jemand beantworten, der sich mit diesen Komponenten auskennt.
 

susejunky

Moderator
Teammitglied
Hallo f.gruber,


f.gruber schrieb:
... Bleibt nur das Verzeichnis bin. Soll das ins Backup oder wird das auch vom System wieder neu erstellt?
vielleicht hilft Dir die Dokumentation zu snap bei dieser Entscheidung weiter.

Das Kapitel Data locations erscheint mir ein guter Startpunkt zu sein, um herauszufinden welche Daten snap an welchen Orten ablegt.

Viele Grüße

susejunky
 
OP
F

f.gruber

Hacker
Ich werde /snap vom Backup excluden. Sollte einmal ein Restore nötig sein, so gehe ich davon aus, dass es keine Probleme wegen snap geben sollte.

Siehe auch: https://forum.snapcraft.io/t/should-i-backup-the-snap-directory/27851
 

susejunky

Moderator
Teammitglied
Hallo f.gruber,


f.gruber schrieb:
... Sollte einmal ein Restore nötig sein, so gehe ich davon aus, dass es keine Probleme wegen snap geben sollte.
hast Du jemals überprüft, ob Du, mit Hilfe der von Dir erstellten Datensicherungen, Dein System wieder erfolgreich herstellen kannst?

Viele Grüße

susejunky
 

Christina

Moderator
Teammitglied
f.gruber schrieb:
Ja, habe schon auf diversen Computern zurückrudern müssen auf ein Backup.
Nimmst du rsync für den Server im Internet, weil der im laufenden Betrieb gesichert werden muss?
Oder nimmst du generell rsync?
 

Christina

Moderator
Teammitglied
Kennst du auch fsarchiver?
Hot backups habe ich aber noch nicht ausprobiert. Das ist mir zu heiß.
 
OP
F

f.gruber

Hacker
Christina schrieb:
Kennst du auch fsarchiver?
Hot backups habe ich aber noch nicht ausprobiert. Das ist mir zu heiß.
Ich habe vor Jahren begonnen nach einer Anleitung von heinlein-support.de meine eigenen Scripte zu basteln.
Diese inzwischen wahrscheinlich überarbeitete Anleitung gibt es immer noch und zwar hier: https://www.heinlein-support.de/howto/backups-und-snapshots-von-linux-servern-mit-rsync-und-ssh

Ich sehe den Vorteil darin, dass ich jedes Detail selber modifizieren kann. Dass es viel Arbeit war und immer wieder ist, das kann ich nicht abstreiten. Eine fertige Lösung ist natürlich komfortabler.

Eines ist mir auch klar: Es ist schwierig für jemanden, sich darin zurechtzufinden, weil es halt trotzdem eine Bastelarbeit ist. Abgesehen davon, dass es vielleicht bei jemand anderem gar nicht so funktioniert wie beabsichtigt.

Ich weiß nicht, ob es jemals jemand ausprobiert hat :roll:

Auf der Seite von heinlein-support steht jedenfalls:
Code:
Unsere nachfolgend vorgestellte Backup-Lösung kommt ohne spezielle Backup-Software aus 
und ist in unseren Augen trotzdem kein Kompromiss, 
sondern der “fertigen Software” in vielen Bereichen überlegen.
Da ist schon was dran.
 

josef-wien

Ultimate Guru
Zwei rhetorische Fragen: Brauchst Du -A und -X wirklich nicht? Könnte -x diverse "excludes" unnötig machen?

P. S. Ich ziehe wie Du rsync vor, mit dem ich genau steuern kann, was passiert.
 

Christina

Moderator
Teammitglied
rsync verwende ich auch. fsarchiver sehe ich als Boardwerkzeug, aber das ist natürlich subjektiv.
 
OP
F

f.gruber

Hacker
josef-wien schrieb:
Brauchst Du -A und -X wirklich nicht?
Die Optionen -A und -X scheinen bis jetzt nicht abgegangen zu sein. Ich habe mit Mehrbenutzersystemen nichts mehr zu tun :p
Könnte man sagen: Nützt es nichts, so schadet es nichts?
Wenn du mir diese Frage mit "Ja" beantworten kannst, nehme ich halt diese zwei Optionen dazu.
josef-wien schrieb:
Könnte -x diverse "excludes" unnötig machen?
Bei der Option -x fehlt mir das Verständnis, wozu das gut sein soll - leider :eek:ps:
 

josef-wien

Ultimate Guru
Schaden können sie nicht anrichten. Aber wenn Du keine ACL-Berechtigungen verwendest, brauchst Du -A nicht. Und wenn Dir die Befehle chattr und lsattr nichts sagen, brauchst Du -X nicht.

-x verhindert, daß im Quellpfad eingehängte Partitionen berücksichtigt werden. Wenn Du / sicherst, wird nur das übertragen, was direkt auf der Systempartition gespeichert ist, alles andere (wie z. B. /dev, /proc/, /sys oder eine als /home eingehängte Partition) wird ignoriert. Wenn Du /home/ferdinand/ sicherst, wird eine gegebenenfalls dort (z. B. als /home/ferdinand/filme) eingehängte zusätzliche Datenpartition ignoriert. Es hängt von den jeweiligen Anforderungen ab, ob dieser Parameter nützlich ist.
 
OP
F

f.gruber

Hacker
josef-wien schrieb:
-x verhindert, dass im Quellpfad eingehängte Partitionen berücksichtigt werden. Wenn Du / sicherst, wird nur das übertragen, was direkt auf der Systempartition gespeichert ist, alles andere (wie z. B. /dev, /proc/, /sys oder eine als /home eingehängte Partition) wird ignoriert. Wenn Du /home/ferdinand/ sicherst, wird eine gegebenenfalls dort (z. B. als /home/ferdinand/filme) eingehängte zusätzliche Datenpartition ignoriert. Es hängt von den jeweiligen Anforderungen ab, ob dieser Parameter nützlich ist.
Okay, hab mir in etwa gedacht, dass es so gemeint ist.

Nun, ich habe tatsächlich bei einigen Computern, die ich sichere, andere Dateisysteme, eben z.B in /home oder /local oder auch in anderen Verzeichnissen eingehängt.

Es ist aber so, dass ich bisher meist nur Teile restaurieren muss, also nur das System oder nur die Partition, die in /home eingehängt ist usw.

Wenn man das ganze System restaurieren muss, dann muss ich halt genau schauen, was beim Restore zu excluden ist. Vorarbeit und Nacharbeit ist da ohnehin immer notwendig, da man ja meist eine andere Festplatte hat, und daher /etc/fstab zu ändern ist und diverse andere "Kleinigkeiten", wie zum Beispiel eine Neuinstallation des Bootloaders ...

Bei Geräten, auf denen nur Linux läuft, mache ich bei Notebooks mit SSD immer nur eine einzige Partition. :roll:
Hat man mehrere Partitionen, ja dann muss man diese halt vor dem Restore neu anlegen und dann aufpassen, wohin was zurückkopiert werden soll. Habe das aber noch kaum gebraucht ...

Was ich aber nicht gewusst habe, ist, dass auch /dev, /proc/ und /sys eingehängte "Dateisysteme" sind. Ist das wirklich so?
Ich habe /proc/*, /sys/* und /dev/* einfach prinzipiell bei jedem rsync-Backup excluded.

Bei der Gelegenheit stellt sich mir jetzt die Frage: Wie erkenne ich eigentlich, ob ein Verzeichnis eingehängt ist, oder sich direkt im Dateisystem befindet. Ich meine, kann man das in der Ausgabe von ls (bzw. dir) irgendwie anzeigen?
 

Christina

Moderator
Teammitglied
f.gruber schrieb:
Wie erkenne ich eigentlich, ob ein Verzeichnis eingehängt ist, oder sich direkt im Dateisystem befindet.
Mit mount kannst du das z.B. sehen.
Lies doch nochmal, was @josef-wien dir vor 3 Jahren schon geschrieben hat:
https://linux-club.de/forum/viewtopic.php?p=785420#p785420
f.gruber schrieb:
Bei Geräten, auf denen nur Linux läuft, mache ich bei Notebooks mit SSD immer nur eine einzige Partition. :roll:
Da ist fsarchiver nebenbei bemerkt nicht sinnvoll zur Sicherung.
 
Oben