Feedback erwuenscht zu dem neuen raspiBackup installer

  • Feedback erwuenscht zu dem neuen raspiBackup installer? Schau mal ob du hier fündig wirst!

  • Da Thomasl nicht kann oder will

    Beides trifft nicht zu :cool: ich habs einfach nicht mitbekommen.... in der Annahme, dass ich bei diesem Backup eh nicht helfen kann... ich nutze ja mein eigenes Tool. Ich gucke morgen früh mal, was ich verpasst habe.

  • @ThomasL :thumbup:

    Es geht hier auch nur sekundaer um Backup. Primaer steht die Frage im Raum, wie man am besten eine gewaehlte Liste von Systemd Services geordnet runter bzw wieder hochfaehrt. Die Idee war dass systemctl das macht und die Servicedependencies beruecksichtigt. Nur leider ist es so dass die Liste der Services bei systemctl einfach nur ungeordnet parallel gestoppt bzw gestartet werden :denker:

  • Moin

    Ich habe jetzt nicht alles gelesen und nur mal quer auf systemd gescannt. Vor dem Hintergrund des Themas vermute ich, dass es um ein automatisches Fullbackup des Systems geht, für das passend einzelne Services gestoppt werden müssen, um Konflikte und Integritätsprobleme zu vermeiden.

    Unter anderem wegen der damit einhergehenden Probleme habe ich selber gar nicht erst versucht, das programmtechnisch zu lösen. Ich glaube, dass so etwas und mit einer akzeptablen Gewährleistung nur mit dem gleichen Anteil von disziplinarischen Anweisungen und technischen Lösungsschritten möglich ist. Anders ausgedrückt, ohne den Faktor "kontinuierliche menschliche Kontrolle" halte ich das Ergebnis in hohem Maße für Zufallsbedingt.

    Eine Auswahlliste waere wohl noch besser. Aber das ist extremer Aufwand und vermutlich sogar nicht allumfaenglich loesbar sein. Deshalb moechte ich gerne bei den Befehlen bleiben.

    Das sehe ich genau so. Ich halte es für ein ziemlich riskantes Wagnis, das maschinell ermitteln zu wollen, bis hin, dass es zu massiven Datenverlust führen kann.

    Aber Dank Deines Tipps habe ich

    Code
    sudo systemctl list-units --type=service --state=active

    gefunden. Da muss man nur noch .services maskieren und gut ist :)

    Auch das halte ich für keine gute Lösung. "active" bedeutet nicht, dass der Job dieser Service-Unit ein laufender Job ist, sondern nur, dass die Unit "active" ist. "maskieren" hat unter systemd eine eindeutig definierte Funktionalität... also Achtung. Wenn überhaupt, wären vielleicht die folgenden Statements eine Alternative (...von denen ich aber ebenfalls abrate, um daraus maschinelle Rückschlüsse zu ziehen):

    Code
    systemctl -l | grep running | grep service | grep -v systemd
    systemctl -l | grep waiting | grep timer

    Das zeigt die jetzt laufenden Services an... und Service bedeutet hier laufendes Programm. Aber, was aus dieser Perspektive gar nicht erkennbar ist, dass zu jeder Zeit durch die timer auch neue laufende Prozesse gestartet werden können, die auf Abhängigkeiten zugreifen oder darauf angewiesen sind. Nur mal so als Beispiel Logrotate vom Journal.

    Dank Deiner Hinweise zu systemd habe ich jetzt schon einen Prototypen wo eine Liste aller aktuell laufenden Services angezeigt wird und man kann die Services einzeln in einer Checklist anklicken. Das macht es sehr einfach.

    Ohne das der menschliche "Clicker" Kenntnis über kausale (Dependencies) Abhängigkeiten der angebotenen Service-Units hat, resultiert daraus imho ein digitales russisches Daten-Roulette.

    Siehst Du es auch so dass systemctl unter der Decke die richtige Reihenfolge von den zu stoppenden und zu startenden Services ermittelt und befolgt?

    Es gibt keine Reihenfolge bei Systemd, sondern nur Abhängigkeiten. Aus den Abhängigkeiten resultiert möglicherweise als sekundärer Effekt eine Start- und Stop-Reihenfolge, aber die ist irrelevant.... primär ist die Abhängigkeit der relevante Aspekt. Was dazu führt, dass nicht voneinander abhängige Prozesse quasi parallel gestartet und gestoppt werden (können). Das bedeutet aber auch, dass beim Stoppen eines Services -als Folge vielleicht gar nicht so offen erkennbar- auch abhängige Services gestoppt werden. Aber die quasi kausal gestoppten Services werden wiederum nicht zwingend mitgestartet, wenn der ursprüngliche primäre Service restartet wird.

    Meine Unit "serverctl.service" wird beispielsweise bei Systemstart gestartet. Irgendwelche (variierend) davon abhängige Units werden dynamisch zur Laufzeit gestartet. Würde ich nun serverctl.service stoppen, sterben alle abhängigen Units ebenfalls. Restarte ich serverctl.service werden die zuvor kausal gestoppten Services nicht mitgestartet.

    Ich halte es auch für ein Wagnis, dem Anwender eine Liste anzubieten, aus denen er zu schließende Services auswählen kann. Ein solche Liste würde möglicherweise auch libvirt-Services enthalten, oder virtual-box-VMs, oder systemd-nspawn-container, oder docker-container. Oder Timer-Jobs, wo ich gar nicht weiss, ob vielleicht der ge'time'te und jetzt gerade zufällig laufende Job schlichtweg getötet wird, wenn ich die Service-Unit stoppe. Jetzt kann sich jeder ausdenken, was mit den in einer VM laufenden Prozessen passiert, wenn ich auf dem Host die VM-Services stoppe. Was ist, wenn ein Anwender auf seinem Client einen JDL2-Job auf Nachts scheduled und es wird ihm der Share mittendrin entzogen?

    Da ja zuvor mein Raspi unser vollumfänglich genutzter LAN-Server war, betrachte ich das Problem jetzt natürlich auch nur aus meiner subjektiven Perspektive auf unser Netzwerk und schaue dabei insbesondere auf unseren LAN-Server .... und vor dem Hintergrund sehe ich hier schon gewisse Risiken, wenn man das einfach so übernimmt. Was anderes kann ich ja jetzt hier auch gar nicht zugrunde legen, weil ich andere Situtationen eben nicht kenne. Ich bin jedoch davon überzeugt, dass ein automatisch laufendes systemweites Backup meiner Meinung nach nur Zufallsbedingt funktioniert, wenn der Admin nicht zuvor konkret sicher gestellt hat, dass Prozesse ordnungsgemäß beendet werden... was eben nicht zwingend mit dem Stoppen einer Service-Unit passiert oder gewährleistet ist .... und das gerade eben auch ergänzt durch Kommunikation und disziplinarische Maßnahmen mit den Clients.

    Von einem Admin, der im LAN zur Verfügung gestellte Server-Prozesse betreut, würde ich erwarten, dass er Kenntnis über die Steuerung seiner manuell eingerichteten Prozesse hat. Das heisst, ich würde vom Admin erwarten, dass er manuell sichergestellt hat, dass zuerst Prozesse ordnungsgemäß beendet werden und dann ggf. service-unit (sofern noch notwendig) gestoppt werden. Und wenn er diese Kenntnisse nicht hat, bleibt sein Full-Backup eben teilweise auch nur ein Zufallsprodukt oder es führt an anderer Stelle zu Datenverlust, wenn er sich nicht an Spielregeln hält. Bei mir war es die Kenntnis über die Kausalität aller Probleme, dass ich das eben gar nicht mehr sichere. Ein seltener neuer Image-Install ist hier bei uns viel weniger aufwendig, als der Aufwand und die ständige Qualitäts-Kontrolle der potentiell (bei meiner LAN-Server-Perspektive) unsicheren Full-System-Backups. Ich würde nach einem solchen Backup, wenn Services gestoppt wurden (also nicht gerade samba) durchaus auch einen Reboot in Erwägung ziehen, um sicherzustellen, dass jetzt wirklich wieder alle Services laufen.

    Sorry... ich hoffe, dass ich jetzt hier kein Spielverderber bin und mich unbeliebt mache... was ich hier geschrieben habe, kann sowohl richtig als auch falsch sein. Was es ist, hängt allein von der Funktion der zu sicherenden Maschine ab. Ich versuch deshalb auch nur bei einer rein technischen Perspektive auf die vorhandenen Probleme zu bleiben. :conf: Persönlich vertrete ich allerdings die Meinung, dass ein Fullbackup speziell meines LAN-Servers nur manuell und unter Aufsicht durchgeführt werden kann.... was ich natürlich hinsichtlich des Aufwands für mich und der nur extrem kurzlebigen Aktualität des Backups ausschließe.

    8 Mal editiert, zuletzt von WinterUnit16246 (24. März 2019 um 11:52)

  • Woanders bin ich aufgeklaert worden. Leider beruecksichtigt systemctl nicht die Serviceabhaengigkeiten sondern startet alle angegebenen Services parallel

    Ich glaube, da bist Du einer Fehlinformation aufgesessen. Im geposteten Beispiel wird lediglich eine Reihenfolge (mit "After=") aber keine Abhängigkeit (mit "Requires=") definiert. Für das korrekte Verhalten ist aber beides nötig:

    Nur "After":

    Code
    $ systemctl --user start A B
    Mar 24 13:32:45 keller systemd[646]: Starting A.service...
    Mar 24 13:32:45 keller systemd[646]: Starting B.service...
    Mar 24 13:32:47 keller systemd[646]: Started A.service.
    Mar 24 13:32:47 keller systemd[646]: Started B.service.

    Nur "Requires":

    Code
    Mar 24 13:33:24 keller systemd[646]: Starting B.service...
    Mar 24 13:33:24 keller systemd[646]: Starting A.service...
    Mar 24 13:33:26 keller systemd[646]: Started B.service.
    Mar 24 13:33:26 keller systemd[646]: Started A.service.

    Beides:

    Code
    Mar 24 13:34:06 keller systemd[646]: Starting B.service...
    Mar 24 13:34:08 keller systemd[646]: Started B.service.
    Mar 24 13:34:08 keller systemd[646]: Starting A.service...
    Mar 24 13:34:10 keller systemd[646]: Started A.service.
  • Sorry... ich hoffe, dass ich jetzt hier kein Spielverderber bin und mich unbeliebt mache...

    Nope, bist Du nicht und machst Du Dich nicht:no_sad:.

    Du hast sicherlich Recht dass unwissentliches Stoppen von Services zu inkonsistenten Backups fuehren kann. Und ich habe jetzt auch verstanden dass beim Starten per systemctl auch nicht unbedingt sichergestellt ist dass alle dependent Services wieder gestartet werden. D.h. der Benutzer muss einfach wirklich explizit und genau wissend angeben welche Services zu stoppen und zu starten sind und das auch noch gut testen sollte. Am besten ist es wohl wirklich am Ende einen Restart des Systems zu machen damit systemd alles wieder korrekt startet. Allerdings gibt es viele Benutzer den ist schon die Backupzeit wo ihre Services gestoppt sind zu lang :rolleyes:

    Ich denke ich lasse den Benutzer die Services die er denkt gestoppt bzw gestartet werden sollen explizit angeben. So war es bislang auch schon, nur dass er manuell die Services raussuchen musste und in die Konfig per Editor eintragen musste. Die Liste soll ihm dabei helfen Kandidaten zu identifizieren. Jetzt werde ich ihn in einem weiteren Menu in eine Reihenfolge bringen lassen, dann die ausgefuehrte Befehlssequenzen zum Starten und Stoppen anzeigen lassen und hinweisen das gut testen.

    Welche Services da angezeigt werden muss ich noch mal eruieren. Dein grep Vorschlag sieht auch ganz gut aus.

    Fazit:

    Ein Backup eines laufenden Systems muss immer gut geplant, konfiguriert und getestet werden. Dieser Fakt geht sicherlich unter wenn ein Benutzer per einfacher Klicks Services auswaehlen kann und dann by Magic die Reihenfolge vom Backupprogramm bestimmt wird. Deshalb lasse ich die Finger davon diese Sequenz zu erzeugen mit all den Unwaegbarkeiten mit systemd bzw systemctl. Jetzt muss ich nur noch eine gute Methode finden mit dem primitiven whiptail den Benutzer die Reihenfolge definieren zu koennen.

  • Ich glaube, da bist Du einer Fehlinformation aufgesessen. Im geposteten Beispiel wird lediglich eine Reihenfolge (mit "After=") aber keine Abhängigkeit (mit "Requires=") definiert. Für das korrekte Verhalten ist aber beides nötig:

    Danke fuer den Hinweis. Heisst das nun dass systemctl doch alle Anhaengigkeiten beruecksichtigt und benutzt werden koennte :conf::denker:

    Ich denke am sichersten ist es die Verantwortung zu dem Thema dem Benutzer aufzuerlegen wie es bislang schon getan wird. Bislang habe ich auch kein negatives feedback dazu bekommen - ausser ein paar Fragen welche Services man nehmen sollte zum Starten und Stoppen.

  • Welche Services da angezeigt werden muss ich noch mal eruieren.

    Du hast an der Stelle ein -imho fast nicht zu lösendes und ziemlich- imposantes Problem.... also, jetzt wieder aus meiner persönlichen rein subjektiven Sicht auf meinen Server betrachtet. Im Grundegenommen wären eigentlich nur 2 primäre Maßnahmen vor dem Backup notwendig, und zwar müssen User-Logins und Timer-Jobs verhindert werden.

    Also alle Dienste, die in irgendeiner Form einen User-Login an einem auf der Maschine laufenden Service beinhalten, müssten eigentlich gestoppt werden.... sowas wie samba, nfs, postfix, exim, dovecot, ssh, radicale, cloudservices, Datenbank-Services, wpa-supplicanct, hostapt, telegram-cli, ftp, smstools, (auf meinem Server die VMs nicht zu vergessen), usw. ... ich wüsste gar nicht, wie umfangreich die Liste noch sein kann. Das Problem an der Stelle ist also, dass man das aufgrund der Vielzahl an Möglichkeiten kaum vorbestimmen oder vorhersagen kann. Dann müssen auch einige Timer unter der Prämisse geprüft oder gar ausgesetzt werden, dass das Backup ja länger dauern könnte und während der Zeit Timer vielleicht irgendwelche Jobs starten könnte, die mit dem Backup kollidieren oder in Konflikt stehen. Gerade auch wenn ein PI im Rahmen der Home-Automatisierung zyklisch irgendwo irgendwelche Sensor-Werte abholt und die speichert.

    Ich halte das für ein sehr anspruchsvolle Problem.... :conf: ... allein vor dem Hintergrund einer unfassbar großen Variabilität. Das bedeutet, ohne wirklichen Überblick über die Raspi-Funktionen durch den Admin kann im allerschlimmsten Fall (was ich nicht hoffe) so ein Backup aber auch nur ein Alibi-Backup sein, ohne ein wirliches Backup zu sein. Das ist ja genau der Grund, warum ich da kapituliert :daumendreh2: habe und heute einen anderen Weg gehe...

    Einmal editiert, zuletzt von WinterUnit16246 (24. März 2019 um 19:13)

  • ... Das bedeutet, ohne wirklichen Überblick über die Raspi-Funktionen durch den Admin kann im allerschlimmsten Fall (was ich nicht hoffe) so ein Backup aber auch nur ein Alibi-Backup sein, ohne ein wirliches Backup zu sein...

    Ein laufendes System zu sichern ist immer mit Unwaegbarkeiten versehen. 100% Garantie auf Erfolg kann man nicht geben. Viele Leute sind der Meinung dass so ein Backup auch kein zuverlaessiger Backup ist.

    Meine Erfahrung ist dass es funktioniert. Als ich damals nach laengerer Verfuegbarkeit von raspiBackup einfuehrte dass die Start/Stop Services nicht mehr angegeben werden koennen sondern sie angegeben werden muessen gab es gewissen Protest, denn bis dahin haben viele Benutzer ihre Raspberries ohne irgendwelche Services zu stoppen gesichert und erfolgreich restored.

    Es kommt eben wirklich darauf an was auf dem Raspi laeuft und wie gut man testet. Ein Linux Admin/Profi erstellt sich seine eigene Backupstrategie wie z.B. Du mit dem Neuinstallationsansatz. Es gibt aber viele die sind froh wenn ihr Raspi erfolgreich aufgesetzt wurde und ihre Dienste tut und wollen sicherstellen dass sie im worst case relativ schnell und einfach das Image wiederherstellen koennen. Genuegend Dankesmails habe ich bekommen die belegen dass das Konzept durchaus erfolgreich ist.

    Ein paar Benutzer haben sich mal gemeldet weil der Restore nicht erfolgreich war. Das lag aber immer daran dass diese den Hinweis doch den Restore auch zu testen bzw zu ueben missachtet haben :-/ und dann als das Kind in den Brunnen gefallen war in Panik=O den Restore falsch durchgefuehrt haben. Alle haben ihr Image aber letztendlich aus dem Backup dann wiederherstellen koennen :shy:

    Es ist immer noch besser ein Backup zu haben was mit einer geringen Wahrscheinlichkeit, die der Benutzer durch gewissenhafte Konfiguration und Tests positiv beeinflussen kann, fehlerhaft ist als gar keines :)

  • Es ist immer noch besser ein Backup zu haben was mit einer geringen Wahrscheinlichkeit, die der Benutzer durch gewissenhafte Konfiguration und Tests positiv beeinflussen kann, fehlerhaft ist als gar keines

    Du musst nichts rechtfertigen oder erklären, natürlich ist so ein Backup besser, als keines. Und es wird definitiv viele Situationen geben, wo das völlig problemlos und auch anschließend reproduzierbar durchläuft. Mir kamen gerade noch zwei Ideen, wie man unabhängig davon, Dienste zu schließen, trotzdem noch erreichen kann, dass User nicht dazwischenfunken können.

    Die erste wäre, einfach das Netzwerk-Interface zu schließen.... also entweder die Netzwerk-Services oder sogar das Interface selber zu schließen. Damit wäre es egal, über welche Netzwerk-Verbindungen User etwas machen wollen... man muss keine Services schließen und die User sind trotzdem definitiv für alle Services ausgesperrt. Braucht der PI für das Backup selber das Netzwerk, um es auf ein Remote-Laufwerk zu schreiben, kann man alternativ kurzerhand sämtlichen eingehenden New-Traffic via iptables untersagen. Dann kann der PI zwar raus, aber niemand rein.

    Beides wird dafür sorgen, dass sehr effektiv von außen kommende Schreibzugriffe während des Backups verhindert werden. Lediglich die vom User eingestellten Cron-Jobs müssen dann noch berücksichtigt werden. Dazu habe ich nur die Idee, dass die Jobs via File-Flag informiert werden, dass sie pausieren müssen... aber dafür müssen die Jobs natürlich das File-Flag auf exist prüfen. Keine Ahnung, wie man das sonst lösen kann.

    Ob das alles notwendig ist... oder praktikabel .... oder auch nur sinnvoll....???... keine Ahhnung! Ich denke, da gibts keine pauschale Aussage, das ist von PI zu PI nach Umfang des jeweiligen Setups unterschiedlich.

  • Du musst nichts rechtfertigen oder erklären, natürlich ist so ein Backup besser, als keines...

    So wie ich aus Feedback entnehmen kann sind viele Benutzer froh relativ einfach ein Backup erstellen zu koennen ohne sich gross in die Materie einarbeiten zu muessen. Deshalb versuche ich ja das Thema zu startende/stoppende Services bewusst zu machen aber auch moeglichst convenient abzuhandeln. So wie ich es dachte dass dabei sytemctl/systemd helfen kann hat sich ja leider als eine Sackgasse erwiesen :(

  • Ich habe jetzt eine neue Version, bei der die Services und ihre Reihenfolge definiert werden kann, erstellt.

    Waere nett wenn ich Feedback zu der ServiceSelectionFunktion bekommen wuerde.

    Die Menus werden uber M3 -> C6 erreicht.

    Auswahl der Services:

    Ich habe im Beispiel cups und exim4 vorher ausgewaehlt (Bitte keine Diskussion ueber Sinnhaftigkeit dieser Auswahl. Es sind nur Beispiele um den Menuflow zu zeigen :shy:). Dann erscheint

    und es kann erst exim4 und dann cups gewaehlt werden.

    Danach erscheint zum Bestaetigen

    Damit wird erst exim4 und dann cups gestoppt. Start ist umgekehrt. Ist das halbwegs intuitiv? Ist ziemlich schwer einen halbwegs intuitiven Menuflow zu der ServiceSelection mit whiptail zu erstellen ||

  • Der Link im Ausgangspost ist Tod ;)

    Die Menus werden uber M3 -> C6 erreicht.

    M3 -> C7 ;)

    Ich finde es sehr sehr gut gelungen, einfach zu verwenden und gut umgesetzt. :)

    Das einzige was mir jetzt noch fehlt wäre wie schon mal vorgeschlagen aber abgelehnt, dass man dann dennoch einen Bereich hat, wo man eigene Befehle vor und nach dem Backup ausführen lassen kann:saint:(man kanns ja nochmals probieren):

    Das 2. Feld ist für individuelle Befehle die 1:1 so ausgeführt werden, wie angegeben.

    Bzgl der Services habe ich es dazu reduziert dass nur Services erlaubt sind. Keine Ausnahmen wie Du vorschlägst. Wer das will muss das manuell konfigurieren, denn es ist ein Spezialfall.

  • M3 -> C7 ;)

    Benutzt Du den aktuellen Code?

    Zitat

    Das einzige was mir jetzt noch fehlt wäre wie schon mal vorgeschlagen aber abgelehnt, dass man dann dennoch einen Bereich hat, wo man eigene Befehle vor und nach dem Backup ausführen lassen kann:saint:(man kanns ja nochmals probieren)

    Sorry - das ist irgendwie an mir vorbeigegangen. Ich bekomme über diverse Kanäle diverse Anfragen rein. Da kann es passieren dass im WebseitenKommentar/Facebook/twitter/Forum/eMail Gewirr was bei mir untergeht.

    Die von mir preferierte Methode ist ein Issue im Github zu erstellen. Da geht definitiv nichts verloren ;)

  • Benutzt Du den aktuellen Code?

    habe den Link von der Website verwendet:

    Code
    curl -s -L -O https://www.linux-tips-and-tricks.de/raspiBackupInstallUI_beta.sh && sudo bash raspiBackupInstallUI_beta.sh

    das ist irgendwie an mir vorbeigegangen.

    nene, nicht vorbeigegangen, du hattest es abgelehnt

    Bzgl der Services habe ich es dazu reduziert dass nur Services erlaubt sind. Keine Ausnahmen wie Du vorschlägst. Wer das will muss das manuell konfigurieren, denn es ist ein Spezialfall.

    Oder bezog sich das auf etwas anderes?

  • Eurer Feedback hilft mir sehr den Installer halbwegs benutzerfreundlich und verstaendlich zu gestalten :thumbup:

    Hilfreichen Feedback gab es bislang immer von - ich nenne sie mal - good citizens im Forum - also Leute die sich regelmässig im Forum bewegen und keine Einsteiger im Thema Linux sind. Ich wuerde es begruessen wenn auch Besucher dieses Forums die sich zu Einsteigern zaehlen Feedback geben wuerden. Genau fuer Diejenigen versuche ich ja das BackupLeben leichter zu machen :)

  • Zu Deinem zweiten Punkt. Da habe ich Dich offensichtlich falsch verstanden :-/

    jetzt weißt du aber was ich haben möchte oder?

    Der aktuelle development Code ist auf github verfuegbar.

    Ok, dann werd ich den Test morgen nochmals wiederholen, wobei ich auch schon die Services in einer Liste auswählen hab können.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!