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

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.

• • apmanituRXL04 - Proxmox pve07 Manitu
    • Ersatz für pve05, den abgebrannten Entwicklungsserver
  • apmanituRXL05 - BackupServer Manitu
    • stellt BackupSpace im größeres Ausmass zur Verfügung
  • 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.