Kategorie:Intern:Backup

InArbeit scheint ein Euphemismus für hier müssen wir dringend was tun sein

Ich muss einen Weg finden, einen Überbick zu geben und dennoch auch die Details zu beschreiben. Eine Mischung der hier aufgeführten älteren Texte, neuerer Struktur und fehlenden Infos bilden wohl die ganze Wahrheit

• Intern:NAS beschreibt die Organisation unsere Network Storages (paris, stockholm, videostation) ganz gut
• es fehlt die Beschreibung des Teils des Backup-Bereiches (der sich mit dem Backup von Stockholm vermischt), den wir von unseren Maschinen aus befüllen und via NAS nach Stockholm doppeln. Dies sind
  • Autopoll24-Datenbanken (Firebird)
  • mysql-Datenbanken (aller) Hosts
  • ....
• Intern:Backup_Spaces beschreibt die Backup Spaces beim manuti, ich kann aber von extern gerade nicht darauf zugreifen.

Ich versuch das ganze nun neuaufzubauen! Diese Seite enthällt noch alte Abschnitte am Ende, es ist aber der richtige Ort für die Strategie

Das ist hier also ein Stück Knete was ich noch forme, Informationen können sich noch verschieben, verändern oder gar als Ergebnisse nur im SourceCode landen

Diese Kategorie ist gleichzeitig der zentrale Ort zur Beschreibung der Strategie. Wir wollen hier vollständig erfassen was zu sichern ist. Wo es redundant und örtlich getrennt gehalten wird.

Die praktische Implementation ist dann immer an den einzelnen "Geräten" beschrieben, dorthin wird von hier verlinkt.

Ggf gibt es noch Seiten, die nicht ganz in dieses Schema passen, wie Intern:Backup_Spaces zum Beispiel. Da wurde Dinge in der Beschreibung gedoppelt, wichtig ist dann gegenseitig zu verlinken.

Es gab hier (bis 16.10.2024) eine Beschreibung der Aufgaben der einzelnen Geräte/Server. Das ist jetzt hier weg und umgezogen nach Kategorie:Intern:RootServer.

zentrales Frontend und einige weitere Webseiten

Übersicht: Kategorie:Intern:RootServerXL02

Backup: Intern:ManituServer02_Backup

Zu sichern sind:

• MariaDB von Autopoll-Frontend/Hekpdesk
• MariaDB der Autopoll-Doku
• Mediadateien der Autopoll-Doku
• git-Repositories, in denen sich auch jeweils die aktuellen Source der Anwendungen befinden

Was machen wir mit:

• Download Bereich unserer Webseite
• ocpp-Server hat nur die Datenbank, die im Rahmen der regulären MariaDB-Sicherung, gesichert wird, wenn er in Produktion geht, ggf die Dateien des Up and Downloads.
• kmStands-APP hätte die Dateien mit den QR-Codes, die man aber jederzeit neu erstellen kann.

Die weiteren Webseiten sind alles Wordpress-Installtionen, die über ein Plugin einen vollständigen Backup in einen Intern:Backup_Spaces schreiben

Zudem werden deren mariaDB-Datenbanken im Rahmen des automatisierten MariaDB-Backups aller in den Metadaten hinterlegten Datenbanken, nocheinmal gesichert.

Hat derzeit KEINEN Backup seiner Daten

Übersicht: Kategorie:Intern:RootServerM03

Backup: Intern:ManituServer03_Backup

zu sichernde Daten (alles offen):

• MariaDB - Datensicherungen autom aller vorhandenen Datenbanken, das ist das zukunftsicher
• openVPN network 03 und 04 haben Ihre Daten in je einem git, aber noch ohne RemoteRepositories, diese Bare-Repositories wären zu sichern
  • Lösung A, einfach auf autopoll.de/srv/git/autopoll schießen, dann geht es in das Standard-Verfahren
  • Lösung B, was analoges zum autopoll.de aufbauen.
• Konfiguration der openVPN-Netzwerke und von WireGuard unter /etc.. sollten wir auch sichern.
• Der Support-Proxy besteht nur aus einem zu installierendem Server (noch undokumentiert) vgl Intern:ManituServer03_Dienste und seinen Daten unter MariaDB und ist damit gesichert.

wird abgebaut und zieht um nach pve08 Manitu

Übersicht: Intern:VirtualServer06

• täglicher lokaler Backup, die letzten 5 Versionen werden gehalten.
• täglicher Backup auf unseres Promox-BackupServer
• Problem, die Daten der virtuellen Maschinen werden größtenteils gesichert und verteilt, die virtuellen Maschinen selbst nicht.
• Unter \\paris\backup\proxmox.... befinden sich (halbwegs) aktuelle Sicherungen als Kopie, außerhalb des pve06 Gehäuses

Wir verbessern hier nicht mehr vollständig, weil der Rechner neu aufgebaut wird.

Backup-Tasks

von	ca. bis	Aufgabe
21:00	22:15	Proxmox Backup lokal nach hdbackup
22:30	23:40	Proxmox Backup nach Proxmox-BackupServer

• stellt BackupSpace im größeres Ausmass zur Verfügung, mit 100GB je Server im manitu BackupSpace werden wir nicht auskommen, die 5-fach Sicherung unserer VM auf pve06, belegt bereits 1,5TB
• Nimmt Sicherung von Proxmox I, Proxmox II und pve06 direkt von der Proxmox-Virtualisierung entgegen.
• weitere Dateien lassen sich über API integrieren, aber noch offen-

Ersatzgerät für den abgebrannten Entwicklungsserver pve05

zu sichernde Daten:

• einige Konfigurationsdateien, die im Proxmox vom Standard abweichen.
• WireGuard Konfiguration
• Proxmox interner Backup von 2 Versionen jeder virtuellen Maschine, auf der anderen Platte, also nicht da, wo die VM ihre Platten hat. Weniger Platz daher nur zwei und nicht 5, wie bisher. (done)
• Datensicherung aller VMs auf den Proxmox-Backup-Server, welche Dateien der Backup Server aufhebt, entscheidet er.
• Kopie einer aktuellen Version (ohne Datum) auf den anderen Proxmox Server bei Manitu, um schnell reagieren zu können, alte erst löschen wenn neue vorhanden das machen wir mit rsync.
• Kopien der Backups mit Hashwert prüfen (python?)
• Analog Kopie einer der aktuellen Versionen auf den Strato/Hetzner Backup
• läßt man das Verteilen der Kopien nicht besser den BackUp-Server machen, um die Produktonsmaschinen zu entlasten. => NEIN, dann wäre man von einem Backup abbängig, die einzelnen Prozeße müssen unabhängig voneinander sein.
• Die extra Sicherung von Inhalten der VMs ist bei der jeweiligen VM beschrieben.

Backup-Tasks

von	ca. bis	Aufgabe
20:00	20:10	Proxmox Backup lokal von ssd1
21:00	21:05	Proxmox Backup lokal von ssd2
21:30	21:40	copy letze Sicherung nach exchange
21:30	21:40	rsync von exchange/ssd1 nach Proxmox-I
21:30	21:40	rsync von exchange/ssd2 nach Proxmox-I
22:00	22:05	Proxmox Backup nach Proxmox-BackupServer

Ersatzgerät für pve06, zur Auslagerung der Produktionsmaschinen

• analog zu apmanituRXL05

Backup-Tasks

von	ca. bis	Aufgabe
20:00	20:10	Proxmox Backup lokal von ssd1
21:00	21:05	Proxmox Backup lokal von ssd2
21:30	21:40	copy letze Sicherung nach exchange
21:30	21:40	rsync von exchange/ssd1 nach Proxmox-I
21:30	21:40	rsync von exchange/ssd2 nach Proxmox-I
22:00	22:05	Proxmox Backup nach Proxmox-BackupServer

Backup-Tasks

von	ca. Dauer	debianProd	Proxmox I	Proxmox II	Proxmox pve06	Proxmox pve04
19:45	75min	gdb -> gbk
21:00			-> ssd1	-> PrxBackup	-> hdBackup
21:20			-> ssd2	-> ssd1
21:40			-> PrxBackup	-> ssd2
22:00			-> exchange	-> exchange
22:10			-> crypto (/mnt/ssd1u2/hetzner)	-> crypto (offen)
22:20				-> rsync ssd1 PrxI
22:40				-> rsync ssd2 PrxI
23:00			-> rsync ssd1 PrxII
23:20			-> rsync ssd2 PrxII
23:40			-> rsync HETZNER (offen)
0:00				-> rsync HETZNER (offen)

Übersicht: [1]

Falls bei manitu der Supergau ausbricht, wollen wir noch auf unsere virtuellen Maschinen zugreifen können. D.h. wir kopieren die jeweils letzte Fassung, also die aus dem Exchange Ordner, per rsync auf ein Hetzner-Storage. Auf dem Storage können wir auch Snapshots festlegen und damit ein wenig Historie aufheben.

Auf unseren "eigenen" ProduktionsVMS bei manitu verschlüsseln wir nicht, wir wollen schnell und gut arbeiten, und haben die Maschinen hoffentlich dicht genug gemacht.

Die Daten bei Hetzner liegen auf einem günstigen Storage, da haben wir wenig selber in der Hand wir sollten sie nur verschlüsselt ablegen.

Standardverfahren, aus einem Passwort und einem zufälligen SALT erzeugt man einen Schlüssel. Zudem brauche gute Koderungsverfaren noch einen iv (initialisation-Vector). Verschlüsselt man viele Dateien mit gleichem Key und gleichen IV, kann unter Umständen auf den Key zurückgeschlossen werden.

Es genügt aber nicht SALT und IV auf der Quellen zu speichern, denn wir die kaputt ist, bekommt man die Datei nicht wieder auf. Daher speichert man normalerweise Salt und IV am Anfang der Datei, in definiertert Länge.

Wir können mit symetrscher Verschlüsselung arbeiten, weil wir die verschlüsselten Dateien auf Hetzner ablegen und ggf wieder abholen, müssen wir sie dort nie entschlüsseln, der Passwort kann bei uns bleiben.

Das Password befindet sich im Keepass. Python Skripte zum entschlüsseln, es würde auch mit openssh auf der Komandozeile gehen (dazu auch ein Beispiel) befindet sich im Sicherungs-USB.Stick. (ALLES NOCH OFFEN).

• virtuelle Maschinen
  • debianProduktion2021
  • WS2022Prod02-08
  • W7WebAPRatio02
  • lennyMailSrv
  • Testmaschinen rn/vo/tg
  • Entwicklung WebTG, WebRN, Delphi12
  • SupportKnettenbrech
  • HomeAssitant
  • DesktopTG

• NAS
  • paris
  • stockholm
  • videowuerfel
  • lazarus(da steht noch ein leeres kleines NAS rum)

Dieses ist die Überblick Seite für den Backup, der sich in verschiedene Bereiche gliedert und dennoch gemeinsam betrachtet werden muss.

1) "ältere" Texte

• Intern:Backup versucht einen Überblick zu geben
• Intern:NAS beschreibt die Organisation unsere Network Storages (paris, stockholm, videostation)
• Intern:XEN-VM_Sicherung beschreibt die Sicherung unsere virtuellen Maschinen
• Intern:Cronjobs_und_Maintenance beschreibt die regelmäßigen Jobs, dabei sind auch Backups enthalten

2) "neuere Struktur"

• Intern:Backup_Autopoll24 beschreibt die Datensicherungsanforderungen und Realisierung für Autopoll-24
• Intern:Backup_WebSitesEntwicklung beschreibt die Datensicherungsanforderungen für unsere Webseiten und die Entwicklungssourcen
• Intern:Backup_NAS beschreibt die Datensicherungsrealisierung auf unseren NAS (ehemals Intern:NAS)

Datensicherunganforderungen für unseren lokalen Arbeitsplatz PC's gibt es nicht, denn auf denen wird nichts wichtiges gespeichert. Alle Daten die im Betrieb so anfallen werden auf dem NAS paris unter \\paris\sdctec[\autopoll] abgelegt und sind damit Teil der NAS Sicherungstrategie.