Datenkonsistenz FirstSpirit

Benutzersicht

Der FirstSpirit-Redakteur bedient FirstSpirit über den ContentCreator (Webclient bis 5.0) oder SiteArchitect (JavaClient bis 5.0). Nach Übernahme seiner Änderungen durch Beenden des Bearbeitungsmodus, beispielsweise nach Eingabe eines Textabsatzes oder Hochladen eines Bildes, erhält er eine Statusrückmeldung im Client, ob die eingegebenen Daten vom FirstSpirit-Server übernommen wurden. Die Rückmeldung erfolgt dabei spätestens nach 90s, dem Timeout des FirstSpirit-Netzprotokolls, das statisch in der Implementierung eingetragen ist. Die Rückmeldung zeigt an, dass die Daten am FirstSpirit-Server erhalten wurden. Im Normalbetrieb werden diese erfolgreich empfangenen Daten persistent gespeichert. In Sonderfällen, z.B. wenn der FirstSpirit-Server-Prozess durch externes Senden des Signals SIGKILL beendet wird, also nicht kontrolliert heruntergefahren wird, kann es geschehen, dass diese Daten nicht persistent gespeichert werden. Es kann dann aber trotzdem festgestellt werden, welche Daten persistent vorliegen.

Anzeige aller Änderungen

Um nach unkontrolliertem Beenden des FirstSpirit-Servers festzustellen, welche Benutzereingaben tatsächlich persistent gespeichert wurden, kann ein Redakteur zunächst die Funktion "Änderungsverlauf" auf einem beliebigen FirstSpirit-Objekte (Seite, Absatz, Medienobjekt) im Client aufrufen, um zu sehen, wann und durch wen die letzte Änderung dieses Objektes erfolgte. Diese Änderung ist dann persistent vorhanden.

Wenn unbekannt ist, welche FirstSpirit-Objekte geändert wurden, also vom System als geändert persistent vorliegen, kann über die FirstSpirit Access-API eine Liste aller seit einem bestimmten Datum geänderten Objekte erstellt werden. Diese Möglichkeit nutzt e-Spirit beispielsweise selbst in der eigenen Intranet-Website, um eine schnelle Übersicht der Neuigkeiten bekanntzumachen.  Die API-Benutzung wurde hierzu als FirstSpirit-Modul implementiert, um sie in verschiedenen Projekten einzusetzen. Das Modul ist zwar ein nur internes verwendetes, nutzt aber öffentlich verfügbare API-Funktionen. Bei Bedarf kann eventuell der Quelltext des Moduls bei e-Spirit angefordert werden. Name des Moduls: Intranet_LastChanges.fsm

Systemarchitektur

Bezüglich der Datenkonsistenz im FirstSpirit-System ist die Komponente FirstSpirit-Server die im wesentlichen relevante. Weitere FirstSpirit-Komponenten wie die WebApps fs5root (Startseite, JavaClient-Proxy), fs5webedit (Webclient) sowie die Java-basierten Clients speichern keine persistenten Daten und die genannten Komponenten arbeiten aus Benutzersicht alle nahezu synchron mit dem FirstSpirit-Server bezüglich Datenübernahme vom Benutzer. Die genannten Komponenten speichern temporäre Daten während der Datenübernahme zum Server maximal 90s, was dem Verbindungs-Timeout des FirstSpirit-Protokolls entspricht. Wenn der Benutzer beispielsweise im Webclient oder JavaClient ein Texteingabefeld ausfüllt und auf "Speichern" klickt, erhält er eine Rückmeldung sobald der FirstSpirit-Server die Daten erfolgreich entgegengenommen hat, bzw. erhält alternativ spätestens nach dem Verbindungs-Timeout von 90s eine Fehlermeldung, dass die Übernahme fehlgeschlagen ist.

Zur persistenten Datenhaltung auf Seite des FirstSpirit-Servers werden 3 Komponenten eingesetzt: Berkeley-DB, RDBMS, Konfigurationsdateien, generierte Web-Dateien. Die Datenkonsistenz jeder dieser Komponenten wird nachfolgend beschrieben.

Abbildung 1: Interne Systemarchitektur FirstSpirit-Server, Persistenzschicht

Berkeley-DB

FirstSpirit verwendet Oracle Berkeley DB Java Edition in der lizensierten Version zur persistenten Sicherung der FirstSpirit Projektdaten sowie einiger Server-zentraler Daten. Für jedes FirstSpirit-Projekt wird eine eigene Berkeley-Datenbank (Environment) in einem eigenen Dateisystemordner erstellt.

Alle 5 Minuten erfolgt die Erstellung eines Berkeley-Checkpoints, sodass alle intern an die Berkeley-Implementierung zur persistenten Sicherung übergebenen Daten nach spätestens 5 Minuten persistent im Dateisystem vorliegen. Diese Zeitspanne ist aktuell statisch im FirstSpirit-Quelltext kodiert.

RDBMS

FirstSpirit nutzt JDBC als Protokoll zur Anbindung externer relationale Database-Managementsysteme. Außerdem wird das transaktionsorientierte Arbeiten der JDBC-API verwendet, so dass der FirstSpirit-Server bei einer ändernden Datenbankoperation synchron wartet, bis der Datenbankserver diese Änderung als persistent gesichert zurückmeldet. Sofern der Datenbankserver die JDBC-API bezüglich Transaktionen korrekt implementiert, ist die Datenkonsistenz der relationalen Daten in FirstSpirit, dort Datenquellen, bzw. Content Store genannt, sichergestellt.

Weil bei Verwendung eines RDBMS in FirstSpirit immer auch gleichzeitig die Berkeley-DB verwendet wird, weil nicht alle FirstSpirit-Objekte, z.B. Templates, ins RDBMS ausgelagert werden können, ist die Datenkonsistenz zwischen den Objekten im RDBMS und der Berkeley-DB ebenfalls zu beachten. Für FirstSpirit ist es aber unkritisch, wenn im Falle eines Neustart nach einem Systemausfall das RDBMS Daten enthält, die zeitlich nach den letzten verfügbaren Daten in der Berkeley-DB geschrieben wurden, denn FirstSpirit schreibt alle Daten ins RDBMS revisionsbasiert und löscht dabei keine alten Revisionen. Daten von Revisionen im RDBMS, die nicht von der Berkeley-DB referenziert werden, werden normal genutzt.

Konfigurationsdateien

Konfigurationsdateien, beispielsweise zentrale Server-Konfiguration wie fs-server.conf, oder Modul-spezifische Konfigurationen werden als einzelne XML- oder Textdateien im Dateisystem des FirstSpirit-Servers abgelegt. Das persistente Speichern einer Datei nach Änderung innerhalb des FirstSpirit-Servers erfolgt spätestens nach der durch den Parameter cyclicSaveTime (fs-server.conf) in Sekunden definierten Zeitspanne. Vordefiniert sind hier 60 Sekunden.

Generierte Web-Dateien

Von FirstSpirit über Generierungs- und Deployment-Aufträge generierte HTML, JSP oder vergleichbare Web-Dateien können zu jedem beliebigen Zeitpunkt in den Inhaltsstand einer beliebigen Revision des zugehörigen FirstSpirit-Objekts zurückversetzt bzw. neu erstellt werden. Sofern die zugehörigen FirstSpirit-Objekte also persistent vorliegen, siehe vorherige Absätze, kann der Zustand einer Website bei Verlust einiger oder aller dort abgelegten von FirstSpirit generierten Dateien problemlos wiederhergestellt werden. Es genügt dazu, den Startzeitpunkt des jeweiligen Generierungsauftrag über ein vorgelagertes Skript einen Startzeitpunkt in der Vergangenheit zu übergeben.

Datensicherung und Wiederherstellung FirstSpirit

Bei Einsatz von FirstSpirit im Unternehmensumfeld bieten sich diverse Verfahren zur Datensicherung und Wiederherstellung zur Absicherung gegen Systemausfälle an. Systemausfälle können durch diverse Ereignisse ausgelöst werden und zeichnen sich gerade dadurch aus, dass sie meistens durch vorher gar nicht in Betracht gezogene Auslöser entstehen. Mögliche Ursachen für Ausfälle sind: Fehlbedienung durch Benutzer, Probleme in der System-Hardware, Fehler in Software-Komponenten, Ausfälle in der Netz- und System-Infrastruktur, hohe Auslastung von Systemressourcen.

Bei der Auswahl des zu verwendeten Verfahrens zur Datensicherung und Wiederherstellung sind einige wesentliche Aspekte zu beachten:

• maximal erlaubter Datenverlust bezüglich der letzten Änderungszeit
• Systemressourcenbelastung durch Datensicherung: CPU, Storage-I/O, Network-I/O, Datenmenge
• Systemressourcenbelastung bei Wiederherstellung: Network-I/O, Storage-I/O
• benötigtes Fachwissen oder Personal zur Wiederherstellung
• benötigte Zeit zur Wiederherstellung des betriebsfähigen Systemzustands

Die folgenden Verfahren zur Datensicherung und Wiederherstellung werden in der Praxis für FirstSpirit-Systeme bei Kunden eingesetzt und haben jeweils Vor- und Nachteile bezüglich oben genannter Aspekte, die immer im jeweiligen Projektumfeld individuell bewertet werden müssen:

Projektexport

Manuell durch Benutzer in der Rolle eines Projektadministrator oder zeitgesteuert über einen Auftrag innerhalb des Projektes selbst, kann eine Exportdatei eines FirstSpirit-Projekts erstellt werden, die alle Projektdaten enthält, u.a. auch Benutzerdaten, RDBMS-Inhalte, Modulkonfigurationen, Auftragsdefinitionen, Konfigurationen von Live-WebApps. Nach den Import dieser einen Projektexportdatei in der Rolle des FirstSpirit-Server-Administrators in einen anderen FirstSpirit-Server oder auch denselben FirstSpirit-Server auf dem sie erstellt wurde, auch parallel zum vorhandenen Originalprojekt, kann die Arbeit an dem Projekt fortgesetzt werden. Das Erstellen der Exportdatei erfolgt intern snapshot-basiert bezüglich der Objektrevisionen und kann problemlos während des Redaktionsbetriebs stattfinden.+ Sicherung und Wiederherstellung durch jeden FirstSpirit-Server-Administrator zeitgesteuert oder manuell möglich+ Wiederherstellung eines einzelnen Projektes auf beliebigen anderen oder denselben FirstSpirit-Server als Kopie möglich+ problemlose Sicherung während des Redaktionsbetriebs+ Import in andere FirstSpirit-Server möglich+ Import in beliebige andere von FirstSpirit unterstützte RDMS möglich+ 100% datenkonsistent+ kein Verlust an letzten Redakteurstexteingaben- nur für eigenständige FirstSpirit-Projekte geeignet, d.h. ohne Verknüpfungen zu anderen Projekten (Templates-Abos, Content-Transfer, Packagepool, ausgenommen Remote-Media)- nur Vollsicherung aller Projektdaten bei jedem Vorgang möglich, falls Revisionsverlauf gesichert werden muss (Standardfall), keine inkrementelle oder differentielle Sicherung- Verlust der Verknüpfung zu den archivierten Revisionen

Offline-Backup

Hierzu wird der FirstSpirit-Server heruntergefahren, ein dateibasiertes Backup durch Standard-Backupsoftware erstellt sowie das externe RDBMS gesichert und der FirstSpirit-Server wieder gestartet. Weil üblicherweise inkrementelle oder differentielle Sicherungsverfahren eingesetzt werden, beträgt die benötigte Zeitspanne selbst bei Sicherung ohne Verwendung eines Dateisystem-Snapshots, häufig nur wenige Minuten.Die Datenkonsistenz zwischen RDBMS und Berkeley-DB ist gewährleistet, weil bei abgeschaltetem FirstSpirit-Server keine Schreiboperationen im RDBMS erfolgen.+ 100% datenkonsistent+ kein Verlust an letzten Redakteurstexteingaben+ Sicherung und Wiederherstellung ohne Kenntnisse von FirstSpirit möglich+ Zeitdauer zur Wiederherstellung durch Einsatz von Standard-Backupsoftware ist bekannt- nicht während des Redaktionsbetriebs möglich- nicht bei vielen zeitgesteuerten Aufträgen möglich, denn abgebrochene Aufträge werden nicht wiederholt und während des Zeitintervalls der Sicherung zeitlich eingeplante Aufträge werden nie gestartet- nur Wiederherstellung des gesamten FirstSpirit-Server direkt möglich, Wiederherstellung einzelner Projekte aufwändig

Dateibasierte Sicherung während der Redaktionsarbeitszeit

Sofern ohne weitere Vorbereitung während des Redaktionsbetriebs eine dateisystembasierte Sicherung durch Standard-Backupsoftware erfolgt, ist die Datenkonsistenz in der Berkeley-DB nicht gewährleistet und ein Betrieb nach Wiederherstellung aus der Datensicherung ist nicht sichergestellt, weil die Berkeley-DB im Datenbestand des Backup-Systems irreparabel beschädigt sein kann. Eine manuelle Reparatur der Berkeley-DB durch e-Spirit-Mitarbeiter ist zwar in vielen Fällen möglich, aber zeitaufwendig.- nicht datenkonsistent- Verlust an letzten Redakteurstexteingaben von mehreren Minuten bis Stunden (Dauer der Datensicherung)- Wiederaufnahme des Betriebs nach Wiederherstellung ist nicht garantiert- nur Wiederherstellung des gesamten FirstSpirit-Server direkt möglich, Wiederherstellung einzelner Projekte aufwändig

Dateibasierte Sicherung außerhalb der Redaktionsarbeitszeit

Die Hinweise in diesem Abschnitt gelten nur, falls außerhalb der Redaktionsarbeitszeit keine automatisiert durchgeführten Änderungen am FirstSpirit-Datenbestand über die FirstSpirit-API erfolgen. Falls doch Änderungen erfolgen, z.B. über tägliche automatisierte Importaufträge, gelten die im vorherigen Kapitel (Dateibasierte Sicherung während der Redaktionsarbeitszeit) genannten Hinweise.Sofern ohne weitere Vorbereitung außerhalb des Redaktionsbetriebs, beispielsweise nachts, eine dateisystembasierte Sicherung durch Standard-Backupsoftware erfolgt, sowie gleichzeitig oder kurz nachfolgende eine Sicherung der RDBMS, ist die Datenkonsistenz in der Berkeley-DB zwar theoretisch nicht gewährleistet und ein Betrieb nach Wiederherstellung aus der Datensicherung nicht 100% sichergestellt, weil die Berkeley-DB im Datenbestand des Backup-Systems irreparabel beschädigt sein kann, aber die Wahrscheinlichkeit dafür ist vernachlässigbar gering. Im Fehlerfall ist eine manuelle Reparatur der Berkeley-DB durch e-Spirit-Mitarbeiter in vielen Fällen möglich, aber zeitaufwendig.Die Datenkonsistenz zwischen RDBMS und Berkeley-DB ist gewährleistet, weil das RDBMS mindestens alle in der Berkeley-DB referenzierten Revisionen enthält.Der Fehlerzustand einer defekten Berkeley-DB kann nur auftreten, wenn gleichzeitig zur Sicherung Schreiboperationen auf der Berkeley-DB erfolgen, die aber nur ausgelöst werden durch Redakteurs-Aktionen oder durch API-Nutzung in zeitgesteuerten Aufträgen. Üblicherweise werden in zeitgesteuerten Generierungs- und Deploymentaufträgen nur lesende Operationen auf der Berkeley-DB durchgeführt. Schreibenden Operationen treten im Dateisystem nur bezüglich der Logdateien und erstellten HTML- oder sonstiger Web-Dateien auf, die bezüglich Verlust bei der Wiederherstellung unkritisch sind.Wichtig ist, das Backup-System so zu konfigurieren, dass auch geöffnete Dateien gesichert werden!+ 100% datenkonsistent zwischen RDBMS und Berkeley-DB+ Sicherung und Wiederherstellung ohne Kenntnisse von FirstSpirit möglich+ Zeitdauer zur Wiederherstellung durch Einsatz von Standard-Backupsoftware ist bekannt+ kein Verlust an letzten Redakteurstexteingaben (solange tatsächlich niemand zu der Zeit arbeitet)- nicht 100% garantiert datenkonsistent bezüglich Berkeley-DB- nicht während des Redaktionsbetriebs möglich, aber während des Betriebs von FirstSpirit-Generierungsaufträgen- nur Wiederherstellung des gesamten FirstSpirit-Server direkt möglich, Wiederherstellung einzelner Projekte aufwändig

Snapshot-basierte Sicherung

Diese Sicherung kann während der Redaktionsarbeitszeit erfolgen. Die verwendete Standard-Backupsoftware löst zunächst einen Dateisystem-Snapshot aus oder einen Snapshot der gesamten VM sofern es sich um ein virtuelles System handelt. Dann erfolgt zusätzlich die Sicherung des RDBMS, die dort systembedingt bei transaktional arbeitenden Systemen immer snapshot-basiert ist. Alle anderen nun folgenden Aktionen erfolgen asynchron zum FirstSpirit-Betrieb und sind zeitlich unkritisch. Der Dateisystemsnapshot wird im readonly-Modus als lesbares Dateisystem eingehangen und die Standard-Backupsoftware kopiert alle seit der letzten Sicherung geänderten Dateien und löscht anschließend den Dateisystem-Snapshot.Die Datenkonsistenz zwischen RDBMS und Berkeley-DB ist gewährleistet, weil das RDBMS mindestens alle in der Berkeley-DB referenzierten Revisionen enthält.Die Datenkonsistenz der Berkeley-DB ist ausreichend gewährleistet, nur die noch nicht ins Dateisystem geschriebenen Änderungen der Redakteure sind verloren, maximal die Arbeitszeit von 5 Minuten pro Redakteur, siehe Berkeley-DB. Technisch kann es vorkommen, dass beim Start des wiederhergestellten Systems ein automatischer Überprüfungsschritt der Berkeley gestartet wird, der je nach Größe der Berkeley-DB mehrere Minuten dauern kann. Dieser Schritt führt eine Konsistenzprüfung durch und entfernt die noch nicht vollständig geschrieben Änderungen der Datensätze, die zum Zeitpunkt der Snapshot-Erstellung erfolgten.Bei Einsatz von Snapshot-Dateisystemen gilt Folgendes zu beachten:Allgemeine Hinweise zu Dateisystem-Snapshots+ ausreichend datenkonsistent+ Sicherung während der Redaktionsarbeitszeit möglich+ Sicherung und Wiederherstellung ohne Kenntnisse von FirstSpirit möglich+ Zeitdauer zur Wiederherstellung durch Einsatz von Standard-Backupsoftware ist bekannt- möglicher Datenverlust der Änderungen der letzten 5 Minuten (siehe Berkeley-DB)- nur Wiederherstellung des gesamten FirstSpirit-Server direkt möglich, Wiederherstellung einzelner Projekte aufwändig

Snapshot-Sicherung mit Backup-Modus während Betrieb

Diese Sicherung kann während der Redaktionsarbeitszeit erfolgen. Die verwendete Standard-Backupsoftware löst zunächst einen Dateisystem-Snapshot aus oder einen Snapshot der gesamten VM sofern es sich um ein virtuelles System handelt. Direkt nachfolgend werden über die FirstSpirit-API mittels Aufruf der Funktion AdminService.serverBackupPrepare() alle Daten der Berkeley-Caches mit dem  Dateisystem synchronisiert und alle Schreiboperationen auf die Berkeley-Datenbank angehalten. Dann erfolgt zusätzlich die Sicherung des RDBMS, die dort systembedingt bei transaktional arbeitenden Systemen immer snapshot-basiert ist. Anschliessend erfolgt erneut ein Funktionsaufruf über die FirstSpirit-API, AdminService.serverBackupDone(), um den normalen Betrieb fortzusetzen. Alle anderen nun folgenden Aktionen erfolgen asynchron zum FirstSpirit-Betrieb und sind zeitlich unkritisch. Der Dateisystemsnapshot wird im readonly-Modus als lesbares Dateisystem eingehangen und die Standard-Backupsoftware kopiert alle seit der letzten Sicherung geänderten Dateien und löscht anschließend den Dateisystem-Snapshot.Die Datenkonsistenz zwischen RDBMS und Berkeley-DB ist gewährleistet, weil das RDBMS mindestens alle in der Berkeley-DB referenzierten Revisionen enthält.Die Datenkonsistenz der Berkeley-DB ist gewährleistet und es sind alle Änderungen der Redakteure in der Sicherung enthalten.Sofern in dem kurzen Zeitraum von wenigen Sekunden zwischen den Funktionsaufrufen AdminService.serverBackupPrepare() und AdminService.serverBackupDone() ein FirstSpirit-Client eine schreibende Server-Aktion anfordert, erhält der Benutzer erst eine Rückmeldung vom Client sobald der normale Betrieb fortgesetzt wird. Sofern die Zeitspanne zwischen beiden Funktionsaufrufen die maximale statisch kodierte Wartezeit des Clients von 90 Sekunden nicht überschreitet, ist ein störungsfreier Betrieb gewährleistet. Bei längerer Wartezeit erhält der Redakteur eine Fehlermeldung des Clients, dass die Verbindung zum Server getrennt wurdeEine Beispielimplementierung eines externen Java-Programms, das von einem pre- und post-Backupscript aufgerufen wird, ist auf Anfrage bei e-Spirit verfügbar.Bei Einsatz von Snapshot-Dateisystemen gilt Folgendes zu beachten:Allgemeine Hinweise zu Dateisystem-Snapshots+ 100% datenkonsistent+ kein Verlust an letzten Redakteurstexteingaben+ Sicherung während der Redaktionsarbeitszeit möglich+ Sicherung und Wiederherstellung ohne Kenntnisse von FirstSpirit möglich+ Zeitdauer zur Wiederherstellung durch Einsatz von Standard-Backupsoftware ist bekannt- zur Verwendung muss ein FirstSpirit Beanshell-Skript oder ein FirstSpirit-Modul oder ein externes Java-Programm mit Nutzung der FirstSpirit-API erstellt werden- nur Wiederherstellung des gesamten FirstSpirit-Server direkt möglich, Wiederherstellung einzelner Projekte aufwändig

Allgemeine Hinweise zu Dateisystem-Snapshots

Dateisysteme mit Snapshot-Funktion:

• ZFS (Standarddateisystem seit Solaris 11)
• UFS (Standarddateisystem Solaris 9 und 10)
• ext4, ext3, XFS (Linux, jeweils nur in Kombination mit LVM)
• JFS2 (AIX)
• NTFS (Windows, in Kombination mit Shadow-Volume)

Von BTRFS (Linux) wird abgeraten, weil es allgemein, unabhängig von FirstSpirit, als noch nicht stabil genug für den Produktiveinsatz angesehen wird (Stand Oktober 2015). Dateisysteme unter Linux über UserFS, wie ZFS teilweise dort betreiben wird, ist ebenfalls nicht stabil genug für den Produktiveinsatz.

Beim Einsatz von Dateisystem-Snapshots gilt allgemein, unabhängig von FirstSpirit, zu beachten, dass der Datenbereich zur Aufnahme der Änderungen im Dateisystem während eines aktiven Snapshots, ausreichend groß bemessen wird. Falls hier eine Fehlkonfiguration erfolgt, droht ein Auffüllen des aus Anwendungssicht verfügbaren Dateisystems, so dass die Anwendung möglicherweise nicht schnell genug reagieren kann, sich frühzeitig genug herunterzufahren, um Datenverlust zu vermeiden. Zusätzlich gilt zu beachten, dass das Entfernen eines Snapshots, was nach erfolgreicher Dateisicherung erfolgen sollte, zu einer I/O-Belastung und CPU-Belastung führt, weil das Snapshot-Dateisystem die während der Existenz des  Snapshots vorgenommenen Änderungen im Dateisystem mit dem Originaldateisystem konsolidieren muss. Aus Betriebssicherheitsgründen, sollte ein Snapshot aber so schnell wie möglich wieder entfernt werden, um das vorher genannte Auffüllen des Snapshot-Bereich zu vermeiden.

FirstSpirit Enterprise-Backup

Das von e-Spirit ausgelieferte optionale FirstSpirit-Modul Enterprise-Backup ermöglicht die Sicherung von FirstSpirit-Projekten oder gesamter FirstSpirit-Server während der Redakteursarbeitszeit. Es arbeitet je nach Konfiguration inkrementell oder differentiell zur letzten Vollsicherung, so dass die bei jeder Sicherung zu übertragende Datenmenge nur die tatsächlichen, durch die Redakteure durchgeführten, Änderungen umfasst.

Die Bedienung erfolgt vollständig über den FirstSpirit ServerManager Client ist daher eigenständig durch den Anwendungsbetrieb möglich.

Die Sicherung enthält alle Daten, die bereits in einem FirstSpirit Projektexport vorliegen, also auch RDBMS, ist aber im Vergleich zum Projektexport für den  Einsatz bei untereinander referenzierten Projekten (Package-Pool, Content-Transfer, Feature-Transport, Remote-Media, usw.) ausgelegt.

Zu weiteren Details siehe die zugehörige Modul-Dokumentation EBAC_DE_FirstSpirit_EnterpriseBackup.pdf .

+ eigenständig durch Anwendungs-Administrator nutzbar

+ problemlose Sicherung während des Redaktionsbetriebs

+ kein Verlust an letzten Redakteurstexteingaben

+ Sicherung während der Redaktionsarbeitszeit möglich

+ Wiederherstellung einzelner Projekte möglich (Einschränkungen laut Dokumentation beachten)

- wiederherstellbarer Revisionsverlauf beginnt erst mit erstmaligem Einsatz des Enterprise-Backup (Bei der ersten Sicherung des Projekts wird nur der aktuelle Revisionszustand aller Objekte gesichert, nicht deren vorherige Revisionen. Ein vollständiger Revisionsverlauf ist also nur im Backup enthalten, wenn direkt bei Projekterstellung das Enterprise-Backup bereits eingesetzt wurde.)

- Wiederherstellung des gesamten FirstSpirit-Systems erfordert detaillierte FirstSpirit-Kenntnisse, weil zunächst ein neuer (leerer) FirstSpirit-Server installiert werden muss, dorthinein dann das Enterprise-Backup-Modul installiert wird und anschließend mittels des FirstSpirit ServerManager Clients, die Wiederherstellung, interaktiv ausgelöst, aus den Backup-Dateien begonnen wird.