Bakup im laufenden Betrieb

Allgemein Fragen, deutsche News, Ankündigungen & Events zum OTRS
Post Reply
BlackCat
Znuny newbie
Posts: 9
Joined: 24 Jul 2019, 13:26
Znuny Version: 6.0.23
Real Name: Johannes Nagel

Bakup im laufenden Betrieb

Post by BlackCat »

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?
Johannes
Moderator
Posts: 391
Joined: 30 Jan 2008, 02:26
Znuny Version: All of them ^^
Real Name: Hannes
Company: Znuny|OTTERHUB

Re: Bakup im laufenden Betrieb

Post by Johannes »

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ß
schulmann
Znuny wizard
Posts: 470
Joined: 20 Nov 2011, 16:08
Znuny Version: 6.5.4
Real Name: Schulmann

Re: Bakup im laufenden Betrieb

Post by schulmann »

BlackCat wrote: 16 Mar 2022, 10:02
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?
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
Nachteile:
  • 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
CD
Znuny6/Debian/ESXi
Post Reply