Hallo Zusammen,
ist es möglich ein backup im laufenden Betrieb zu machen, und hat jemand Erfahrung damit bzw. ist es möglich OTRS live zu spiegeln, als eine Art
"Raid", für den Fall dass wenn der OTRS Server ausfällt man immer noch ein funktionierendes System hat?
Wie löst Ihr diese Fälle?
Bakup im laufenden Betrieb
-
- Moderator
- Posts: 393
- Joined: 30 Jan 2008, 02:26
- Znuny Version: All of them ^^
- Real Name: Hannes
- Company: Znuny|OTTERHUB
Re: Bakup im laufenden Betrieb
Hi,
also mein "einfacher" Vorschlag ist hier:
- Datenbank als Cluster aufsetzen. Also als Master Slave im einfachsten Fall.
- Attachments in einem separaten Laufwerk als Mount einbinden (ext4 Share oder vergleichbar)
- Znuny Verzeichnis via rsync (ohne Temp Verzeichnis var/tmp) einmal pro Tag updaten.
Alle Relevante Daten liegen in der DB und im Attachment Mount. Das Znuny Verzeichnis braucht es für Config.pm und Pakete und Co. Das geht zwar auch alles ohne einen frischen Stand, so ist man aber relativ nah an der Realität und kann schnell schwenken.
Das geht alles viel komplexer und mit Sicherheit auch besser. Das ist aber die "einfachste" Methode und sie ist von den Daten her konsistent.
Nur der Fall das jemand die DB "droppt" wird damit nicht gut abgefangen, da alles vom Master auch auf die Slaves projiziert wird.
Gruß
also mein "einfacher" Vorschlag ist hier:
- Datenbank als Cluster aufsetzen. Also als Master Slave im einfachsten Fall.
- Attachments in einem separaten Laufwerk als Mount einbinden (ext4 Share oder vergleichbar)
- Znuny Verzeichnis via rsync (ohne Temp Verzeichnis var/tmp) einmal pro Tag updaten.
Alle Relevante Daten liegen in der DB und im Attachment Mount. Das Znuny Verzeichnis braucht es für Config.pm und Pakete und Co. Das geht zwar auch alles ohne einen frischen Stand, so ist man aber relativ nah an der Realität und kann schnell schwenken.
Das geht alles viel komplexer und mit Sicherheit auch besser. Das ist aber die "einfachste" Methode und sie ist von den Daten her konsistent.
Nur der Fall das jemand die DB "droppt" wird damit nicht gut abgefangen, da alles vom Master auch auf die Slaves projiziert wird.
Gruß
-
- Znuny wizard
- Posts: 470
- Joined: 20 Nov 2011, 16:08
- Znuny Version: 6.5.4
- Real Name: Schulmann
Re: Bakup im laufenden Betrieb
Man kann Znuny in einer virtuellen Maschine betreiben und die Clusterfunktionen der Virtualisierungslösung nutzen.
Gegen logische Fehler hilft das aber nicht.
Alternativ kann man - auch in einer virtualisierten Umgebung - so vorgehen:
Die DB läuft auf der gleichen Maschine wie die Znuny-Software.
Die Verbindung zur DB erfolgt entweder zu localhost oder mit Hilfe von IPC.
Die Attachments lässt man in der DB (muss nicht sein, erleichtert aber das Handling).
Man erstellt mit Hilfe der Virtualisierungslösung einen Klon.
Man kopiert automatisiert in kurzen Zeitabständen (z. B. alle 10 Minuten) die Archive-Logs, WAL-Files, ... auf den Klon.
Auf dem Klon werden die DB-Änderungen einmal täglich automatisch eingespielt.
Falls es ein Problem mit der produktiven Maschine gibt kann der Klon mit Point-in-Time-Recovery manuell nachgeführt und als produktive Maschine aktiviert werden.
Vorteile:
- Keine weitere Software nötig
- Point-in-Time-Recovery möglich
- Test-Instanz mit einem beliebigen zeitlichen Stand machbar
- Mit der Methode können beliebig viele Testmaschinen aufgebaut werden.
- Klare Trennung zwischen Produktion und Test: Kein Risiko für die produktive DB bei Tests
- Es muss eingerichtet und dokumentiert werden.
- Man muss aufpassen, dass der Klon keine Mails abruft und keine Mails verschickt.
- Die Inbetriebnahme der Absicherung erfolgt nicht automatisch.
- Die Inbetriebnahme der Absicherung erfordert mehrere manuelle Schritte.
- Keine zentralisierte DB möglich
Znuny6/Debian/ESXi