Validate backups before restore
This commit is contained in:
@@ -55,9 +55,9 @@ Admin-Zugangsdaten werden nicht per `.env` gesetzt. Nach dem ersten Start oeffne
|
||||
Dort gibt es zwei Wege:
|
||||
|
||||
- `Admin anlegen`: festen Admin direkt erstellen und anmelden.
|
||||
- `Backup einspielen`: ein TicketTracker-SQL-Backup einspielen. Danach meldest du dich mit einem Benutzer aus dem Backup an.
|
||||
- `Backup einspielen`: ein TicketTracker-SQL-Backup hochladen, Struktur pruefen und danach einspielen. Danach meldest du dich mit einem Benutzer aus dem Backup an.
|
||||
|
||||
Ein Restore ersetzt den kompletten Systemstand. Vor dem Einspielen werden alle TicketTracker-Tabellen geleert; danach gelten ausschliesslich Benutzer, Passwoerter, Sessions, Settings, Organisationen, fixe Abrechnungen und Abschluesse aus dem Backup.
|
||||
Ein Restore ersetzt den kompletten Systemstand. Vor dem Einspielen wird geprueft, ob Dump-Struktur und aktuelle Datenbankstruktur zusammenpassen. Danach werden alle TicketTracker-Tabellen geleert; anschliessend gelten ausschliesslich Benutzer, Passwoerter, Sessions, Settings, Organisationen, fixe Abrechnungen und Abschluesse aus dem Backup.
|
||||
|
||||
## Image bauen und in Gitea pushen
|
||||
|
||||
|
||||
+3
-3
@@ -9,9 +9,9 @@ Wenn noch kein Admin existiert, zeigt TicketTracker beim Aufruf automatisch die
|
||||
Dort gibt es zwei Moeglichkeiten:
|
||||
|
||||
- `Admin anlegen`: festen Admin mit Benutzername, vollem Namen und Passwort erstellen. Danach ist der Admin direkt angemeldet.
|
||||
- `Backup einspielen`: ein TicketTracker-SQL-Backup aus einem frueheren Systemstand einspielen. Danach meldet man sich mit einem Benutzer aus dem Backup an.
|
||||
- `Backup einspielen`: ein TicketTracker-SQL-Backup aus einem frueheren Systemstand hochladen, Struktur pruefen und danach einspielen. Danach meldet man sich mit einem Benutzer aus dem Backup an.
|
||||
|
||||
Ein Restore ersetzt den kompletten Systemstand. Vor dem Einspielen werden alle TicketTracker-Tabellen geleert. Danach gilt ausschliesslich der Stand des Backups, inklusive aller Benutzer, Passwoerter, Sessions, Einstellungen, Organisationen, fixen Abrechnungen und Abschluesse.
|
||||
Ein Restore ersetzt den kompletten Systemstand. Vor dem Einspielen wird geprueft, ob die Struktur des Dumps zur aktuellen Datenbank passt. Fehlen Felder oder enthaelt der Dump unbekannte Felder, wird eine Fehlermeldung angezeigt und der Restore kann nicht gestartet werden. Beim eigentlichen Restore werden alle TicketTracker-Tabellen geleert. Danach gilt ausschliesslich der Stand des Backups, inklusive aller Benutzer, Passwoerter, Sessions, Einstellungen, Organisationen, fixen Abrechnungen und Abschluesse.
|
||||
|
||||
## Grundprinzip
|
||||
|
||||
@@ -443,7 +443,7 @@ Der Datenbankexport im Adminbereich erzeugt eine SQL-Datei fuer einen kompletten
|
||||
|
||||
Der Export enthaelt alle Tabellen, die fuer den Stand des Systems notwendig sind: Benutzer, Einstellungen, Organisationen, Tickets, Sessions, Teamspace-Werte, fixe Abrechnungen, Ausnahmen und Monatsabschluesse. Er ist kein reiner CSV-Auszug, sondern ein Restore-Backup.
|
||||
|
||||
Im laufenden System kann der Admin ein SQL-Backup ebenfalls im Adminbereich wieder einspielen. Vor dem Restore erscheint ein Hinweis, weil alle aktuellen Daten ersetzt werden. Nach dem Restore ist eine neue Anmeldung mit den Zugangsdaten aus dem Backup notwendig.
|
||||
Im laufenden System kann der Admin ein SQL-Backup ebenfalls im Adminbereich wieder einspielen. Nach dem Hochladen muss zuerst die Strukturpruefung erfolgreich durchlaufen. Erst danach wird der Restore-Button freigegeben. Vor dem Restore erscheint ein Hinweis, weil alle aktuellen Daten ersetzt werden. Nach dem Restore ist eine neue Anmeldung mit den Zugangsdaten aus dem Backup notwendig.
|
||||
|
||||
## Zammad Sync
|
||||
|
||||
|
||||
Reference in New Issue
Block a user