Neues raspiBackup Wrapperscript "Coldbackup" ?

  • Schon laenger bin ich in Kontakt mit jemandem der sich ein paar gute Gedanken daruber gemacht hat wie man unattended, also automatisch, ein Backup der Raspberry erstellen kann welches gestoppt wurde. Er hat es Coldbackup getauft. Die Idee ist gut: Man benutzt raspiBackup um eine Kopie des aktuell laufenden Systems zu erstellen, faehrt das aktuell laufende System normal runter, startet das eben geclonte System und fertigt mit dem ein Backup des gerade gestoppten Systems an. Dadurch sichert man ein gestopptes System und muss sich keine Gedanken ueber Stoppen von laufenden Services machen. Alleridings dauert der Backupprozess dadurch doppelt so lang da man das System einmal cloned und einmal sichert. Auch muss man zwei weitere Partitionen auf einem weiteren Medium bereitstellen auf welches man das aktuelle System cloned.

    Natuerlich sind dazu noch Aenderungen an raspiBackup notwendig und wir sind dran. Meine Frage in die Runde: Die Idee ist gut - hat aber auch gewisse Nachteile. Ich fuer meinen Teil brauche dieses Feature nicht. Auch bekomme ich oft Feedback dass der Backuprozess zu lange dauert und in der Zeit wichtige Services inaktiv sind. D.h. eine Verlaengerung der Backupzeit ist unattraktiv. Klar kann man gezielt ein zweites System irgendwo installieren welches zum Sichern des gestoppten Systems benutzt wird und sich damit den Clone sparen. Aber das erfordert dann wieder zusaetzlichen manuellen Konfigurationsaufwand und raspiBackup kann ja mittlerweile ohne manuelle Konfiguration nur durch den installer genutzt werden - jedenfalls sofern man keine speziellen Dinge macht.

    Da ich gerade andere Projekte am laufen habe befindet sich raspiBackup bei mir erst einmal im "Maintenance Mode", sprich, ich habe meine Bearbeitung der offenen git Issues erst einmal gestoppt aber bearbeite natürlich alle Problemberichte und beantworte wie gewohnt Fragen zu raspiBackup.

    Die notwendigen Aenderungen fuer Coldbackup werde ich in raspiBackup vornehmen und das Wrapperscript Coldbackup dann auch bei mir ins git Repo stellen.

    Mich wuerde nun mal interessieren was Ihr ueber Coldbackup denkt. Ist das eine gute Idee und wuerdet Ihr Coldbackup nutzen oder ist das aus Eurer Sicht verschwendete Zeit?

  • Irgendwie verstehe ich das ganze noch nicht.

    Man benutzt raspiBackup um eine Kopie des aktuell laufenden Systems zu erstellen,

    Das heißt also, es wird eine Kopie eines laufenden Systems erstellt

    und fertigt mit dem ein Backup des gerade gestoppten Systems an.

    Dann wird ein Backup erstellt von einer Kopie, die im laufenden Betrieb erstellt worden ist?

    Entweder stehe ich hier auf dem Schlauch, oder ich habe da etwas falsch verstanden.

    Auf jeden Fall sehe ich den Sinn nicht.

  • Auf jeden Fall sehe ich den Sinn nicht.

    Der Sinn ist ein Backup von einem gestoppten System zu erstellen. Die Schritte im Einzelnen. Dadurch wird hoffentlich das Prinzip klarer :)

    Gegeben:

    1) System Raspian R

    2) Freie Partitionen für ein zweites geclontes System C

    3) Backuppartition B

    Schritte:

    1) Clone laufendes R auf C mit raspiBackup

    2) Stoppe R

    3) Starte C

    4) Backup gestopptes R auf B mit raspiBackup

    5) Starte R

  • Dadurch wird hoffentlich das Prinzip klarer

    Ja, jetzt wird das Prinzip etwas klarer.

    Das heißt, das Backup wird nicht von dem Clone erstellt, sondern von dem gestoppten "inaktiven" System. Das geclonte System wird nur zur Ausführung benutzt.

    Ist das eine gute Idee und wuerdet Ihr Coldbackup nutzen oder ist das aus Eurer Sicht verschwendete Zeit?

    Ich persönlich würde es nicht nutzen, da ich bisher keine Probleme mit dem Backup (Restore) vom laufenden System gehabt habe.

    Ist zwar eine Möglichkeit (Spielerei?) Für einen Laien, der sich mit raspiBackup schon schwer tut, eine weitere Hürde.

    Benötigt wird zumindest ein Systemdatenträger (SD oder SSD) ein weiterer Datenträger mit zwei Partitionen (Backup und Clone) oder ein dritter Datenträger.

    Im letzteren Fall gibt es dann u.U wieder "undervoltage" wenn kein aktiver Hub benutzt wird.....

    • Offizieller Beitrag

    Ist zwar eine Möglichkeit (Spielerei?)

    Sehe ich auch so.

    Das was raspiBackup aus den Backupmöglickeiten besonders hervorhebt ist ja gerade, dass man im laufenden Betrieb sein System sichern kann und das mit einer vielzahl von Optionen.

    Der Gedanke ansich ist ja nicht schlecht. Man hätte ein fertiges System auf (z.B. SD-Karte), auf dem per RPi OS Lite(?) einfach nur raspiBackup läuft. Cool wäre, wenn man gleich nach dem Start in einem Menue von raspiBackup landen würde, in dem man Quelle, Ziel und Optionen auswählen kann. Usw.

    Wenn, dann würde ich soetwas ggf. extra als kleines Image zum download zur Verfügung stellen, aber nicht unbedingt im Hauptprojekt integrieren.

  • Hallo,

    ich nutze raspiBackup auch, weil es im im laufenden Betrieb ausgeführt werden kann. Ich muss zugeben, dass ich die Backup's nicht ganz so regelmäßig teste, aber dennoch hatte ich noch nie Probleme damit.

    Mir persönlich wäre der Aufwand auch zu hoch, wenn doch mal ein Restore fehl schlagen würde, habe ich zum einen ein funktionierendes Backup immer noch irgendwo gesichert und im Notfall bekommt man (ich) mein System auch so wieder hin, ist halt zeitaufwändig.

    Wenn ich mal ein System habe, das so wichtig ist, das einen hohen Aufwand an Backup-Strategie benötigt, dann würde ich als erstes den "Bastelrechner" ersetzen.

    framp kümmere dich in dieser Zeit lieber du deine eigenen Projekte, das muss auch mal sein :)

    Grüße

    Dennis

    🎧 With the music execution and the talk of revolution, it bleeds in me and it goes 🎧

  • Wenn, dann würde ich soetwas ggf. extra als kleines Image zum download zur Verfügung stellen, aber nicht unbedingt im Hauptprojekt integrieren.

    Ein Image zu erstellen davor werde ich mich hueten denn dann bin ich Fulltime dabei das Image wieder zu updaten weil es immer wieder irgendwelche Besonderheiten bei den raspiBackup Nutzern gibt :no_sad: . Auch muesste dann der Installer zwei weitere Partitionen fuer den Clone anlegen. Ich wage jetzt nicht daran zu denken was das fuer ein Testaufwand ist :-/

    Nee, deshalb ist der Weg mit einem Wrapperscript welches as is fuer Fortgeschrittene raspiBackup Nutzer zur Verfuegung gestellt wird der einzige Weg den ich sehe um dieses eigentlich nette Feature anzubieten. Wer es nutzen will kann dann ja auch ein kleines Image vorbereiten und nutzen. Man muesste das in Coldbackup dann noch vorsehen.

  • Ich bin ehrlich gesagt auch noch nicht ganz überzeugt von der Idee.

    Wenn ich das System runterfahre und ein "geclontes" System starte, dann nehme ich lieber gleich das ganze Bootmedium (SD-Karte / USB-Stick) aus dem Pi und kopiere (clone) auf ein neues Medium.

    Das ist dann nur solange identisch, bis wieder eine der Installationen geändert wird.

    Bei Boot von einer SSD nicht ganz so einfach ;) .

    Aber wenn, würde m.E. dieses Konzept des automatischen "Coldbackups" nur dann Sinn machen wenn ich auf ein externes Medium (NAS-Share?) sichern kann.

    Ein Backup auf demselben Medium ist für mich kein Backup, nur eine Duplizierung. Fällt das Medium irgendeinem Schaden zum Opfer, ist beides weg. Das ist nicht der Sinn eines Backups.

    Gruss

  • Also ich will mich hier gleich einmal einklinken um ein hin und her an Fragen zu vermeiden. Die Idee und die erste Version zu raspiColdBackup ist bereits mehr als vier Jahre alt und entstand nachdem ich raspiBackup im Netz gefunden hatte. Meine erste Version hat jedoch den Nachteil, dass darin alles selbst programmiert ist und, aufgrund der wenigen Nutzer auch nicht so ausgreift ist. Die neue Version ist ein Wrapper und nutzt die gut durchentwickelten Komponenten von raspiBackup. Zu der Zeit plagte mich aber auch ein anderes Problem. Ich war :( vor Corona im Sommer viel mit dem Camper unterwegs und muss mich dann auf mein Smarthome verlassen können. Dieses erledigt u.a. auch die Bewässerung des Gartens. Und was passiert wenn man unterwegs ist? Na klar, das System streikt. Also habe ich ein System gesucht was mich bei der Behebung von Störungen aus der Ferne unterstützen kann.

    Liegt der Raspi auf dem Schreibtisch und macht man vielleicht über raspiBackup hinaus ohnehin gelegentlich mal ein Image von dessen SD-Karte macht das Ganze natürlich nicht viel Sinn. Ist das System jedoch räumlich schwer erreichbar und ist zudem die Bandbreite zu diesem begrenzt sieht das ggf. schon anders aus. Dann kann es schon sinnvoll sein das Backup auf einem direkt angeschlossenem USB- Device zu speichern und das System aus der Ferne wiederbelebbar zu machen.

    Aber nun zur Vorstellung des Skriptes (Beta):

    raspiColdBackup.sh ist kein eigenständiges Skript, es ist ein Wrapper der raspiBackup.sh und dessen Helper um die Funktionalität "ColdBackup" erweitert. Damit stehen in raspiColdBackup viele Funktionen aus raspiBackup.sh zur Verfügung. Es werden auch Einstellungen aus der raspiBackup.conf gezogen. Deshalb verweise ich zunächst auf folgende Seiten: http://www.linux-tips-and-tricks.de/raspiBackup oder https://github.com/framps/raspiBackup

    Zielstellung:

    - Erstellen eines Backups der gesamten SD-Karte (MMC) im Raspberry Pi (Raspi) im ungenutzten Zustand der root Partition. Dies entspricht einem Backup der MMC, nach deren Entnahme, in einem Kartenlesegerät (ColdBackup).

    - Damit sollen mögliche Inkonsistenzen des Filesystems durch geöffnete Dateien vermieden werden, wie dies, bei einem Backup im ausgeführtem Zustand wie z.B. mittels raspiBackup.sh passieren könnte. Im Weiteren soll die Mitnahme von Filesystemfehlern, wie es mit dd (Images) möglich ist, verhindert werden.

    - Alle Dienste sollen während der Backupzeit - nur beschränkt durch zweimaliges reboot - verfügbar sein.

    - Möglichst einfache Handhabung. Mit der Definition von Clone- und Backup- Device im Initialteil des Skriptes ist zur Ausführung einer Aktion die Angabe keiner oder nur einer Option erforderlich.

    - Die Möglichkeit den Raspi von einem USB- Device auszuführen eröffnet weitere nützliche Funktionen. So kann z.B. ein fsck auf die MMC angewendet werden, was im eingehängten Zustand von /root nicht funktioniert.

    - Im Weiteren besteht die Möglichkeit den Clone für Testzwecke einzusetzen. Zu beachten ist allerdings, dass sich dabei nicht der Kernel Patchlevel verändert, da dabei die gemeinsame genutzte /boot Partition verändert wird. Mittels --reclone kann der Clone nach dem Test wieder auf den Stand von /root der MMC gebracht werden.

    - Weitere Funktionen dieses Skriptes können für Raspi's nützlich sein die räumlich nur schwer zugänglich sind. So ist u.U. die Fortsetzung des Betriebes nach Systemhängern möglich, wenn der Raspi z.B. in einen Smarthome mittels 'ping' überwacht wird und ein Neustart über eine Schaltsteckdose erzwungen werden kann. Um dabei ein erneutes hängen auszuschließen kann der Raspi mit der Option --nextbootusb veranlasst werden dann von USB zu booten. Anschließend kann die MMC mittels --restoremmc aus dem Backup wiederhergestellt werden. Ein daran anschließendes, manuelles --bootmmc bringt den Raspi wieder auf die MMC zurück. Erfahrungsgemäß ist die MMC selten wirklich defekt und Fehler treten meist auf der /root Partition auf. I.d.R. lässt sie sich erneut beschreiben. Über ein Reboot des Systems kann man sich leicht durch einen Eintrag in der /etc/rc.local in folgender Form informieren lassen: /usr/local/bin/raspiImageMail.sh "$(hostname)" "Boot von: $(mount|grep "on / "|cut -d ' ' -f1)"

    Voraussetzungen:

    - raspiBackup muss eingerichtet und funktionstüchtig sein.

    - Ein USB-Device (Stick, SSD, o.ä), mit einer ausreichend großen EXT4 Partition zur Aufnahme einer Kopie des Inhalts der root- Partition der MMC. Es ist nur der von /dev/root belegt Platz auf dem USB- Device (Clone) erforderlich.

    - Auf der MMC befinden sich nur zwei Partitionen (/boot und /root).

    - Das OS ist Jessie, Stretch oder Buster. Wheezy wird nicht Unterstützt.

    - Es ist Platz, in der doppelten Größe der MMC, auf einem Backupmedium (USB-Partition, NFS-Device) mit EXT4 erforderlich. Benötigt werden die Skripte raspiBackup.sh (V. 0.6.7), raspiBackup2Image.sh, sowie das Script raspiImageMail.sh in den passenden Versionen. Siehe: http://www.linux-tips-and http://tricks.de/raspiBackup

    - pishrink.sh zur Reduzierung der Image- Größe. Siehe: https://github.com/Drewsif/PiShrink

    - Soll eine Ergebnis- eMail aus raspiColdBackup.sh versendet werden muss raspiBackup.conf für eMail konfiguriert sein und es muss das Programm raspiImageMail.sh in /usr/local/bin vorhanden sein.

    Vorgehensweise beim Coldbackup:

    - Von der root- Partition wird mit rsync ein Clone auf der Partition eines EXT4 USB- Devices erstellt. Dazu wird zuvor das Filesystem auf dem USB- Device neu erstellt. Achtung, es gehen alle darauf befindlichen Daten verloren.

    - Anschließend bootet der Raspi von dieser USB- Partition (dem Clone von /root).

    - Es wird mittels raspiBackup.sh ein Backup von /root der MMC im Mode rsync, sowie von /boot (dd) erzeugt.

    - Aus dem Fileverzeichnis des Backups wird mittels raspiBackup2Image.sh eine Image- Datei erstellt und unter Zuhilfenahme von pishrink.sh die Dateigröße minimiert. Die Basisdaten aus rsync werden nach dem Erstellen des Images aus dem Backup gelöscht. Das kann mit --noclear unterbunden werden.

    - Der Raspi bootet erneut und wird wieder von der MMC ausgeführt. Damit ist das ColdBackup abgeschlossen.

    - Dieses Image (Restore) kann später, wie gewohnt, auf eine MMC kopiert werden. Beim ersten Start erfolgt eine Expansion des Filesystems so dass der gesamte frei Platz auf der MMC für /root verfügbar wird.

    Anwendung:

    - Vor der ersten Verwendung muss raspiBackup installiert sein und es müssen die Variablen im Initialisierungsteil des Skriptes gesetzt werden. Ein USB- Device kann mit der Option --usb2ext4 für das ColdBackup vorbereitet werden. Dabei wird eine Partition für den Clone in der Größe von /root und aus dem Rest eine Partition für Backups erstellt.

    - Im Normalfall wird das Script 'sudo raspiColdBackup.sh' ohne Parameter aufgerufen. Es werden die Variablen CLONE_DEV_PARTUUID, BACKUP_DEV_PARTUUID und CMD_MOUNT_BACKUP_MPT aus dem Initialisierungsteil für alle Aktionen, mit und ohne Angabe von Optionen benutzt.

    Beispiel-1: Clone auf USB, Backup auf NFS

    CLONE_DEV_PARTUUID="64d44972-02" #USB Devices

    CMD_MOUNT_BACKUP_MPT="mount -t nfs -o soft,nolock,rw 192.168.1.2:/RaspiBackup /raspibackup"

    Beispiel-2: Clone und Backup auf einer SSD

    CLONE_DEV_PARTUUID="c4bcd995-4d12-5c42-9105-3fdf7164ae92" Partition 1

    BACKUP_DEV_PARTUUID="91fa4c00-029e-c94d-b4dd-4723fa80699d" Partition 2

    - Es können beim Programmaufruf auch Parameter angeben welche die Variablen im Initialisierungsteil überschreiben. Welche steht dann im Help.

    sudo raspiColdBackup.sh [<CLONE-DEV|PARTUUID>] [<BACKUP_DEV|PARTUUID|BACKUP_PATH>] [options]

    Wird <backup-path> übergeben ist ein entsprechender Eintrag in der fstab erforderlich.

    Optionen:

    --force Unterdrückt die Sicherheitsabfrage vor dem Formatieren von CLONE-DEV für die Ausführung z.B. aus cron.

    --help Kurzbeschreibung.

    --noclone Klont nicht. Achtung! Unterschiede im Patchstand zwischen MMC und Clone können ein boot verhindern.

    --nomail Verhindert das Versenden einer eMail, auch dann, wenn Mail in raspiBackup.conf konfiguriert ist.

    --noclear Die Daten, die beim Backup mir rsync erstellt wurden werden nach dem Backup nicht gelöscht

    --noreboot Es wird kein automatisches reboot am Ende der Skripte auf dem USB- Host ausgeführt. Um das Skript fortzusetzen ist die Eingabe von 'reboot' erforderlich. Das ermöglicht beispielsweise ein manuelles 'fsck' auf der MMC nach dem Backup ohne dazu erneut von USB booten zu müssen.

    --verbose Ausführliche Protokollierung.

    Spezial Optionen: (dabei wird kein Coldbackup durchgeführt)

    --bootmmc Bootet von der MMC, sofern der Raspberry von USB läuft.

    --bootusb Bootet das System vom USB- Device. Es wird davon ausgegangen, dass ein funktionsfähiger Clone vorhanden ist.

    --debug Unterstützt bei der Untersuchung von Parameterproblemen, stoppt nach der Anzeige der Parameterverarbeitung.

    --nextbootmmc Das System wird beim nächsten Boot bzw. nach Stromunterbrechung von MMC gebootet.

    --nextbootusb Das System wird beim nächsten Boot bzw. nach Stromunterbrechung von USB gebootet.

    --reclone Aktualisiert den Clone.

    --restoremmc Kopiert die Imagedatei mittels dd (<hostname>.dd) aus dem jüngsten Backup auf die MMC.

    --status Zeigt die wichtigsten Daten der raspiColdBackup- Umgebung an.

    --usb2ext4 Für die einfache Verwendung von raspiColdBackup kann hiermit ein USB- Device vorbereitet werden. Es werden zwei Partitionen erstellt. Partition CLONE in der Größe der MMC und die Partition BACKUP im Rest des Devices, welche mindestens die doppelte Größe der MMC aufweisen muss.

    --usb2fat32 Formatiert ein USB- Device mit einer fat32 Partition für die Verwendung unter Windows.

    Bemerkungen:

    - Das Backup- Device muss zur Laufzeit automatisch mountbar sein. Dazu muss es entweder direkt am Raspberry Pi angeschlossen sein oder/und in der fstab eingetragen sein. Beim Aufruf ohne Parameter kann das mount- Kommando, wie oben beschrieben auch direkt im Init- Teil dieses Skriptes angegeben werden. Dann ist kein Eintrag in der fstab erforderlich. Einträge in der fstab sollte die Option 'noauto' verwenden um das Backup vor ungewolltem Zugriff zu schützen.

    - Beide für das ColdBackup erforderlichen Partitionen können sich auch auf ein und demselben USB- Device befinden.

    - Die Dateien raspiColdBackupXXX.log, werden jeweils für MMC und USB, bei Erfolg, ins Backupverzeichnis kopiert.

    - Zur besseren Orientierung wird dem Prompt auf dem Clone Device ein [USB] vorangestellt.

    - Ist der Raspi mit externen Systemen, wie z.B. Datenbanken verbunden, wird es ggf. erforderlich sein diese vor den reboot- Vorgängen zu schließen. Hierfür ist ein ausführbares Script namens 'raspiColdBackupHelper.sh' zu erstellen. Dieses Skript wird jeweils vor dem reboot des Raspi's ausgeführt. Das Skript darf keine Anweisungen enthalten, die zu einer Endlosschleife führen, da der Bootvorgang dadurch nicht beendet werden könnte.

    - Werden Daten auf dem Raspi gespeichert, die unabhängig vom boot- Device (MMC/USB) verfügbar sein sollen, müssen diese auf einem USB oder NFS Device abgelegt werden. Diese Daten sind allerdings nicht Bestandteil des ColdBackup's, können aber beispielsweise innerhalb des Skriptes raspiColdBackupHelper.sh gesichert werden.

    Natürlich ist auch der gemischte Betrieb möglich. Man beschränkt sich auf die Erstellung eines Clones um damit einen Wiederanlauf nach Systemhängern zu ermöglichen und macht das Backup regelmäßig mit raspiBackup übers Netzwerk. Stellt raspiBackup im Ergebnis ein Image bereit ist auch die Wiederherstellung der MMC über raspiColdBackup denkbar. Ich selbst benutze eine Kombination aus raspiBackup und raspiColdbackup. Ich mache jede Woche via cron ein Backup mittels raspiBackup. RaspiColdbackup führe ich nur nach größeren Änderungen durch (Backup auf USB). Nach kleineren Änderungen wird lediglich der Clone aktualisiert. Mitunter läuft einer der drei Raspi's des Smarthomesystems aber auch mal ein halbes Jahr ohne Änderungen.

    Nachdem Kennenlernen von raspiBackup suchte ich den Kontakt zum Autor dieses Skriptes weil ich damals spezielle Wünsche hatte. So wollte ich beim Backup über WLAN wegen mangelnder Bandbreite (zum Gewächshaus im Garten) nicht die ganze MMC kopieren sondern nur die darauf befindlichen Dateien. Der Nachteil, auf dem Backup- Medium stand kein fertiges Image aus dem Backup bereit. Damit war die Idee für raspiBackup2Image geboren, welche vom raspiBackup- Autor auch super umgesetzt wurde. RaspiBackup2Image ist nun ebenfalls zentraler Baustein von raspiColdBackup. So aktivierte ich jetzt diesen Kontakt wieder weil zur Umsetzung des Wrappers einige Erweiterungen in raspiBackup erforderlich waren. Ich danke dem Autor dafür und auch für Hinweise die ich während dieses Prozesses von ihm erhielt.

  • . Dieses erledigt u.a. auch die Bewässerung des Gartens. Und was passiert wenn man unterwegs ist? Na klar, das System streikt. Also habe ich ein System gesucht was mich bei der Behebung von Störungen aus der Ferne unterstützen kann.

    Huhu,

    Ich nutze auch erfolgreich raspiBackup :bravo2: , ich kann auch Dich verstehen kmbach.

    Aber für ein Garten hab ich immer noch den Nachbarn, wenn ich im Urlaub bin und wenn der Nachbar in Urlaub geht mach ich das gleiche für Ihn.

    Wenn das System streikt beim hochfahren, warum hat man es rutergefahren.Ein Raspberry braucht nicht viel Strom wenn er im Urlaub mal 7/24 an ist.

    Und wenn ein Hardware def. vorliegt nützt selbst ein Backup nichts.

    Wenn man das braucht kann man es machen, dann lohnt sich der Aufwand.

    Ich mach täglich ein Backup mit raspiBackup und einmal in der Woche spiele ich es auf ein USB/SDD auf um es zu testen. Sollte mal eines nicht gehen, kann ich immernoch auf das andere zurückgreifen was ging.

    Natürlich ist der Aufwand mit Zeit verbunden, aber die Zeit nutze ich gerne.

    Idee ist nicht schlecht.

    LG

Jetzt mitmachen!

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