.

.

Ein wirklich guter Tip von einem unserer Leser - probieren Sie es aus ...... (der Archiv-Stand ist vom Feb. 2023) :
.
(1) https://web.archive.org/web/20230608224350/http://www.hifimuseum.de/   ...... und
(2) https://web.archive.org/web/20230608231016/http://www.fernsehmuseum.info/ ... und
(3) https://web.archive.org/web/20230608225138/http://www.magnetbandmuseum.info/ ...... und
(4) https://web.archive.org/web/20230609201746/http://software.ipw.net/

Unsere Museen-Seiten aus diesem amerikanischen Archiv kommen nicht so berauschend schnell - (wie ehemals von unserem alten Web-Server) - sie werden offensichtlich erst beim Aufruf (aus dem Archiv) entpackt. Sogar die Bilder lassen sich vergrößern !!! Jedoch sind manche unserer xxx.ipw.net "Sub"- (Wissen) Seiten in diesem Archiv leider nicht enthalten.

I am sorry, to tell you, our servers are down by a configuration fault. The upgrades from opensuse "rev 15.3" to the next "rev 15.4 and to rev 15.5" did fail and I did a mistake too. Only one DOM-0 host-server did survive with one secondary name sever. We are working on that problem hardly. Please be patient.

.

Die beiden Server im Data-Center in Düsseldorf haben 8 und 12 Kern CPUs mit je 32 GB RAM, also viel Leistung und laufen unter opensuse XEN - bei uns mit 6 oder mehr virtuellen "Gast-Servern", sogenannten "Virtuellen Maschinen". Startet dieser "Host" (Gastgeber) nicht mehr - das ist die Basis - die DOM-0 dieses Servers -, wird auch kein virtueller Gast mehr gestartet. Und nichts geht mehr. Das wars dann. Jetzt gehts ans Reparieren.

Die Komplexität des laufenden Systems verbirgt sich in den hunderten von Abhängigkeiten der einzelnen Softwarebereiche, die in solch einer "Virtuellen Maschine" (einer VM) kreuz und quer miteinander zusammenhängen.

Wir haben da das Basis-System, - auch "DOM-0" genannt (die unterste Hirarchie - es ist die Domäne-0) - das die Server-Hardware überhaupt startet. Das lief bei uns unter opensuse rev. 15.3 und sollte unbedingt auf rev. 15.5 "hochgefahren" werden, aus Sicherheitsgründen. Und von da an nahm das Unheil seinen Lauf.

Dieses Virtualisierungs-System kennt 2 Virtualisierungs-Varianten, XEN und KVM. Angeblich sind die fast funktionsgleich und nahezu gleich performant, aber das täuscht. Mit dem Virtualisierungs- Manager kann man jetzt einzelne virtuelle Gäste - das sind eigenständige aber virtuelle "Server" - auf diesem Basis-System erzeugen, und das mit beliebigen alten und neuen Betriebsystemen, (aber leider nicht immer).

Auf solch einer "VM", einem (von 6 oder 10 oder noch mehr) virtuellen Server(n) laufen dann die sogenannten Anwendungsprogramme, bei uns der Apache2 Webserver mit einem "CMS" im Hintergrund. Unser "CMS" (das "Content Management System" typo3) basiert auf PHP Programm-Moduln und auf der mysql / mariadb Datenbank. Und zu diesen ineinander greifenden Konstellationen gehören zu jedem Modul jede Menge an sogenannten Libraries, ähnlich den DLLs bei Windows.

Weiterhin haben wir eine "Suchmaschine" mit Namen "mnogosearch" am Laufen, die auch nur mit bestimmten PHP-Versionen von opensuse harmoniert. Diese mnogosearch Engine ist ganz extrem performant und komfortabel und hilft bei den über 45.000 Museen-Seiten erheblich, Suchworte schnell zu finden und die Ergebnisse / Fundstellen übesichtlich darzustellen.

Und das alles war über 14 Jahre ausgereift und lief bis zum 16.7.2023. Und das muß jetzt nochmal neu aufgesetzt werden, weil die vorhandenen Backups korrupted (nicht mehr lesbar) waren. Diverse Restore-Versuche sind schief gelaufen und haben bislang jede Menge Zeit gekostet.

Es kann dauern. Auf den aktuellen von einer der beiden Platten zurückgeholten Dateien - es sind 2.111.678 - (files found, 2,1 millions !!!)) fehlen nach dem "Recover" viel zu oft die Dateinamen. Damit sind die sicherlich geretteten Dateien praktisch nutzlos.

Im Moment wird deshalb auf dem 2. Server ein opensuse rev. 15.5. XEN-Server neu aufgesetzt, eine erste VM neu angelegt und darin eine ältere opensuse Version installiert und dann werden die ganzen CMS-Module hinterher nachinstalliert.

Von Vorteil war (zum Glück) auf jeden Fall, daß entgegen aller Linux Guru-Empfehlungen die gesamte mysql Datenbank und das gesamte typo3 CMS auf eine völlig separate dritte Partition - also nicht (1)=boot, oder (2)=root - sondern (3)="data" ausgelagert war und deshalb komplett original und völlig intakt überlebt hatte.

kann ich ganze Bücher (Wälzer) darüber schreiben, was im Linux- und CMS-Bereich alles nicht funktioniert und wie sehr sich die weltweiten Programmierer aus dem Fenster lehnen (also nicht nur bei Microsoft - denen die Chinesen den zentralen Key der Keys für die gesamte Microsoft Cloud über zwei Wochen unerkannt geklaut hatten) und die inzwischen fast alle mit der Komplexität der Technik ziemlich überfordert sind und auch, wie man sich "tot-googlen" kann.

.

.