Backup

Dieser Text ist Bestandteil des Software-Projektes 'Backup Data'
Version 23.01.1

Copyright (C) 2020 Richard Albrecht , www.rleofield.de
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see http://www.gnu.org/licenses/.

Install/Update
Beschreibung/Anwendung/Tests
Basis Konfiguration

Projekt bei GitHub Backup Data

Hintergrund

cron reicht nicht für rsnapshot

Ein Backup mit 'rsnapshot' ist an cron gebunden.
Cron setzt einen Server/Client voraus, der 24/7 online sein muss.

Um diese Abhängigkeit zu vermeiden, wird die implizite Buchführung durch 'cron' durch eine eigene Verwaltung ersetzt.

Damit ist eine Unterbrechung des Betriebs des Servers/des Clients möglich.
Die Backupfestplatten können in Pausen ausgetauscht werden, um eine Auslagerung der Backupfestplatte zur Sicherheit zu erreichen.

Bezeichnung der Projekte

Das Backup für eine Backupfestplatte besteht aus beliebig vielen Projekten, die Datenstrukturen auf der Datenquelle darstellen.
Grenzen sind nur durch die Größe der Backupfestplatte und der Datenstrukturen auf der Datenquelle gegeben. Pro Backupfestplatte können daher, je nach Platz, mehrere Projekte angelegt werden.

Eine Richtlinie für den verfügbaren Platz auf der Backupfestplatte ist, dass der freie Platz auf der Backupfestplatte ca. 30% beträgt. Der freie Platz sollte nicht unterschritten werden, um den Betrieb von 'Backup Data' nicht zu gefährden.

'rsnapshot' legt eine Historie der Daten an. Daher wird zusätzlicher Platz benötigt, um die alten Files in der Historie aufzuheben.

Wird das Ende der Historie erreicht, gibt 'rsnapshot' den Platz wieder frei. Meist ist das erst nach vielen Monaten der Fall.

Jede Backupfestplatte bekommt ein eindeutiges Label, das aus Kleinbuchstaben ohne Sonderzeichen und ohne Unterstrich '_' besteht.

Beispiel: fdisk
Falsch wäre: f_disk

Der Name eines Projektes mit den Daten auf der DatenHD wird ähnlich festgelegt. In den Daten kann es einen oder mehrere Verzeichnisbäume geben, die in das Backup aufgenommen werden sollen. Jedes Projekt hat individuelle Zeiten und Einträge in der Historie (s.u.).

Beispiel: pcbuero

Falsch wäre: pc_buero

Der Name der BackupHD und der Name des Projektes wird mit _ verbunden. (Label_Projekt)
Beispiel: fdisk_pcbuero

Das ergibt eindeutige Namen für jedes Backup, der die Zuordnung der Backupfestplatte und der Daten auf der Datenquelle im Projekt angibt. Quelle der Daten kann eine lokale HD oder ein via SSH erreichbarer Remote-PC sein.

Dieser Label_Projekt-Name wird in vielen Filenamen und Einstellungen verwendet, um einen Bezug auf das jeweilige Backup zu haben.¸

Beispiele:

Disk-Label	Daten	Label_Projekt
fdisk	pcbuero	fdisk_pcbuero
fdisk	pc5	fdisk_pc5
bdisk	pc5	bdisk_pc5
cdisk	pc5	cdisk_pc5

Im Beispiel werden auf 'fdisk' die Daten von 'pcbuero' und 'pc5' abgelegt.
Auf 'bdisk', 'cdisk' und 'fdisk' werden die Daten von 'pc5' abgelegt. Je nach Zeitfenster sind die Daten nicht immer gleich.

Verschlüsselung:

Hat der Label der Backupfestplatte 'luks' am Ende, werden die Daten verschlüsselt.
Beispiel: fluks
Für LUKS muss ein Schlüssel im Home-Verzeichnis von 'root' hinterlegt sein

Ablauf

Nach einem festgelegtem Intervall (z.Zt.1h), wird in jedem Backup in 'Label_Projekt' nachgeschaut, ob das für das Backup spezifische Intervall abgelaufen ist.
Ist das der Fall, wird die Backupfestplatte und die Datenquelle gesucht und, wenn möglich, das Backup ausgeführt.
Jedes Backup kann unterschiedliche Intervalle haben.

Backups werden sequenziell ausgeführt. Parallele Verarbeitung ist nicht vorgesehen.

D.h. je nach Backup-Liste kann sich eine Verschiebung der Startzeiten ergeben.

Durch 'rsync' ist der Zeitumfang pro Backup minimal, weil nur geänderte Files übertragen werden.

Ist alles gut eingerichtet, sind die Differenzen marginal. Selbst ein umfangreiches Backup ist nach wenigen Minuten erledigt.

Die Backupfestplatte kann jedesmal neu gemounted werden und wird danach auch wieder aus dem System entfernt (einstellbar).

Das Backup braucht root-Rechte:

• mount/umount der Backupfestplatte
• Backup von Systemfiles
• Remote-Backup mit Daten von Usern mit unbekannter ID

Verzögerungen:

• unzureichende Geschwindigkeit zur Backupfestplatte, USB 2.0 sollte vermieden werden
• langsame Netzverbindung, beim ersten Backup wichtig, danach weniger
• zu lange Abstände zwischen den Backups (viele Daten sind inzwischen geändert worden)

Wichtige Kommandos

Kommandos zum Start/Stop usw.

Mit 'cdb' (ein alias in .bashrc) kann man als 'root' in das Backup-Verzeichnis wechseln.
Alle Kommandos müssen mit './' ausgeführt werden, da das Backup-Verzeichnis nicht im Suchpfad der Bash liegt.

Start/Stop:

• tt.sh → Anzeige der letzten Logzeilen
• stop.sh → Stop des Backup, wenn fertig, mit tt.sh kontrollieren
• start_backup.sh → Start des Backup, sofort ohne Warten auf das Intervallende
• cron_start_backup.sh → Start des Backup, zur Verwendung in 'crontab' nach
       einem Reboot des PC

Info:

• show_disks.sh → Anzeige der mit dem PC verbundenen Backupfestplatten
       ist die HD via USB verbunden, aber z.Zt, nicht am PC,
       wird der Zeitpunkt des letzten Backups auf dieser HD angezeigt
• show_config.sh → zeigt alle Konfigurationen für alle Backups
• show_times.sh → zeigt die Intervallzeiten bis zum nächsten Backup

Test:

• test.sh → prüft die Syntax der Konfiguration und die
        Erreichbarkeit der Datenquelle bzw. des Remote-PC,
        die Backupfestplatte muss dazu gemounted sein

Verzeichnisse im Backup-Verzeichnis

conf/

Konfiguration für einzelne Backups im rsnapshot-Format
Label_Projekt.conf

done/

Datum des letzten Backup einer Konfiguration
Label_Projekt.done.log

exclude/

Liste von Verzeichnissen/Files, die nicht in das Backup sollen
siehe 'man rsync' in Linux
Label_Projekt

interval_done/

Protokoll der einzelnen Stufen des Backups
wird als Kontrolle der internen Buchhaltung verwendet
Label_Projekt.done.txt

oldlogs/

alle 24h werden die Logfiles vom Tag vorher hierher verschoben

pre/

Test auf Existenz der Daten auf der Datenquelle oder auf dem Remote-PC Label_Projekt.pre.sh

retains_count/

Buchhaltung der Anzahl der Backups in der Historie der Retain-Werte Label_Projekt.retainvalue

Logfiles

aa_*Label_Projekt*.log 
rr_*Label_Projekt*.log
cc_log.log  
trace.log

aa_Label_Projekt.log

alle Kommandos, die rsnapshot erzeugt und ausführt
inklusive aller rsync-Kommandos

rr_Label_Projekt.log

Ausgabe von rsync

cc_log.log

zentraler Log aller Vorgänge, wird mit tt.sh angezeigt

trace.log

Kurzform von 'cc_log.log'

Konfiguration

• conf/Label_Projekt.conf editieren, siehe Doku rsnapshot
    snapshot_root, retain Values (genau 4 Zeilen),
    Logfiles, backup-Zeilen für Datenquellen, lokal and/or remote
• exclude/Label_Projekt anpassen oder leer lassen
• pre/Label_Projekt.pre.sh anpassen (exit 0 = alles ok, exit 1 = Daten nicht erreichbar)

Mit test.sh Syntax testen.
Mit show_config.sh Konfiguration anzeigen lassen.

Wichtig:
Datenmengen in den Projekten sollten nicht zu groß werden.
Es ist besser, viele kleine Verzeichnisbäume im Backup zu haben, als alles unter einen großen Baum zu stellen. D.h. vor der Konfiguration des Backup sollten die eigenen Verzeichnisbäume entsprechend strukturiert werden. Verweise kann man mit symbolischen Links anlegen. Symbolische Links werden von rsync als Link kopiert, ohne die Daten dahinter.

File cfg.target_disk_list anpassen.

Hier steht die Reihenfolge der BackupHD-Label, die abgearbeitet werden.
In DISKLIST=Label Label2 .

File uuid.txt:
- enthält den Label und die UUID der BackupHD

File cfg.projects anpassen.

Hier steht die Reihenfolge der Abarbeitung der Projekte pro BackupHD und die Intervallzeiten zwischen den Backups für jedes Projekt. Das Backup prüft unabhängig davon zu jeder vollen Stunde, ob eines dieser Intervalle erreicht wurde. Zusätzlich kann angeben werden, ob die BackupHD neu gemounted und nach dem Backup wider getrennt wird. (nur bei USB sinnvoll, Label mit *luks werden mit cryptsetup geöffnet)).

Warnung: Läuft das Backup zu lange, d.h. sind die Intervalle zu knapp gewählt, kann es vorkommen, das beim Erreichen des Endes das nächste Intervall schon wieder fällig ist. Normalerweise läuft ein Backup nur wenige Minuten.

Dauert das Backup zu lange, kann das folgende Ursachen haben:
Backupfestplatte ist mit USB 2.0 verbunden oder es ist das erste Backup und alle Daten müssen kopiert werden
oder die BackupHD war lange nicht am PC und es haben sich sehr große Mengen an geänderten Daten ergeben
- daher ist ein zeitnaher Wechsel der Backupfestplatten sinnvoll

volle Festplatten

Das sollte nie vorkommen.!
Ist die Backupfestplatte sehr voll, kann das Backup so lange dauern, dass fast keine Pausen zur Kontrolle mehr entstehen. Daher sollte eine Backupfestplatte nur zu max. 2/3 gefüllt werden, um eine Reserve zu haben.
Wegen der Historie via rsnapshot werden Files im Backup u.U. erst nach Jahren entfernt. Man darf nicht einfach in der Historie Files löschen.

In der Ergebnisnotiz wird die Festplattenbelegung der Backupfestplatte angegeben. D.h. werden die 66% BackupHD-Füllung erreicht, sollte man sich Gedanken über das Backup-Konzept machen.

Ersatz der Backupfestplatte:
größere Backupfestplatte beschaffen, verkleinern ist wegen Historie nur schwer möglich
mit rsync -avSAXH kopieren
UUID anpassen
Testen

mount.sh Label / umount.sh Label

• Mounten bzw. Trennen einer Backupfestplatte an USB
• wird intern verwendet
• muss bei Ausführen von test.sh und einer USB-Backupfestplatte vorher ausgeführt werden.

Tests mit echten Daten:

Man kann die Option für rsync in conf/* mit 'n' (Dry RUN) erweitern, zum Test,
und in den Logfiles nachschauen, was passiert ist.

Start/Stop

Mit start_backup.sh starten.
Es wird eine Sperre angelegt, die einen 2. Start verhindert.
Mit stop.sh stoppen.
Es wird eine leere Datei 'stop' angelegt. Diese wird an geeigneten Stellen abgefragt. Der eigentliche Stop erfolgt an dieser geeigneten Stelle, aber nie im Verlauf eines Backup.

Log anschauen

Mit tt.sh kann man via Tail das laufende Log anschauen. Zur Kontrolle des erfolgreichen 'stop' verwendbar. Alle andere Logfiles könne mit tail/cut usw, angeschaut werden. Das ist nicht weiter vorbereitet.

Im Folder backup_messages_test/ werden kurze Info-Files über den Erfolg/Misserfolg angelegt.
Dieser Folder wird auf den Arbeitsplatz des Admin kopiert.
Das is in cfg.ssh_login konfigurierbar.

Workingfolder

Wird in /etc/rlf_backup_data.rc konfiguriert.
Beispiel: WORKINGFOLDER=/usr/local/bin/backup_data
Zur Laufzeit wird der Workingfolder nach cfg.working_folder kopiert.

Beispiel für einen rsnapshot Konfigurationsfile

config_version  1.2  
snapshot_root   /mnt/wdg/rs/tux2/
no_create_root  1
cmd_cp          /bin/cp
cmd_rm          /bin/rm
cmd_rsync       /usr/bin/rsync
cmd_ssh /usr/bin/ssh
cmd_logger      /usr/bin/logger
retain          eins    5
retain          zwei    4
retain          drei    3
retain          vier    2
verbose         2
loglevel        3
logfile /usr/local/bin/backup_data/aa_wdg_tux2.log
lockfile        /usr/local/bin/backup_data/rsnapshot.pid
rsync_short_args        -avSAX
rsync_long_args         --delete --numeric-ids --relative --delete-excluded --log-file=/usr/local/bin/backup_data/rr_wdg_tux2.log
ssh_args        -p 4194
exclude_file    /usr/local/bin/backup_data/exclude/wdg_tux2
link_dest       1
sync_first      1
use_lazy_deletes        1
backup  root@tux2:/root                 .
backup  root@tux2:/etc                  .
backup  root@tux2:/home/rleo            .
backup  root@tux2:/opt                  .
backup  root@tux2:/sbin                 .
backup  root@tux2:/var/log              .
backup  root@tux2:/usr/local/bin        .

// EOF