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.

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

zentraler Kommunikationsschnittpunkt für

• VPN03 Autopoll-24 Router
• VPN04 support Proxy (in Entwicklung)
• wg0 WireGuard Netzwerk zwischen unseren Servern (in Entwicklung)

Ü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

• Hat intern zwei SSDs für die Produktionsdaten und eine HDD für die Backup-Daten
• täglicher Backup, die letzten 5 Versionen werden gehalten.
• 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, weil der Rechner neu aufgebaut wird.

Ersatzgerät für den abgebrannten Entwicklungsserver pve05

• Im Aufbau, warten auf Bereitstellung der Hardware durch Manitu
• Eigentlich wird sich die Maschine eher langweilen, wenn die paar Test und Entwicklungsmaschinen drauf sind
• aber wir wollen Produktion und Entwicklung trennen, zudem können sich die beiden Maschinen gegenseitig spiegeln
• Wir spiegeln aber manuell, an einen pveCluster traue ich mich erst nach lokalen Tests, dafür bräuchte ich auch drei Machinen.

• öffentliche IP Adresse nur für ssh
• Zugriff über WireGuard, wir teilen ein Segment .255 von I-Adresse in 16er Teile. dann haben wir 14 IP-Adressen, eine für den Server und 13 für virtuelle Maschinen, das sollte reichen. Also 10.12.50.0/28 mit 10.12.50.0 - 10.12.50.15, dann 10.12.50.16/28 usw. Diese 8 Segmente können wir dann für unseren Komunikation-Server, in Griesheim und auf den einzelnen physikalischen Servern nutzen und untereinander sollte das routebar sein. Aber pve06 hat zur Zeit als alleiniger 14 VMs aktiv. D.h. wir machen ggf doch ein WireGuard-IP Raum je Server 10.12.50, .51, etc.
• Proxmox Standard-Installation mit Ausnahme, dieser Zugriffsbeschränkung, vgl auch: Intern:VirtualServerTest01

zu sichernde Daten:

• einige Konfigurationsdateien, die im Proxmox vom Standard abweichen.
• WireGuard Konfiguration
• Proxmox interner Backup von 1-2 Versionen jeder virtuellen Maschine, auf der anderen Platte, also nicht da, wo die VM ihre Platten hat. Weniger Platz daher nur eine und nicht 5, wie bisher.
• automatisches kopieren der Sicherung auf den 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
• 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.
• Die extra Sicherung von Inhalten der VMs ist bei der jeweiligen VM beschrieben.

• stellt BackupSpace im größeres Ausmass zur Verfügung, mit 100GB je Server werden wir nicht auskommen, die 5-fach Sicherung unserer VM auf pve06, belegt bereits 1,5TB
• Variante A, ein strunzdummer File-Server auf den wir was kopieren, und jeder der was drauf kopiert muss auch selbst für Rotation, Versionsverwaltung, Platz sorgen.
  • Problem dabei, jede einzelne Implementation die was auf den Server kopiert kann falsch sein.
• Variante B, wir schieben Daten über ein Eingangsverzeichnis (je Anwendung) auf den Server, der Server sorgt dann selbst für die Begrenzung der Anzahl und das weiter kopieren, der Dateien
  • Problem, wenn die Kopie auf den Backup-Server klemmt, dann wird auch nicht an die anderen redundanten Stellen verteilt, somit ist das keine Sicherheit beim Ausfall des Backup-Servers
• Variante C, jedes Ziel prüft selbst was es aufhebt, wir setzen die gleiche Software dann an mehreren Stellen ein, die Kopien kommen aber alle von der Quelle
• Schön wäre eine zentrale Verwaltung oder zu mindestens Protokoll, an dem wir sehen, welche Dateien gesichert, bzw. nicht gesichert worden sind.

• Kopieren der Daten mit rsync über ssh und damit mit Benutzer Authentifizierung ohne das shared Verzeichnisse offen liegen, zum Zielpunkt
• Auf dem Zielpunkt läuft ein Server (python) dem wir ssl gesichert eine Nachricht schicken mit dem was wir gesichert haben und ein hash
• diese Meldung geht auch an eine zentrale Backup Verwaltung (auf M03?, der hat wenig zu tun, damit es unabhängig vom BackUp-Server ist)
• wenn der Backup Server die Datei geprüft, verschoben, gelöscht hat, meldet er dies der zentralen Verwaltung
• Damit laufen von allen Kopien die Infos an der zentralen Verwaltung zusammen und man kann auf Fehler und fehlende prüfen.
• Die Software würde damit auf jedem Gerät zum Einsatz kommen, welches Geräte übergreifendes Ziel von Backup Dateien ist.
• Eine open-Source Lösung, die in diese Richtung geht, sehe ich nicht, mal Mastodon gefragt.

• • apmanituRXL06 pve08 - Proxmox pve08 Manitu
    • Ersatz für pve06
  • Strato / Hetzner**
    • externer Backup-Server, idealerweise mit einem Proxmox drauf, auf den man schnell umschalten kann, wenn beim Manitu was passiert.
    • Die Frage ist, ob als Backup, also alle Dateien da, oder alle Dateien so da und aktivierbar, dann man dann gleich wieder online ist
    • zweites hieße eine zusätzliche Virtualisierung von Frontend und VPN-Server, damit wir alles wieder schnell aktivieren können.

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

• NAS
  • paris
  • stockholm
  • videowuerfel
  • (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.