Backup, wenn bestimmtes USB-Laufwerk vorhanden

[Donnerkeil]

Hallo Leute,

habe ein Debian-12-Linux-System, dass mal ein Server mit Paperless-NGX werden soll. Intern besteht es aus 2 Laufwerken (sda und sdb) für Betriebssystem und Daten. Soweit, sogut.

Jetzt das Wünsch-Dir-Was: Ich würde gern beim Neustart des Systems per Script prüfen, ob eine bestimmte USB-Festplatte angeschlossen ist und wenn ja, ein Backup-Script starten.

Erste Hürde: Auto-mounten USB-Hdds eigentlich oder wie bekäme ich die automatisch so eingebunden, dass jeder User davon lesen und darauf schreiben kann?
Oder: Könnte man einfach alles mounten, was beim Neustart gerade an einem der 7 USB-Ports angestöpselt ist, mit Lese- und Schreibrechten für alle User?

Nächstes Problem: Da unklar ist, an welchem der 7 möglichen USB-Ports die USB-Hdd angestöpselt wird, müssten ggf. alle USB-Anschlüsse abgefragt werden. Wie frage ich im Script ab, ob /dev/sd(x) vorhanden ist?

Endgegner: Wie prüft man im Script, ob eine der gefundenen Platten eben jene Welche ist? Identifiziert man nach Volume-Name? Oder nach Vorhandensein einer bestimmten Datei?

Das ganze Unterfangen geht weit über meine Möglichkeiten hinaus - wer hilft mir über die Straße?

[cosinus]

Warum muss denn immer soviel automatisiert werden? Ist das Bequemlichkeit oder für einen unbedarften Anwender?
Je mehr mit eigenen Scripts automatisiert wird, desto mehr kann schiefgehen. Ich halte das so:

• Mit 'su -' zu root werden.
• Externe Platte anstecken und mounten.
• Backup als root starten. (Ich verwende keine "echten" Scripte, sondern nur aliases, die ein mksquashfs bzw. rsync machen)

Ist sowas echt zuviel Arbeit?

[gugus]

Servus
Ich habe meine ext Laufwerke alle mit udev und systemd unter kontrolle.
Mit udev erkennt das System welche Platte angeschlossen wird und systemd liefert weitere Möglichkeiten fürs scripting.
Vielleicht kannst Du etwas ableiten ...

Beispiel udev

Code: Alles auswählen

SUBSYSTEMS=="usb", DRIVERS=="usb", ATTRS{serial}=="FF2000DF000000000000005FD5F76F", KERNEL=="sd?1", ACTION=="add", SYMLINK+="usb-backup", ENV{SYSTEMD_WANTS}+="usb_backup@%k.service"

systemd

Code: Alles auswählen

[Unit]
Description=USBBackup
 
[Service]
ExecStart=/usr/local/bin/usb-backup.sh %I
 
[Install]
WantedBy=system.device

Mit dem Script das gestartet wird kann ich dann weitere Aktionen wie Backup durchführen.
Einmal Aufwand, danach Automatisch.

[cosinus]

Interessante Idee, aber was passiert wenn man eine Platte anstecken will und es soll kein Autobackup gemacht werden?
Oder man will das erweitern und auch eine neue Platte mit anderer UUID soll ins Autobackup aufgenommen werden?

[letzter3]

Interessante Idee, aber was passiert wenn man eine Platte anstecken will und es soll kein Autobackup gemacht werden?

Vorher disablen?

Oder man will das erweitern und auch eine neue Platte mit anderer UUID soll ins Autobackup aufgenommen werden?

script erweitern oder kopieren?

Waren die Fragen ernst gemeint?
Frage zurückgezogen um schlechte Stimmung zu vermeiden.

[letzter3]

Gerne auch mal schauen, wie es z.B. OMV macht: https://github.com/openmediavault/openm ... -usbbackup

[cosinus]

script erweitern oder kopieren?
Waren die Fragen ernst gemeint?

Was war denn so unverständlich?
Wenn man mal keine Automatik will, muss man MANUELL eingreifen oder nicht?
Wenn man auf ein anderes Gerät das Backup schreiben will, wird automatisch das alte Backup überschrieben oder wird gefragt?

Klar man kann das Script erweitern, aber das war glaub ich nicht die Intention des TE. Und nach solchen Fragen kommt meist mehr.

[letzter3]

Wenn man mal keine Automatik will, muss man MANUELL eingreifen oder nicht?

Ja. Ihre Lösung heisst aber immer manuell. Was ist bequemer?
Und ich vermute mal, dass es eine reine backupplatte ist, auf die das backup geschrieben werden soll, wenn die Platte angesteckt ist.

Wenn man auf ein anderes Gerät das Backup schreiben will, wird automatisch das alte Backup überschrieben oder wird gefragt?

Das liegt doch an dem

Code: Alles auswählen

ExecStart=/usr/local/bin/usb-backup.sh %I

was dann wie passiert....

Klar man kann das Script erweitern, aber das war glaub ich nicht die Intention des TE. Und nach solchen Fragen kommt meist mehr.

Nein, dass war Ihre Intention.
Der TE wollte eine bestimmte backupplatte nutzen, er wollte nicht das backupplattensystem erweitern.

Ich nutze übrigens das verlinkte OMV-Zeugs für das Viertbackup auf Festplatte im icy-Box-Gehäuse. Funktioniert hervorragend.

(1 backup lokal -> Falls die Daten lokal beschädigt beschädigt sind -> schnell und schmutzig; 2. backup in der cloud ; 3 backup auf PC bei mir zu Hause, 4. backup -> unregelmäig wie vorher beschrieben; je nach Lagerort verschlüsselt)

Aber vielleicht sollten wir den TE erstmal antworten lassen, vielleicht ist Ihre Einschätzung ja auch die passendere.

[cosinus]

Ja. Ihre Lösung heisst aber immer manuell. Was ist bequemer?

Der ganze Thread bezieht sich auf Automatik. Deswegen meine Frage, wie man das überhaupt zuverlässig genug scripten kann und so, dass auch es dausicher ist.
Ich hab da deswegen meinen einfachen Ansatz geschildert. Ist natürlich nichts, wenn man im Büro Hunderte Rechner sichern will. Aber da denkt man sich wohl auch was anders aus, als an jedem PC MANUELL irgendwelche Festplatten anzustecken.

[Donnerkeil]

Wow! Allerbesten Dank an alle, die sich mit meinem Problem auseinander setzen! Bin wirklich beeindruckt!

@ Cosinus ' 1. Antwort

Mit 'su -' zu root werden.
Externe Platte ...
Backup als root starten ...
Ist sowas echt zuviel Arbeit?

Nein, das wäre für mich nicht zu viel oder zu schwer, für den letztendlichen Nutzer allerdings sehr. Den würde ich erst gar nicht auf die Idee bringen wollen, mit "su-" irgendwas zu machen.

@ Cosinus ' 2. Antwort

"Interessante Idee, aber was passiert wenn man eine Platte anstecken will und es soll kein Autobackup gemacht werden?"

Deswegen würde ich die Backup-HDD ja gerne als solche identifizieren können. Entweder mit einem besonderen Namen oder beispielsweise mit einer vorhandenen Datei, beispielsweise "Backup-Ident-Datei.txt" oder meinetwegen auch mit einem 250 Zeichen langen Dateinamen. Wenn Datei vorhanden, dann Backup, wenn nicht, dann ist es irgend ein anderes Laufwerk und es erfolgt keine Aktion. Vielleicht würde ich aus Sicherheitsgründen dann sogar unmounten wollen ...

@ gugus
udev oder systemd sind Bezeichnugnen für Dinge, die ich bestenfalls vage kenne. Werde versuchen, mich da reinzufuchsen.

@ letzter3
werde mir den Github-Link anschauen.

[shoening]

Hi,

wenn es erst mal um „sichere Erkennung“ der Platte geht, werfe ich mal /dev/disk/by-uuid in den Raum.

Die UUID, die da für die Platte auftaucht, wenn sie denn eingesteckt ist, sollte eigentlich eindeutig sein.

Viele Grüße
Stefan

[heisenberg]

Alternative wäre LABEL, was man dann auf die Platte konfiguriert. Wenn man die Platte tauscht muss man dort nur das Label setzen, ohne den Code des Programmes ändern zu müssen. Das wäre quasi eine Alternative zu einer Datei, die auf der Platte liegt, was Du schon vorschlugst.

[MSfree]

wenn es erst mal um „sichere Erkennung“ der Platte geht, werfe ich mal /dev/disk/by-uuid in den Raum.

Code: Alles auswählen

lsblk -f

[MSfree]

Was einen Automatismus angeht, der läßt sich mit udev, wie oben genannt, erreichen.

Allerdings ist dabei folgendes zu beachten:

• Platte anstecken.
• udev merkt, daß es die Backupplatte ist
• Backupskript startet

So weit,so gut. Aber, dem Anwender sollte angezeigt werden, daß das Ding noch rödelt. Und er sollte benachrichtigt werden, wenn das Backup fertig ist. Damit der Anwender den USB-Stecker wieder abziehen kann, sollte die Platte vom Backupskript auch geunmountet werden, sonst kann es zu Dateisystemkorruption kommen.

Wie gehe ich damit um, daß die Backupplatte irgendwann voll ist und keine weiteren Backup mehr drauf passen?

Was aber ist, wenn der Ernstfall eingetreten ist und eine einzelne Datei aus dem Backup zurückgeholt werden muß?

Aus Sicht des naiven Benutzers hier mal das Ernstfallszenarion:

Ich stecke also die Backupplatte an und.... warte mal, jetzt läuft ja erstmal das "stundenlang" dauernde Backup an, das die Platte am Ende unmountet!

• Wie komme ich dann an die Datei, wenn die Platte nicht mehr gemountet ist?
• Hat das Backup vielleicht nun die Datei mit dem falschen Inhalt überschrieben, weswegen ich die eigentlich zurückholen wollte?

Es sind also einige Dinge zu beachten, wenn man so ein Backup automatisieren will. Es gibt natürlich für beide Fragen eine Lösung.
Man könnte z.B. das Backup auf einmal täglich begrenzen, indem man eine Markierungsdatei in das Rootverzeichnis der Backupplatte schreibt. Hat diese Datei das aktuelle Datum, ist das Backup bereits gelaufen und erneutes abstecken und anstecken führt dann nicht mehr zum Backup sondern nur zu einem Mount.

Das löst die zweite Frage zumindest teilweise. Mit Harlinks im Backup löst man das Problem sogar komplett, weil die kaputte Datei, wegen der man eine Datei vom Backup zurückholen wollte, ist im Backup des Vortages noch vorhanden.

[heisenberg]

Da hatten wir doch vor kurzem was dazu hier:

viewtopic.php?t=188698

• Wie komme ich dann an die Datei, wenn die Platte nicht mehr gemountet ist?
• Hat das Backup vielleicht nun die Datei mit dem falschen Inhalt überschrieben, weswegen ich die eigentlich zurückholen wollte?

Zum 1. Punkt: man könnte die Platte nach Fertigstellung des Backups read-only einhängen. Wenn man die Platte dann abzieht, sollte das problemlos sein.

Zum 2. Punkt: Mehrere Backupsätze nutzen. (täglich, wöchentlich, monatlich)

[HumiNi]

Was aber ist, wenn der Ernstfall eingetreten ist und eine einzelne Datei aus dem Backup zurückgeholt werden muß?

Das Backup-Script fragt vor dem Start ein Restore-File ab, welches vor dem gewünschten Restore angelegt wird.

[cosinus]

welches vor dem gewünschten Restore angelegt wird.

Wir das automatisch angelegt?

[HumiNi]

welches vor dem gewünschten Restore angelegt wird.

Wir das automatisch angelegt?

Nein, manuell. Wenn ausnahmsweise eine Restore (oder eine Überprüfung des Backups) gewollt ist.

[MSfree]

welches vor dem gewünschten Restore angelegt wird.

Wir das automatisch angelegt?

Nein, manuell. Wenn ausnahmsweise eine Restore (oder eine Überprüfung des Backups) gewollt ist.

Nunja, das ist für Donnerkeils Anwendungszweck aber ziemlich unbrauchbar. Das soll schließlich idiotensicher sein, da kannst du nicht erwarten, daß der Endanwender den Automatismus (mounten und Backup starten) aushebelt, die Platte manuell mountet und dann eine mysteriöse Datei mit welchem Namen auch immer, anlegt, um dann auf das Backup zugreifen zu können.

Da hat Heisenbergs Idee, die Platte nach dem Backup read-only zu remounten, schon seinen Charme.

Kombiniert damit, daß das Backup nach anstecken der Platte nur anläuft, wenn innerhalb der letzten x Stunden kein Backup statttgfunden hat, dürfte das schon fast idiotensicher sein, ohne Expertenwissen um eine anzulegende Datei haben zu müssen.

[HumiNi]

Wir das automatisch angelegt?

Nein, manuell. Wenn ausnahmsweise eine Restore (oder eine Überprüfung des Backups) gewollt ist.

Nunja, das ist für Donnerkeils Anwendungszweck aber ziemlich unbrauchbar.

Meine Bemerkung bezog sich nur auf die Frage, wie man ein automatisch anlaufendes Backup verhindert, wenn es nicht gewünscht ist. Für den "normalen" User ändert sich nichts, denn er führt (normalerweise) den Restore nicht selbst aus.

[MSfree]

Meine Bemerkung bezog sich nur auf die Frage, wie man ein automatisch anlaufendes Backup verhindert, wenn es nicht gewünscht ist. Für den "normalen" User ändert sich nichts, denn er führt (normalerweise) den Restore nicht selbst aus.

Wenn man ins Berufsumfeld geht, wo sich ein Admin um Backup und Restore kümmert, wird man so eine Lösung mit einer anzulegenden Datei auch nicht haben wollen. Da setzt man auf Netzwerktechnik, arbeiten auf Netzwerklaufwerken statt lokalem Plattenplatz und Backup der Netzwerklaufwerke, am besten noch mit snapshotfähigen Dateisystemen, selbstverständlich alles zeitgesteuert, die Systeme laufen 24/7.

OK, in der Softwareentwicklung nutzt man durchaus auch lokale Platten, aber da arbeitet man mit Sourcecode Revisionssystemen wie GIT. Da liegt es in der Hand des Entwicklers, seine Änderungen ins Repository zu schreiben. Wenn man sich da etwas zerbröselt, hat man nicht viel verloren. GIT ist aber viel zu kompliziert für normale Anwender und automatiseirt ist da gar nichts.

[gugus]

Ui, da sind ja einige Fragen zusammen gekommen.
Also, mein Backup wird auf dedizierten Platten durchgeführt. Da steht dann auch Backup drauf. Da brauche ich nur im Log das ich mir selbst via Email zuschicke nachzusehen wie es den Platten geht.

Ich lasse mein Backup auch 2 mal hinterneinander auf unterschiedlichen Platten laufen, ist zwar ne kleine Verschwendung, dafür aber eine Sicherheit falls eine Platte den Geist aufgibt. Dann muss ich nur die Seriennummer der neuen Platte auslesen und ins udev script eintragen und schon gehts wieder. Gestartet werden die Platten über schaltbare Steckdosen, somit sind die Platten dann auch vom System getrennt wenn nicht benötigt.

Das Backup mache ich mit rsnapshot.

Ich nenne das privates Backup für Faule

Ja, ich hatte auch schon RAID Systeme, sind mir aber für die paar Dateien die ich sichere aber zu teuer und aufwändig.
Zudem installiere ich bei einem Rechnerausfall (der alle paar Jahre mal vorkommt) komplett neu und installiere die Programm die ich nutze via dpkg -selection Datei nach, die Konfig Dateien zurück kopiert und schon ist wieder alles da und gleich auf den neuesten Stand, der Rest sind virtuelle Systeme die komplett gesichert werden oder gleich weggeworfen... es gäbe noch mehr zu erzählen

[MSfree]

Also, mein Backup wird auf dedizierten Platten durchgeführt. Da steht dann auch Backup drauf. ...Ich lasse mein Backup auch 2 mal hinterneinander auf unterschiedlichen Platten laufen, ist zwar ne kleine Verschwendung, dafür aber eine Sicherheit falls eine Platte den Geist aufgibt.

Ich nenne das privates Backup für Faule

Zumindest hast du ein doppeltes Backup, was ich auf jeden Fall sinnvoll halte. Für "Faule" ist das aber zumindest so, wie ich es verstanden habe, nicht. Denn es Bedarf ja vermutlich manueller Interaktion, die Platte anzuhängen und das Backup zu starten.

Gerade im privaten Umfeld wird es aber gerne mal mit dem Backup nicht so genau genommen. Warum sollte ich heute ein Backup machen, übermorgen reicht doch auch, zumindest bis man mit dieser Prokrastinationstaktik mal auf die Nase fällt.

Daher halte ich es auch im privaten Umfeld für sinnvoll, Backups zu automatisieren, indem man sie z.B. auf ein Netzlaufwerk macht und das jedes Mal wenn ein Rechner gestartet wird. Dann muß man nicht mehr dran denken und hat im Zweifelsfall keinen großen Verlust, wenn man etwas kaputt geht.

Ja, ich hatte auch schon RAID Systeme, sind mir aber für die paar Dateien die ich sichere aber zu teuer und aufwändig.

RAID ist kein Backup sondern hauptsächlich dazu da, um Speichergrößen zu ermöglichen, die mit einzelnen Platten nicht erreicht werden können. Die Redundanz eines RAIDs bringt nur einen gewissen Schutz vor Verlust, wenn einzelne Laufwerke ausfallen.

Solange der Bakupbedarf problemlos auf eine einzelne Platte paßt, gibt es keinen Grund für ein RAID.

Was RAIDs letztlich teuer macht, ist die Plattenkapazität. Vier 18TB Platten kosten halt runde 1100€ plus die Hardware ringsrum, insgesamt also irgendwas im Bereich 1400-1700€. Wenn für den Backupbedarf eine einzelne 18TB Platte reicht, ist man halt mit einem USB-Gehäuse plus die Platte im Bereich 300-350€.

[gugus]

Sorry, da habe ich mich missverständich ausgedrückt und der Länge wegen nicht alles beschrieben.

Mein Backup startet natürlich automatisch von einem Raspi via cron der eine USB Steckdosenleiste schaltet.
Die Platten sind zwei externe USB Platten.

rsnapshot loggt sich via key's bei den Systemen ein und sichert Konfig und Daten.
Am Ende des Backup Scripts wird eine Zusammenfassung des Backups vie Email an mich geschickt, da sind auch Füllstände und Sensordaten drin.
Da kann ich sehen ob ich nächstens eine Platte austauschen muss bevor sie streikt.

Das mit dem Raid, klar Raid eine Plattenstruktur aber auch eine Sicherung für Ausfall einer Platte je nach Raid Ausprägung , das habe ich gemeint.

Ich hatte früher ein Raid 5 System für das Backup ("Reste ausm Geschäft"), hatte gut funktioniert war aber am Server und das Teil lief die ganze Zeit und die Platten waren teurer.

Jetzt laufen die USB Platten nur für die Zeit des Backups, ca 20 Minuten in 24 Stunden, da brauche ich auch keine Server Platten mehr.

Aber wie Du schreibst im privaten Bereich genügt das vollauf.

A propo Kosten, habe gerade kurz nachgeseen sollte ich tauschen müssen, USB3 3,5" 4Tb mit Gehäuse 108€ ... das genügt mir die nächsten Jahre