Übersicht über die Archivierung unter enaio

Allgemeine Übersicht über die Anbindung von OSECM (enaio blueline) an Archivsysteme
Stand : 07.02.2022 Autoren: Jürgen Maak und Frank Kazmierski 

Inhaltsvereichnis:

Allgemeine Informationen zur Verwendung

In diesem Dokument wird der Begriff „Archivierung" im Sinne des Begriffes „Langzeitarchivierung" verwendet, also im Sinne der Verlagerung von Dokumenten auf ein schreibgeschütztes Medium, in der Regel mit Vorgaben für die Aufbewahrungsfrist.
Das Dokument hat das Ziel, die Erfahrungen der letzten Jahre beim Umgang mit Archivsystemen zusammenzufassen und Infos für den Umgang mit den Archiven an Interessierte zu vermitteln.

Übersicht der unterstützten Archivsysteme

Wir unterscheiden die Archivsysteme nach der Art der Anbindung an OSECM-Systeme:

• Virtuelle Archivserver:                            Archivsysteme, die über eine API angesprochen werden können, die der Hersteller bereitstellt und die durch spezielle OSECM-Komponenten (virtuelle Archivserver) genutzt werden können.
• Dateisystembasierte Archiv-Systeme:   Der Zugriff erfolgt auf im Netzwerk freigegebene Verzeichnisse im Sinne von Windows-Freigaben (CIFS)

Virtuelle Archivserver

Virtuelle Archivserver werden in Form von DLLs im Serververzeichnis installiert, mit den Namen AXVARCxxx.DLL (z.B. axvarcit.dll für den iTernity –Archivserver).

Die Einbindung der virtuellen Archivserver erfolgt über die Bereitstellung der entsprechenden Lizenz und der Konfiguration im jeweiligen Einrichtungs-Dialog (siehe Administrations-Handbuch).
Folgende System können unter Verwendung eines virtuellen Archivservers angebunden werden:

• Dell DX (abgekündigt)
• IBM Tivoli
• HP iCAS / iTernity (gleiche Softwarebasis)
• EMC Centera
• IXOS
• IHE(bisher Individualentwicklung OSVB) (kein direktes Archivmedium)

Dateisystembasierte Archivsysteme

Die zu archivierenden Dokumente und zugehörige Metadaten werden auf einem freigegebenen Verzeichnis abgelegt, auf dem das Dienstkonto des OSECM-Applikationsservers schreibend und lesend zugreifen können muss. Die Freigabe muss für Windows-Systeme so nutzbar sein wie eine Standard-Freigabe auf einem Windows-Server, mit der UNC-Notation \\servername\freigabename.
Einige der dateisystembasierten Archivsysteme können bei der Ablage auf der Freigabe festgelegte Dateiattribute („last access time" und das Flag „ReadOnly") auslesen und diese nutzen, um die Dateien physikalisch vor Änderungen und Löschung zu schützen. Um diesen Modus zu nutzen, werden sowohl für das Archivsystem als auch für die Anbindung an OSECM spezielle Funktionalitäten, Lizenzen (NAP) und Konfigurationen benötigt. Im Folgenden wird dieser Modus „Compliance Mode" genannt.
Folgende System können ausschließlich unter Verwendung einer Dateisystemfreigabe angebunden werden:

• NetApp
• EMC Celerra/VNX
• HDS (Hitachi Data Services) HCP
• Fast Silent Cube
• Grau Data Archivmanager
• Jukeboxen über Pegasus InveStore

Relevante Systemtabellen, Systemattribute und Dateisystemobjekte

Systemtabellen

Für den Schreibzugriff / den Archivierungsprozess sind alle Systemtabellen für den jeweiligen Archivsystemtyp relevant.
Für den Lesezugriff auf archivierte Dokumente und die Dearchivierung werden ausschließlich die Informationen aus der medien- und path- bzw. der varcsystems-Tabelle verwendet.
Zusätzlich zu den oben genannten Systemtabellen enthält die Tabelle "osobjhist" Einträge zu Änderungen am Archivierungsstatus von Objekten. Neben der Objekt-ID wird in dieser Tabelle protokolliert, welche Aktion wann von wem durchgeführt wurde. Für die Archivierung sind folgende Aktionen relevant:

Relevante Systemattribute in den Objekttabellen

In allen Objekttabellen werden Informationen (Metadaten) zur Archivierung von einzelnen Objekten in Systemattributen / -spalten gehalten:

Relevante Dateisystemobjekte im Datenverzeichnis

Zusätzlich zu den in der Datenbank gespeicherten Informationen bzgl. der Langzeitarchivierung werden weitere Daten im Dateisystem und auf den Medien abgelegt, die einer Systemwiederherstellung bei beschädigten oder verlorenen Datenbank dienen.
Dazu dient als Vorbereitungs- und Sicherungsverzeichnis das Unterverzeichnis ARCHIVE unterhalb des Server-Datenverzeichnisses. (nicht zu verwechseln mit dem Pfad zu den Medien!). Während der Archivierung werden diese Daten in das Verzeichnis SYS auf den Medium geschrieben. Die Daten im ARCHIVE-Verzeichnis dienen danach als Backup – und enthalten lediglich die aktuellste Version für das jeweilige Medium.
In diesem Ordner wird für jedes Medium bzw. für jedes virtuelle Archiv ein Unterordner angelegt – hier im Beispiel für ein Medium "med0001" der Zustand nach mehreren Archivierungsvorgängen auf dieses Medium:

In der Textdatei "recover.ini" wird eine fortlaufende Nummer geführt, um die zu den archivierten Objekten gehörenden Indexdatendatei und, falls konfiguriert, auch die komplette Objektdefinition zu versionieren. Hier: LNR=27, dadurch bekommen die Dateien im SYS die Version "01B" mit in den Dateinamen – das ist die Hexadezimaldarstellung der Dezimalzahl 27.
Warum dieses Konstrukt? Ohne Versionierung würde versucht werden, für das eigentliche Medium beim nächsten Lauf Indexdaten-Dateien mit dem aktuellen Inhalt, aber dem immer gleichen Namen zu überschreiben. Dies würde in der Regel fehlschlagen, da die zuerst geschriebene Datei durch das Storage-System absolut unveränderbar sein kann (Compliance Mode).
Wenn es bei der Verwaltung dieser fortlaufenden Nummer zu Problemen kommt, sprich: nicht "hochgezählt" wird, entstehen Meldungen im Archivierungsreport und im Error-Log des archivierenden Servers nach dem Motto: kann ..med0001\SYS\... nicht schreiben, weil Zugriff verweigert... Der Archivierungslauf wird dabei jedoch nicht abgebrochen, sondern fortgesetzt – solange die Dokumentdateien auf das Medium geschrieben werden können.
Achtung: Die Daten im ARCHIVE-Unterverzeichnis dürfen nur für bereits geschlossene Medien entfernt werden, da es sonst zu Problemen bei der fortlaufenden Nummerierung in der "recover.ini" Datei kommen kann.
Bei den dateisystembasierten Archiven findet man den SYS-Ordner dann unter dem eigentlichen Medium – dort aber dann mit ALLEN bis dahin erzeugten / aufgelaufenen Versionen der Indexdaten und ggf. der Objektdefinition – hier ein Ausschnitt für das Beispielmedium:

Achtung: Ist für den Pfad eine Retentionszeit eingestellt, werden auch die Dateien im SYS-Verzeichnis mit der Retentionszeit des jeweils letzten Dokumentes im Archivlauf versehen

Das Jahr-2038-Problem

Ein Teil der Archivsysteme basiert auf UNIX- oder LINUX-Betriebssystemen. Auf diesen werden Zeit Stempel (timestamps) häufig noch als Vorzeichen behafteter 32-Bit-Integer-Wert gespeichert, in Form der vergangenen Zeit in Sekunden seit dem 1. Januar 1970. Nach Ablauf von 2.147.483.648 Sekunden, am 19. Januar 2038 um 3:14:08 Uhr UTC kommt es dann zu einem Speicher-Überlauf.
Zeit Stempel vor dem 13. Dezember 1901 20:45:52 UTC sind ebenfalls nicht darstellbar, da hier der Zeit Stempel kleiner als −2.147.483.648 wäre.
Für Details siehe: http://de.wikipedia.org/wiki/Unixzeit
Warum ist dies nun schon heute ein Problem für die Langzeitarchivierung? Viele wichtige Dokumente, vor allem im regulierten Umfeld, müssen 25 Jahre oder länger aufbewahrt werden. Wenn ein derartiges Dokument heute archiviert wird, muss die Aufbewahrungsfrist auf ein Datum nach dem 19. Januar 2038 gesetzt werden, da
2014 + 25Jahre = 2039!
Die meisten Hersteller haben auf dieses Problem bereits reagiert – mit Übergangs- und endgültigen Lösungen. Auf bestehenden, älteren Systemen ist dafür ggf. ein Software-Update notwendig.
Auf der Enaio-Seite muss für den korrekten Gebrauch von Zeitstempeln je nach angebundenem Archivsystem der Registry-Parameter
.\Archiv\RetentionBehavior2038
auf einen speziellen Wert gesetzt werden:

1 Unix-Zeit Bereich (Überlauf am 19. Januar 2038) Archivierungen mit Retention-Zeit nach diesem Datum werden abgelehnt!!!
2 Fortlaufender Zeit Bereich (für Systeme mit endgültiger Lösung und für nicht betroffene Systeme (z.B. mit Windows-Betriebssystem))
3 erweiterter NetApp-Bereich (für NetApp und kompatible Systeme mit „Übergangslösung": Ab 19.01.2038 wird der Zeit Bereich zwischen 1.1.1970 und 2003 verwendet, um Zeiten bis 2072 abzubilden. Das bedeutet, dass für Retention Zeiten nach 2038 Datumsangaben aus diesem Zeit Bereich verwendet werden und umgerechnet werden müssen (time shift))

Hinweis: für jedes Archivsystem und jede Systemsoftwareversion muss erneut geprüft werden, in wie weit das Problem besteht und darauf reagiert werden muss!
Zur Information: für Windows Betriebssysteme und dessen NTFS-Dateisystem-Datenbank werden die verschiedenen Datei-Zeit Stempel als 64bit-Wert in 10ns (10^-7s) Intervallen ab dem 1.1.1601 (UTC) abgelegt, und hier gibt es einen Maximalwert im Jahre 30.828. Die Genauigkeit der LAT liegt im Bereich vom tatsächlichen Ändern bis zu 1 Stunde danach! (siehe https://msdn.microsoft.com/en-us/library/windows/desktop/ms724290%28v=vs.85%29.aspx – "The NTFS file system delays updates to the last access time for a file by up to 1 hour after the last access.")

Konfiguration der Archivierung

Lizenzen

• dateisystembasierte Archivsysteme:
• Ohne Setzen der Compliance-Parameter -> keine separate Lizenz erforderlich
• Mit Setzen der Compliance-Parameter -> Lizenz NAP erforderlichDie Lizenz muss dem Server zugewiesen werden, der letztendlich den Archivierungslauf durchführt.

• Virtuelle Archivserver: Es müssen so viele Lizenzen vorhanden sein wie es Server in der Serverfamilie gibt. Zwar schreibt in der Regel nur einer der Server auf das Archiv, beim Lesen jedoch müssen ALLE Server in die Lage versetzt werden, direkt auf das Archiv zuzugreifen.
• HP iCAS / iTernity -> Lizenz ITE erforderlich
• EMC CenteraStorage -> Lizenz CEN erforderlichMultistorage Cluster (2 Knoten) -> Lizenz CEM erforderlich
• IBM Tivoli -> Lizenz TSM erforderlich

Allgemeine Einstellungen zur Steuerung

Zur Steuerung der Archivierung können für jeden Server der Serverfamilie diverse Einstellungen vorgenommen werden – in der Regel stellt man die Parameter mit dem Enterprise Manager ein. Die Parameternamen beziehen sich auf den Zweig "Einstellungen\Servereigenschaften\" und darin auf die Kategorie "Daten" und darin den Abschnitt "Archivierung". Zu jedem Parameternamen gibt es einen zugehörigen Registrierungswert in der Registry des Servers unter "\Schema\Archive\" (in der folgenden Tabelle immer in runde Klammern gesetzt) – einige der relevanten Einstellungen können NUR in der Registry vorgenommen werden.

Ablauf der Konfiguration der relevanten Systemobjekte

Die genannten Systemobjekte in den für die Archivierung relevante Systemtabellen werden mit dem Enterprise Manager erzeugt – unter der Servergruppe im Zweig Verwaltung -> Medienverwaltung.
Änderungen an den Systemobjekten erfordern einen Neustart des Applikationsservers, welcher die Archivierungsläufe durchführen soll.

Dateisystembasierte Archivsysteme

Einrichtung der Pfade zu den Medien
Für jeden Pfad zu den Medien wird genau ein UNC-Pfad und bei Bedarf die Compliance-Parameter für die dateisystembasierte Archivierung hinterlegt. Es muss gewährleistet werden, daß das Dienstkonto, unter dem der Applikationsserver läuft, volle Zugriffrechte auf den UNC-Pfad hat.
Der Alias sollte so gewählt werden, daß bereits im Namen erkennbar ist, wie der Pfad konfiguriert ist.
Beispiel für einen Pfad für die Aufbewahrung von Dateien für 10 Jahre im Compliance-Modus:

Der Pfadname ist der physikalische UNC-Pfad zu einer CIFS-Freigabe – so wie er durch das dateisystembasierte Archivsystem bereitgestellt wurde, hier: \\10.10.77.131\archiv1\10Jahre.
Die Compliance-Parameter sind:
"Als schreibgeschützt markieren" – setzt den Schreibschutz auf allen Dateien, die abgelegt werden.
"Letzten Zugriffszeitpunkt setzen" – setzt das Dateiattribut "Letzter Zugriff" auf einen berechneten Wert.
"Retention (Tage)" – gibt den Standardwert für die Aufbewahrungsfrist in Tagen ab dem Zeitpunkt des Archivierungslaufes vor. Dieser Standardwert wird nur bei den Objekten verwendet, bei denen das geplante Aufbewahrungsfristende (retention_planned) nicht explizit gesetzt ist.
Beim Archivierungslauf wird dann pro zu archivierenden Objekt das Ende der Aufbewahrungsfrist berechnet, und dieser Wert wird den Dateien und dem Objekt (siehe Abschnitt 3.2) "mitgegeben":
IF Pfad_Parameterwert(Letzten Zugriffszeitpunkt setzen) = true THEN IF Objektwert(retention_planned) IS NULL THENAufbewahrungsfristende = getdate() + Pfad_Parameterwert(Retention (Tage))ELSE Aufbewahrungsfristende = Objektwert(planned retention)) END IF SET Dateiattribut(Letzter Zugriff) = Aufbewahrungsfristende SET Objektwert(retention) = AufbewahrungsfristendeEND IFIF Parameterwert(Als schreibgeschützt markieren) = true THEN SET Dateiattribut(schreibgeschützt) = trueEND IF
Der Parameter "Wechseldatenträger (z.B. WORM)" ist nur zu verwenden, wenn auf Wechseldatenträger mit festgelegter Größe geschrieben wird, wie WORMs, Magnetbänder, DVDs oder CDROMs.
Alle Pfade zu den Medien (jeweils flag=1, intern eindeutig identifiziert durch eine osguid) werden zusammen mit den Pfaden zum WORK und zum CACHE in der Tabelle PATH in der Datenbank gespeichert, mit dem o.g. Beispielpfad und einem Server:

Einrichtung der Mediensets
Mediensets dienen als Ziel der Archivierung für die dem jeweiligen Set zugeordneten Objekttypen.
Sie sind bei Nutzung von dateisystembasierten Archivsystemen (Mediensettyp: interne Medienverwaltung) als Container- und Verwaltungsobjekte für Medien und bieten die (empfohlene) Option zur automatischen Erzeugung von Medien ("Automedien") aus Vorlagen auf definierten Pfaden und eine Option zur gespiegelten Archivierung, um bei Bedarf die Ausfallsicherheit zu erhöhen:
Beispiel für ein Medienset bei Nutzung eines dateisystembasierten Archivsystems:
 
Der Name und der Alias sollte so gewählt werden, daß bereits im Namen erkennbar ist, wie der zugehörige Pfad konfiguriert ist.
Die Checkbox "Vorlage für die Medienbezeichnung festlegen" aktiviert die "Automedien" und die Vorlage für neue Medien kann konfiguriert werden:
Die Mediengröße (MB) legt fest, welche Größe ein Medium maximal erreichen darf, bevor es geschlossen und ein neues Medium angelegt, für die Archivierung auf das Medienset aktiviert und vom Archivierungslauf "befüllt" wird.
Nun müssen noch Regeln für die Namensvergabe für die anzulegenden Automedien angegeben werden, sowie der Basispfad (ein zuvor angelegter Pfad zu den Medien). Ein Medienname besteht dann aus einem Präfix, einer vierstelligen fortlaufenden Nummer, optional einem Suffix. Mit diesem Medienname wird später, beim automatischen Anlegen der Medien, ein Unterordner mit diesem Namen unterhalb des konfigurierten Basispfades angelegt.Auf diese Art muß eine Namensvorlage für das "Hauptmedium" und wahlweise ein "Spiegelmedium" festgelegt werden – dies kann für die Übersichtlichkeit einen Suffix erhalten (z.B. "mirror") - und sollte letztendlich auf einem anderen physikalischen Ort liegen, um auch tatsächlich die Ausfallsicherheit zu verbessern. Eine gespiegelte Archivierung (durch enaio) ist nur dann sinnvoll, wenn die gewünschte Ausfallsicherheit nicht durch das Archivsystem selbst (z.B. automatische Replika an andere Standorte, RAID-Systeme) erreicht wird.Wenn _Haupt- und Spiegelmedium festgelegt sind, betrachtet der Archivierungslauf Dateien nur dann als erfolgreich archiviert, wenn die Dateien auf das Hauptmedium UND auf das Spiegelmedium geschrieben werden konnten.

Verbindungen zu den Medien
Nun wird noch die Zuweisung der Dokumenttypen zum gewünschten Medienset durchgeführt.

Ein Dokumententyp kann nur genau einem Medienset zugewiesen werden. Diese Zuweisung ist lediglich für den Archivierungslauf relevant. Eine spätere Änderung der Zuweisung ist nur für zukünftige Archivierungsläufe wirksam – bereits archivierte Objekte werden NICHT verändert! Ein späterer Lesevorgang auf einem archivierten Objekt wertet das Medienset NICHT aus! In der Objekttabelle (siehe oben) wird lediglich die ID des Mediums vermerkt (medium_doc) – und der relative Pfad der Dokumentdateien unterhalb des Mediums (name_doc).
Bei der Konfiguration des Archivierungsjobs (siehe Kapitel 5.4) sind nur die aktuell (irgendeinem Medienset) zugewiesenen Objekttypen sichtbar. Werden später weitere Objekttypen (irgendeinem Medienset) zugewiesen, muss ggf. der Archivierungsjob rekonfiguriert werden.

Virtuelle Archivserver

Virtuelle Archive Die Einrichtung der Archivierung erfolgt hier nicht über Pfade, sondern über die Nutzung einer DLL für das jeweiligen Archivsystem. Die jeweilige DLL verwendet die vom Hersteller des Archivsystems bereitgestellten API-Aufrufe (Programmierschnittstellen).
Das gleiche reale Zielsystem und auch die gleiche reale DLL kann bei Bedarf mehrfach verwendet werden – mit unterschiedlichen Einstellungen, zum Beispiel für die Aufbewahrungsfrist – zu diesem Zweck werden sogenannte "virtuelle Archive" angelegt:

Der Alias sollte so gewählt werden, daß bereits im Namen erkennbar ist, wie das virtuelle Archiv konfiguriert ist und welches Archivsystem verwendet wird – z.B. "iTernity10Jahre".
Der nachfolgende Konfigurationsdialog ist vom Archivsystem abhängig hier zum Beispiel für eine iTernity:

Mediensets Im Falle virtueller Archivserver erfolgt im Medienset nur eine Verknüpfung zu einem zuvor angelegten virtuellen Archiv:
 

Verbindungen zu den Medien
Danach wird die Zuordnung der Dokumenttypen zum Medienset durchgeführt:

Ein Dokumententyp kann nur genau einem Medienset zugewiesen werden. Diese Zuweisung ist lediglich für den Archivierungslauf relevant.
Eine spätere Änderung der Zuweisung ist nur für zukünftige Archivierungsläufe wirksam – bereits archivierte Objekte werden NICHT verändert!
Ein späterer Lesevorgang auf einem archivierten Objekt wertet das Medienset NICHT aus! In der Objekttabelle (siehe oben) wird hier die vom Archivierungslauf die ID des virtuellen Archives (systemid) vermerkt – und die vom API-Aufruf zurückgegebene ID des Objektes auf dem (fremden) Archivsystem (foreignid).
Bei der Konfiguration des Archivierungsjobs sind nur die aktuell (irgendeinem Medienset) zugewiesenen Objekttypen sichtbar. Werden später weitere Objekttypen (irgendeinem Medienset) zugewiesen, muss ggf. der Archivierungsjob rekonfiguriert werden.

Einrichtung des Archivierungsjobs

Festlegung des Jobs im Administrator Automatische Aktionen DLL AXACARCH.DLL

Es werden nur Dokumententypen angezeigt, für die eine Zuordnung zu Mediensets festgelegt wurde.

Ablaufdiagramme des Archivierungsjobs

Abläufe während der Archivierung

• Start eines Jobs DoArchive am Server Achtung: Der Job kann nicht durch Beenden des aufrufenden Programmes (AXAUTO) beendet werden
• Liste aller zu archivierenden Dokumente wird erstellt (Select Jobs )
• Ermittlung des Mediensets für den Dokumententyp Klärung ,ob Pfade oder virtueller Archivserver verwendet werden muss
• Hier weiter, wenn Pfade ermittelt wurde:
• Ermittlung der Zugriffspfade für die Medien
• Ermittlung des aktuellen Mediums einschließlich Platzüberprüfung
• Schreiben des Dokumentes auf das Medium und wenn eingestellt auf das Spiegelmedium In der Objekttabelle werden nach jedem Dokument FLAGS, MEDIUM_DOC und NAME_DOC geschrieben, wenn der Kopierbefehl korrekt .Es werden die Daten des Dokumentes in eine Übersichtsdatei im OSARCHIVE-Verzeichnis geschrieben
• Nach Abschluss aller Dokumente wird die Übersichtsdatei aus den OSARCHIVE Verzeichnis in das SYS-Verzeichnis des Mediums geschrieben. Weiterhin wird bei Festlegung auch die aktuelle Objektdefinition mit fortlaufender Nummer dorthin kopiert
• Nochmalige Kontrolle des Platzes auf dem Medium

Für Vorverarbeitung der Dokumente steht die Aktion AXACPREF bereit. Diese kann vor einer Archivierung die Dokumente bereits zum Archivierenden Server übertragen. Damit entfällt die Übertragung zum Zeitpunkt der Archivierung.

Auswertung der Protokolle

Protokolle
Folgende Protokolle werden im Rahmen der Archivierung geschrieben:

• Os<datum>.repReportprotokoll (im Server-Log-Verzeichnis)
• Archive<datum>.xml ausführliche Protokolldatei, zusammen mit archive.xsl
• Pfad und Dateiname können über enaio® enterprise-manager festgelegt werden. Voreingestellt ist der Dateiname archive%5%7%6%8%9%10.xml. (%5 steht für das Jahr, %7 für den Monat, %6 für den Tag, %8 für die Stunde, %9 für die Minute, %10 für die Sekunde).

• Die Datei wird in das Serverprotokollverzeichnis \server\log geschrieben.
• Zur Anzeige wird das Stylesheet archive.xsl verwendet. Diese Datei wird in das Verzeichnis \server installiert und jeweils in das Verzeichnis kopiert, in dem die erweiterte Archivierungsprotokolldatei erzeugt wird.

Abbruch der Archivierung

Wird eine Archivierung gestartet, wird der Serverjob DoArchive aufgerufen. Dieser Job läuft am Server und wird NICHT beendet, wenn der aufrufende Prozess (z.B. AXAUTO) gestoppt wird. Daher muss dieser Job auf anderen Wege beendet werden. Während der Archivierung wird nach jedem Datensatz geprüft, ob im Server\OSTEMP eine Datei mit Namen CANCELJOB.$$$ liegt (kann leer sein). Wird diese gefunden, wird sie aus dem Verzeichnis entfernt und die Archivierung abgebrochen.
Achtung: Das gilt für den aktuellen Archivierungsjob. Sind mehrere Archivierungsjobs vorhanden, setzt er mit dem nächsten fort.

Aufgaben und Aktionen im Umfeld der Archivierung

Einstellungen für das Arbeiten mit Objekten in Bezug zur Archivierung

Für das clientseitige Arbeiten mit Objekten gibt es folgende hier relevante Einstellungen:

1. Über die Zuordnung der Systemrolle "Client: Archivierte Dokumente löschen" zu Benutzern kann im Enaio-Administrator eingestellt werden, wer archivierte Objekte löschen darf (im Sinne von: "Verschieben in den Papierkorb"). Nur administrative Benutzer sollten diese Rolle erhalten – damit die langzeitarchivierten Dokumente in der Regel immer an ihrem Standort sichtbar bleiben.
2. Über die Zuordnung der Systemrolle "Client: Archivierungsstand ändern" zu Benutzern kann im Enaio-Administrator eingestellt werden, wer interaktiv Objekte "Zur Archivierung freigeben" oder "Nicht zur Archivierung freigeben" darf (Tastenkürzel F7). Für Benutzer ohne diese Rolle sind die zugehörigen Menüpunkte aus gegraut. Der Entzug dieser Rolle für nichtadministrative Benutzer macht vor allem dann Sinn, wenn der Archivierungsstand nur durch automatische Aktionen (z.B. fachliche Aufbewahrungssteuerung) und/oder Schnittstellen geändert werden soll.

3. Im Enaio Administrator kann global (für alle Benutzer) eingestellt werden, ob langzeitarchivierte Objekte an einen anderen Standort verschoben werden dürfen: Allgemein -> Reiter Dokumente -> Verschieben von Objekten:

4. Diese Einstellung wird in der Datei as.cfg gespeichert und ist damit für alle Server der Servergruppe gültig (Sektion [System], Schalter "MoveObjects", wenn der Wert 2, dann dürfen archivierte Dokumente nicht verschoben werden).

Prüfung der Konsistenz des Systems

Hier geht es nur um die archivierten Objekte.
Die Konsistenz des Gesamtsystems (WORK, Ablagen usw) werden hier nicht betrachtet.

Notwendiger Inhalt:
- Sind alle Dokumente, die auf Speichermedien liegen sollen, wirklich vorhanden?
- Sind sie vollständig lesbar und reproduzierbar?
- Fehlerbehandlung, wenn ein Dokument fehlt oder fehlerhaft ist
- Erstellung von Protokollen für den Nachweis der Unversehrtheit

Komponenten für die Prüfung

Filebasierte Speicher:
- AXACTARCH
    Diese DLL kann nicht bei virtuellen Archiven verwendet werden. Dort kann man als Alternativ die Hashprüfung verwenden.

Archivkonsistenz
Sie können überprüfen, ob Dokumente, die in der Datenbank verzeichnet sind, auch auf dem Speicher vorhanden sind.

Reparatur Archivsystem
Werden bei der Überprüfung der Archivkonsistenz Dokumente gefunden, die den Status 'archiviert' haben, nicht auf den Archivierungsmedien gespeichert sind, aber im Cache vorliegt, können diese Dokumente wieder integriert werden

Archivkontrolle

Durch Archivierungsfehler können Dokumente, die auf Archivierungsmedien gespeichert wurden, weiterhin die Eigenschaft 'zur Archivierung freigegeben' behalten. Solche Dokumente können Sie durch die Aktion 'Archivkontrolle' ermitteln.

Passieren kann das, wenn ein Dokument auf dem Hauptmedium archiviert wird, aber nicht auf das Spiegelmedium geschrieben werden kann. Auch nach einer Korrektur des Spiegelmediums ist ein Archivieren nicht möglich, da das schon geschriebene Dokument auf dem Hauptmedium nicht überschrieben werden kann.

Verzeichnisvergleich
Sie vergleichen den Inhalt von Verzeichnissen, beispielsweise ein Archivierungsmedium mit dem zugeordneten Spiegelmedium

Virtuelle Server
Da hier keine Medien existieren, sondern der Standort über Foreign-ID und System-ID bestimmt werden, funktioniert die AXTESTARCH nicht.
Es kann für die Überprüfung die Hashwertprüfung ACACHASH und AXACHASHD verwendet werden.

Automatische fachliche Aufbewahrungssteuerung 

Mit der Automatischen Aktion 'Fachliche Aufbewahrungssteuerung', axacaret.dll, ermitteln Sie über eine Anfragedatei Dokumente und aus entsprechenden Datenblättern ein Datum, das als geplante Retentionszeit für die Dokumente eingetragen wird. Über eine Änderungsdatei können optional die Indexdaten des Objekts, aus dem das Datum übernommen wurde, geändert werden.
Die geplante Retentionszeit wird nur eingetragen, wenn bisher keine geplante Retentionszeit angegeben war oder eine bereits eingetragene Retentionszeit vor dem neuen Datum für die geplante Retentionszeit liegt. Verweisdokumente werden nur bearbeitet, wenn Sie über virtuelle Server verwaltet werden. Für Dokumente, die in mehreren Ordnern oder Registern liegen, wird eine Änderung der Retentionszeit gegebenenfalls mehrmals geprüft

[ANFRAGE]                                                      Die Datei beginnt mit dem Abschnitt 'Anfrage'.
SCHRANK=Schrankbezeichnung                    In der ersten Zeile geben Sie den Schrank an, aus dem die Dokumente stammen.
DOKUMENT=Dokumenttypbezeichnung       In der zweiten Zeile folgt der Dokumenttyp der  Dokumente.
KLAUSEL1=Objekt@Feld=Wert                      Mit optionalen Klauseln schränken Sie die Auswahl auf die Dokumente ein, die die Klauseln erfüllen.
...
KLAUSELn=Objekt@Feld=Wert                    Die Klauseln müssen fortlaufend nummeriert werden.
Datenfelder=1                                               Vorgegebener Eintrag
[Anfragefelder]                                             In diesem Abschnitt geben Sie das Feld an, dass das  Datum für die geplante Retentionszeit enthält
Feld0=Feldname                                           Das angegebene Feld muss ein Datum enthalten und sich auf dem durch den Typ der Anfrage spezifizierten Objekttyp befinden.

Verwenden Sie interne Namen und klammern Sie die Bezeichnung durch das Prozentzeichen.

Folgende Anfragetypen stehen zur Verfügung:

• Dokumentenanfrage

Das Feld mit dem Datum und das optionale Änderungsfeld befinden sich auf dem Datenblatt des Dokuments.

• Registeranfrage

Das Feld mit dem Datum und das optionale Änderungsfeld befinden sich auf dem Datenblatt des Registertyps. Für alle Dokumente im Register, die in der Anfragedatei angefragt werden, wird die geplante Retentionszeit geändert.

• Ordneranfrage

Das Feld mit dem Datum und das optionale Änderungsfeld befinden sich auf dem Datenblatt des Ordnertyps. Für alle Dokumente im Ordner, die in der Anfragedatei angefragt werden, wird die geplante Retentionszeit geändert

Mit der Änderungsdatei können (optional) Änderungen in das jeweilige Datenblatt geschrieben werden.

Zusätzlich können Sie angeben, ob die Dokumente die Eigenschaft 'zur Archivierung freigegeben' erhalten sollen.

Nachträgliche Anpassung der Aufbewahrungsfrist

Die Automatische Aktion 'Retentionszeit anpassen', axacadjr.dll, übernimmt für alle archivierten Dokumente die geplante Retentionszeit, trägt diese als Retentionszeit ein und ändert die Retentionszeit des Dokumentes auf dem Speichermedium. Liegt die geplante Retentionszeit vor der Retentionszeit, werden die Daten nicht geändert. Ist die Retentionszeit nicht angegeben, wird die geplante Retentionszeit als Retentionszeit eingetragen. Liegt die geplante Retentionszeit in der Vergangenheit, werden keine Änderungen vorgenommen.
Bei der Konfiguration der Automatischen Aktion 'Retentionszeit anpassen' wird der gewünschte Dokumenttyp angegeben, für den die Aktion ausgeführt werden soll. Die Anzahl der archivierten Dokumente wird dabei angezeigt

Aktionen zur Dearchivierung

Dearchivierung
Die Automatische Aktion 'Dearchivierung' kopiert bereits revisionssicher archivierte Dokumente eines Typs von Archivierungsmedien in den Workbereich und kennzeichnet die Dokumente als 'nicht archiviert'. Die Dokumente können danach wieder bearbeitet werden oder mit einer anderen Konfiguration erneut archiviert werden.
Als Bibliothek für die Aktion 'Dearchivierung' binden Sie die axacunac.dll ein (siehe 'Registerkarte 'Zusätze').
Beim Einrichten der Automatischen Aktion (siehe 'Automatische Aktionen einrichten') geben Sie eine Konfigurationsbezeichnung an und wählen im Konfigurationsdialog eine Anfragedatei. Sie geben an, ob ebenfalls Varianten dearchiviert werden sollen und ob die dearchivierten Dokumente die Eigenschaft 'zur Archivierung freigegeben' erhalten sollen.

Über die Anfragedatei legen Sie fest, welche Dokumente dearchiviert werden. Über Einstellungen der Servereigenschaften in der Kategorie: Integrität ist festgelegt, ob eine Hashwertprüfung und eine Signaturprüfung nach der Dearchivierung stattfinden.

Sie können die Aktion manuell starten oder einen Zeitpunkt eintragen, zu dem die Aktion automatisch von enaio® start gestartet werden soll (siehe 'enaio® start'). Über eine Anfragedatei der Aktion 'Dearchivierung' können nur Dokumente eines Dokumenttyps dearchiviert werden. Hat der Dokumenttyp die Eigenschaft 'Dokumentversionen archivieren', werden alle alten Versionen der Dokumente ebenfalls dearchiviert.

Die Anfragedatei erstellen Sie mit einem beliebigen Editor. Sie hat folgende Struktur:

[ANFRAGE]
SCHRANK=Kunden    
REGISTER=Akte
DOKUMENT=Bild
Ausdruck1=Bild@1904^5^15.5.2011

Verwenden Sie interne Namen und klammern Sie die Bezeichnung durch das Prozentzeichen.

Klauseln

Mit optionalen Klauseln schränken Sie die Auswahl auf die Dokumente ein, die im angegebenen Feld mit dem angegebenen Wert indexiert sind.

Beispiel:

Klausel1=Kunde@Status=abgeschlossen

Nur die Dokumente des angegebenen Dokumenttyps werden dearchiviert, die in den Indexdaten des Archivobjekttyps 'Kunde', beispielsweise ein Ordner, im Feld 'Status' mit dem Wert 'abgeschlossen' indexiert sind.

Alternativ können Sie eine Liste mit IDs von Dokumenten für die Dearchivierung erstellen. Sie geben jeweils die ID des Dokuments und die ID des Dokumenttyps an.

Struktur: <objectid>,<objecttypid>;<objectid>,<objectypid>;…

Varianten der über IDs angegebenen Dokumente werden nicht dearchiviert.

Versionen werden dearchiviert

Mediendearchivierung
Die Automatische Aktion 'Mediendearchivierung' kopiert alle revisionssicher archivierten Dokumente beliebigen Typs eines Archivierungsmediums in den Workbereich und kennzeichnet die Dokumente als 'nicht archiviert'. Die Dokumente können danach wieder bearbeitet werden oder mit einer anderen Konfiguration beispielsweise auf anderen Medien erneut archiviert werden. Die Bibliothek für die Aktion 'Mediendearchivierung', axacunme.dll, binden Sie ein (siehe 'Registerkarte 'Zusätze').
Beim Einrichten der Automatischen Aktion (siehe 'Automatische Aktionen einrichten') geben Sie eine Konfigurationsbezeichnung an und markieren im Konfigurationsdialog die gewünschten Medien.

Sie wählen ebenfalls, ob die dearchivierten Dokumente die Eigenschaft 'zur Archivierung freigegeben' erhalten sollen. Wenn Sie die Option Archivierung für die betroffenen Dokumententypen starten markieren, wird nach dem Dearchivieren aller gewählten Medien automatisch die Archivierung der Dokumenttypen gestartet, die sich auf den Medien befinden. Dabei werden die aktuellen Verbindungen zu den Medien für die Dokumenttypen verwendet.
Wenn Sie die Option Nach jedem Medium Archivierung starten markieren, wird nach dem Dearchivieren jedes einzelnen Mediums automatisch die Archivierung der Dokumenttypen gestartet, die sich auf den Medien befinden. Dabei werden ebenfalls die aktuellen Verbindungen zu den Medien für die Dokumenttypen verwendet.
Liegen für dearchivierte Dokumenttypen keine Verbindungen zu Medien vor, werden die Dokumente dieser Typen nicht archiviert. Hat der Dokumenttyp die Eigenschaft 'Dokumentversionen archivieren', werden alle alten Versionen der Dokumente ebenfalls dearchiviert und neu archiviert.
Die Aktion erstellt eine zusätzliche Protokolldatei im Protokollverzeichnis.
Die Bezeichnung lautet UnArchive_YYYYMMDD.txt.

Löschen von archivierten Objekten

Objekte im Enaio sind vom Grundsatz her immer löschbar. Das gilt auch für archivierte Dokumente, egal wo sie im Archivierungsfalle gespeichert wurden. Auch eine Speicherung auf nicht löschbaren Bereichen verhindert nicht die Möglichkeiten, alle Hinweise aus der Datenbank des Systems auf das jeweilige Objekt zu entfernen.
Eine Verhinderung kann also immer nur auf administrativen Wege durchgeführt werden über

• Klauseln auf das Löschrecht
• Entzug der Rollen zum Löschen des Objektes sowie das Entfernen aus dem Papierkorb
• Überprüfung der Löschmöglichkeit auf dem Speichermedium und Verhindern des Löschens, wenn das Dokument nicht vom Speicher gelöscht werden kann. (Serverparameter „Archivierte Dokumente löschen")

Besonderheit: Automatische Aktion AXACDEL Objekte löschen
Mit der Aktion 'Objekte löschen' können Sie alle Objekte, die in einer Anfragedatei angegeben sind, von enaio® server löschen. Es können Ordner, Register und Dokumente gelöscht werden.
Wenn Sie Ordner oder Register löschen, wird ebenfalls der gesamte Inhalt gelöscht. Wenn ein Objekt mehrere Standorte hat, wird es an allen Standorten gelöscht.
Sie legen ebenfalls fest, ob die Objekte unwiderruflich gelöscht oder in den Systempapierkorb verschoben werden
Bei Objekten mit Varianten werden die aktive Variante und alle Untervarianten gelöscht. Mit der entsprechenden Option lassen Sie alle Varianten löschen
Beispiel:

Ausdruck1=Objekt@1904^5^15.5.2011

'1904' ist die Datenbankspalte für die Retentionszeit, '^5^' der Vergleichsoperator

'<=' und '15.5.2011' ein Datum.'

[ANFRAGE]
SCHRANK=Kunden    
REGISTER=Akte
DOKUMENT=Bild
Ausdruck1=Bild@1904^5^15.5.2011

Verwandte Artikel

• Page:
  Wie kann man Dokumente auf "archivierbar" setzen?
• Page:
  Archivierung ab 9.10 +Beispiel für Iternity
• Page:
  Wie wird ein Dokument zum Client übertragen?
• Page:
  Archivierung ab 9.10 - Einrichtung für Centera
• Page:
  Wie kann man das Log der iCas / iTernity aktivieren?