Kriesensituation Recovery DB

Hallo zusammen,

nach einer Demo der Krisensituation bin ich auf ein Par Stolpersteine gestoßen!
Sauber Dokumentation ist das A und O, nun meine Rekonstruktion ergibt folgendes!

1. Installation der Software nach CAO-Update -> fehler vcruntime140.dll Fehlt!, NACH- INSTALLIEREN dann ist wieder alles gut.
2. Backup DB Restore -> OK ohne fehler
3. Mandant einloggen -> fehler

Welche Richtige Vorgehensweise hätten wir bei einer Krisensituation?

CAO-Admin 1.5.0.34
CAO-Faktura 1.5.0.43

Datenbank das Gleiche wie Früher
Hier wird das Krisen Szenario Demonstriert, das aber Funktionieren Sollte!
Ich mag keine Halbe Lösungen, die sind meistens Unprofessionell!
Danke im vorraus

Hallo,

zwischen Windows und Linux Server gewechselt?

Windows interessiert sich nicht für Groß- und Kleinschreibung einer Tabelle (Jedenfalls nicht mit den Standardeinstellungen)
Linux hingegen interessiert sich sehr wohl dafür.

Wenn die Datensicherung z.B die Tabelle artikel enthält und das ganze auf einen Linux Server Rückgesichert wird, meckert CAO wegen der Fehlenden Tabelle ARTIKEL.

Korrekt,
das ist ein sehr wichtiger Punkt, bei Systemabsturz wird in kürzester Zeit weiterarbeiten benötigt. Und genau da muss Mann aufpassen.

Für die die es nicht so genau möchten:
- Von Linux Backup -> Recovery unter Linux(mit der gleichen Mysql Version natürlich.)
- Von Linux auf Windows Schnell zum Laufen zu bringen kann nur mit einem Backup aus CAO-Faktura bzw. CAO-Admin

Na und?
Die Lösung Lautet:
https://www.cao-faktura.de/shop/CAO-Fak ... ackup.html

Egal was immer auch Passiert, ist die Widerherstellung schnell getätigt.

Um auf die eigentliche Frage zu kommen

Welche Richtige Vorgehensweise hätten wir bei einer Krisensituation?

In 99% der Fälle wird in einer Krise nicht zwischen Windows und Linux gewechselt.

Da spielt man auf einer neuen/anderen Maschine das System-Backup wieder ein und sichert die letzte CAO Sicherung zurück.
Man hat kein System-Backup oder die letze CAO Sicherung ist 2 Wochen alt "Kein Backup, kein Mitleid"

Es gibt auch noch "lower_case_table_names" für MySQL/MariaDB. Linux ist Standardmässig 0, Windows 1 und Mac 2
0 = Die Tabellen werden so angelegt, wie Sie im CREATE TABLE angegeben werden. Im CAO Fall UPPERCASE
1 = Es wird alles in lowercase angelegt aber es ist egal ob Groß- oder Kleinschreibung
2 = Wie 0 aber MySQL konvertiert diese zu Kleinschreibung beim nachschlagen.

Klartext, von Linux zu Windows geht (egal welches Backup man benutzt)
Von Windows zu Linux nur mit CAO Backup (Egal ob Autobackup oder manuell)

du hast mich gerade Verwirrt!
Von Linux zu Windows bekam ich die Situation mit den fehler!
Backup aus CAO aus, und Daten Import ging ohne fehler, und voll Funktionsfähig.

Backup am Linux (in der bash mit mysqldump) führte zu fehler bei Datenrücksicherung unter Windows
die 99% werden vom Kunden nicht Vergütet, wenn der Linux stehen bleibt dann gibt es keinen 2-en. und da will ich vorgreifen für die Zukunft.

Backup am Linux (in der bash mit mysqldump) führte zu fehler bei Datenrücksicherung unter Windows

Rücksicherung unter Windows mit CAO oder auch mit mysql auf der Kommandozeile?
Welche Windows MySQL/MariaDB Version? Änderungen an der ini gemacht?

Eigentlich spielt es keine Rolle. Eine Datensicherung sollte eigentlich mit dem Programmeigenen Tools gemacht werden.

Ich habe schon mysqldump (linux) mit mysql (windows) Datensicherungen hin und her gespielt. Ein gutes gefühl hatte ich dabei allerdings nie.
Usere Datensicherung besteht aus wöchtentlichem OS Backup und 2x Täglich Datenbank. (mittels mysqldump unter Linux)
Gleichzeitig wird die Datenbank in einen Testmandanten zurückgesichert, so hat man immer was zum testen.