Sprache:DeutschEnglish Last updated: 2026-10-24

Langzeitarchivierung: Überblick¶

Anton übernimmt digitale Unterlagen geprüft, erkennt ihre Formate und hält fest, wie gut sie sich erhalten lassen. Einen Master verändert Anton nur, wo das Archiv es eingerichtet oder veranlasst hat: bei der Übernahme durch eine Format-Regel oder die Verarbeitung beim QR-Upload, danach durch eine Migration (siehe Speicherung). Die Speicherung selbst und ihre Redundanz leistet die Betriebsinfrastruktur; bei Installationen mit angebundenem Langzeitarchiv übernimmt dieses die Bitstream-Sicherung. Diese Seite zeigt, wie sich die Aufgaben verteilen, und verweist auf die Detailseiten. Sie beantwortet ausserdem die Frage, welches Artefakt eine Sicherung ist und welches eine Publikationsansicht.

Aufgabenteilung¶

Die digitale Langzeitarchivierung besteht aus mehreren Schichten. Anton deckt die fachlichen ab, der Betrieb die Speicherung:

Aufgabe	Anton	Betrieb	Angebundenes Langzeitarchiv
Prüfsummen bei der Übernahme	prüft jede Datei eines SIP gegen das Paket
Prüfsumme pro Datei	berechnet beim Upload MD5 und SHA-512 und legt sie ab
Formaterkennung und Risiko	PRONOM-ID, NARA-Bewertung, Preservation Planning	stellt Siegfried bzw. Fido bereit
Master und Zugriffskopien	bewahrt den Master, verändert ihn nur über Format-Regeln, Upload-Verarbeitung und `media:migrate`, erzeugt `web` und `thumb`
Integritätsprüfung	bringt `media:check`, `media:snapshot` und `media:repair` mit, protokolliert die Prüfungen	legt den Rhythmus als Cronjob fest, richtet die Sicherung für `media:repair` ein	übernimmt die Fixity der Master
Redundante Speicherung		Kopien an mehreren Standorten	Bitstream-Sicherung
Formatentscheide	zeigt Formate mit Handlungsbedarf

Bei Anton as a Service ist k & r der Betrieb. On Premises ist es die betreibende Institution.

Die Kette¶

Übernahme¶

Beim SIP-Ingest nach eCH-0160 prüft Anton für jede Datei im Paket die in der metadata.xml deklarierte Prüfsumme nach: Der Hash wird über die tatsächliche Datei neu berechnet und verglichen. Weicht er ab, schlägt die Validierung fehl. Der Algorithmus stammt aus dem Paket selbst, ist also nicht auf MD5 festgelegt. Zusätzlich merkt sich Anton die Prüfsumme des SIP-ZIPs und weist bereits eingespielte Pakete ab.

Prüfungen bei jeder Übernahme¶

Unabhängig vom Weg, auf dem eine Datei kommt (Hochladen, Import, SIP, agate), prüft Anton sie, bevor sie zum Medium wird:

Viren: Wo die Virenprüfung eingerichtet ist, wird jede Datei zuerst mit ClamAV geprüft. Ein Fund wandert in die Quarantäne, der Import bricht ab. media:virus-scan prüft auch den Bestand, mit den jeweils neuesten Signaturen. Ein Fund dort wird vermerkt und gemeldet, die Datei bleibt liegen. Dateien über 2 GB kann ClamAV nicht als Ganzes prüfen; Anton schickt sie in überlappenden Teilen von 256 MB. ClamAV sieht dann die Bytes jedes Teils, nicht das Format: Signaturen nach Bytemustern findet es, solche am Dateiende, zum Aufbau des Formats oder über die Prüfsumme der ganzen Datei nicht. Ohne Fund wird die Datei daher als «ohne Befund, in Teilen geprüft» vermerkt, nicht als sauber.
Prüfsummen: Bringt eine Ablieferung Prüfsummen mit, werden sie mit den Dateien verglichen; nach dem Ablegen rechnet Anton die Kopie nach.
Format: Jede Datei wird mit dem Werkzeug ihres Formats geprüft (PDF, TIFF, andere Bilder, Ton und Video), und Endung, Format und PRONOM-ID werden verglichen. Bei PDF hält Anton zusätzlich Erhaltungsrisiken fest: nicht eingebettete Schriften, Verschlüsselung, JavaScript, Verweise auf Programme oder andere Dateien und Links ins Web. Schriften, die nur in der unsichtbaren Texterkennung eines Scans vorkommen, sind kein Risiko. «Ungültig» heisst beschädigt oder nicht lesbar. Eine solche Datei wird übernommen und als ungültig vermerkt; auf Wunsch weist Anton sie ab. Was die Datei nicht beschädigt, gilt als gültig mit Warnung: ein Fehler, über den das Werkzeug hinweg darstellt (etwa ein fehlerhaftes Farbprofil oder ein wiederhergestellter Querverweis), ein PDF, das sich als PDF/A ausgibt und keines ist, und ein JPEG-2000-Bild, an dem nur poppler scheitert, während MuPDF es darstellt. media:validate-formats prüft den Bestand regelmässig gründlicher.

Jede Prüfung steht als Ereignis am Medium. Interne Benutzer:innen sehen sie auf der Medienseite eines Datensatzes: oben die letzte Prüfung je Art, darunter die ganze Liste. Alle Formatprüfungen des Archivs, Tag für Tag gezählt und nach Ergebnis filterbar, finden Admins unter Administration → Protokolle → Formatprüfung.

Format Policy¶

Bevor eine Datei als Medium abgelegt wird, wendet Anton die Format-Regeln an, die das Archiv eingeschaltet hat. Die erste Regel, tiff_zip, packt unkomprimierte TIFF und LZW ohne Predictor verlustfrei nach Deflate mit Predictor 2 um. Vor dem Ersetzen prüft Anton, dass alle Pixel gleich geblieben sind; die Prüfsummen der gelieferten Datei stehen danach im Ereignis am Medium. SIPs bleiben unberührt, weil ihre eigenen Prüfsummen die unveränderte Ablieferung belegen.

Welche Regeln gelten, legen Admins unter Admin → Einstellungen → Regeln für Dateien fest, einmal für das ganze Archiv. Beim Hochladen und Importieren lässt sich keine Regel abwählen. Die Seite zeigt jede Regel als «Wenn … ausser … dann …»: für welche Formate sie gilt, wann sie eine Datei auslässt, welche Schritte sie ausführt und was mit dem Original geschieht; die Befehle mit Werkzeug und Version stehen aufklappbar darunter. Passen mehrere Regeln auf eine Datei, laufen sie in der angezeigten Reihenfolge nacheinander, jede mit dem Ergebnis der vorherigen. Jede Änderung steht mit Benutzer:in und Zeitpunkt im Sicherheitsprotokoll. agate liest dieselben Einstellungen und wendet die Regeln an, bevor es ein SIP abschliesst.

Was die Regeln mit den Dateien eines Tabellen-Imports täten, zeigt die Inspektion vor dem Import. Der Probelauf bestimmt jede verknüpfte Datei, nennt ihre technischen Merkmale und sagt je Regel, ob sie greift oder warum nicht, etwa «ausgenommen bei Kompression Deflate, Predictor 2». Er verändert nichts. Die Grösse nach dem Umpacken rechnet er auf Wunsch je Datei aus.

Speicherung¶

Für jede Mediendatei berechnet Anton beim Upload eine MD5- und eine SHA-512-Prüfsumme in einem Lesedurchgang und legt beide in der Datenbank ab. SHA-512 ist der Referenzwert für die Integritätsprüfung, wie ihn OCFL und BagIt empfehlen; MD5 bleibt für die Anbindung an DIMAG und für das Erkennen doppelter Importe. Für Medien aus der Zeit vor Version 0.98 rechnet media:checksum SHA-512 nach — und prüft dabei jede Datei gegen ihre MD5. Die Ableitungen (web, thumb) sind Zugriffskopien.

Der Master ist nicht in jedem Fall die gelieferte Datei. Bei der Übernahme kann sie verändert werden, bevor sie zum Master wird: durch eine Format-Regel wie tiff_zip, die sie verlustfrei umpackt und die gelieferte Datei verwirft (ihre Prüfsummen stehen im Ereignis am Medium), oder durch die Verarbeitung beim QR-Upload (HEIC → JPEG, Bilder → PDF, OCR), die das Archiv einschaltet; nur «Bilder → PDF» behält die gelieferten Bilder als Originale. Einen abgelegten Master verändert danach nur media:migrate, mit Prüfung und Ereignis; media:repair stellt bloss den geprüften Inhalt wieder her.

Behaltene Originale¶

Neben manchen Mastern liegt das Original, wie es geliefert wurde, im Ordner original/ des Mediums: wenn beim Upload per QR-Code mehrere Bilder zu einem PDF zusammengefasst werden, wenn eine Format-Regel das Original behält, und wenn media:migrate --keep-original einen Master umpackt. Seit Version 0.105 führt Anton jedes solche Original als Fassung des Mediums: mit eigener MD5 und SHA-512, Format (PRONOM) und einem Ereignis, das festhält, woher es kommt. Die Fassungen erscheinen nirgends in der Oberfläche; Listen, Galerie, Download und Export zeigen die aktuelle Fassung.

Originale aus der Zeit davor trägt media:register-originals nach. Ihre Prüfsumme ist dann die vom Tag der Erfassung, und das Ereignis hält das fest: Ob die Datei seit dem Upload unverändert ist, lässt sich nicht mehr belegen.

Bei Mandanten mit DIMAG können die Originale lokal bleiben oder wie die Master ins Langzeitarchiv gehen; das legt der Betrieb je Installation fest (siehe Inge und Dimag).

Formaterkennung und Risiko¶

Beim Upload identifiziert Anton das Format über Siegfried bzw. Fido und hält die PRONOM-ID fest; daraus leitet es die Risikobewertung nach dem NARA Digital Preservation Framework ab. Für Altbestände lässt sich das mit media:identify nachtragen. Ausgewertet wird das im Preservation Planning.

Siegfried oder Fido auf dem Server

Die Erkennung nutzt Siegfried oder Fido, die auf dem Server installiert sind. Fehlt das Programm, gelingt der Upload trotzdem, nur bleibt die Erkennung leer. anton:doctor meldet ein fehlendes sf darum als Fehler. Der Reiter «Nicht identifizierte Medien» zeigt, wie vollständig die Erkennung im Bestand ist.

Formatentscheide¶

Anton migriert bei Bedarf, nicht vorsorglich. Eine Datei bleibt im Format, in dem sie übernommen wurde, solange sie sich mit quelloffenen Werkzeugen richtig darstellen oder abspielen lässt und die Nutzungskopie ohne Fehler entsteht. Anlass für eine Migration ist ein Fehlschlag: bei der wiederkehrenden Prüfung, ob sich die Datei darstellen oder dekodieren lässt (media:validate-formats), oder beim Erstellen der Nutzungskopie. Ob und wohin migriert wird, entscheidet das Archiv.

«Richtig darstellen» prüft die Formatprüfung bei PDF über die Erhaltungsrisiken: Ein PDF ohne eingebettete Schriften etwa erscheint mit Ersatzschriften und sieht anders aus, ohne dass es jemand merkt.

Normalisiert wird bei der Übernahme nach den Regeln für Dateien und im Bestand mit media:migrate, beides mit Prüfung. Ob das Original bleibt, legt die Regel fest: tiff_zip verwirft die gelieferte Datei und hält ihre Prüfsummen im Ereignis fest, media:migrate --keep-original behält sie. Behaltene Originale bleiben bitgenau erhalten, mit Prüfsumme. Grundlage für Entscheide ist das Preservation Planning: Es zeigt, welche Formate im Bestand liegen, welches Risiko NARA ihnen zuweist und welche Handlung NARA empfiehlt.

Welche Formate bevorzugt und akzeptiert sind und welche Eigenschaften erhalten bleiben müssen, steht je Formatkategorie auf einer eigenen Seite: für Bilder, PDF, Text, Audio und Video Tabellen und Präsentationen sowie übrige Formate, Container und XML.

Abgabe¶

Siehe Sicherung oder Publikation? weiter unten.

Integrität prüfen¶

Zwei Befehle prüfen den Bestand gegen die gespeicherten Prüfsummen:

Befehl	Was er tut
`media:check --levels=4`	Liest jede Datei neu, berechnet die Prüfsumme frisch (SHA-512, wo vorhanden, sonst MD5) und vergleicht sie mit der Datenbank. Mit `--log-integrity-check` wird jede Prüfung als Ereignis protokolliert — so entsteht eine nachweisbare Historie. Eine fehlende Datei ist ein Befund, die Prüfung läuft weiter.
`media:snapshot --oldest=N --git`	Schreibt die Referenzwerte aller Medien in Listen (SHA-512 und MD5) und committet sie in ein lokales Git-Repository — nachvollziehbar, wann sich ein Referenzwert geändert hat. Prüft im selben Durchgang die N am längsten nicht geprüften Dateien (oder mit `--verify` alle) und protokolliert jede Prüfung.

Den Rhythmus legt der Betrieb fest

Wie oft die Prüfung läuft, bestimmt ein Cronjob pro Installation. So lässt sich der Rhythmus der Grösse des Bestands anpassen: Ein vollständiger Durchlauf liest jede Datei, und bei mehreren Terabyte will das geplant sein.

Bei Anton as a Service richtet k & r die Prüfung ein (Stand September 2026 für die grossen Archive). On Premises richtet die betreibende Institution den Auftrag selbst ein; die Befehle stehen dafür bereit.

Beide Befehle prüfen auch die lokalen behaltenen Originale, je mit eigenem Pfad in den Listen. Ein beschädigtes Original macht das Medium selbst nicht zum Befund.

Davon zu unterscheiden ist anton:doctor: Es prüft die Konsistenz der Datenbank — Hierarchie, Signaturen, abgeleitete Felder — und ob die Dateien vorhanden sind. Die Prüfsummen vergleichen die beiden Befehle oben.

Wenn die Prüfung anschlägt¶

Weicht eine Datei von ihrer Prüfsumme ab, holt media:repair sie aus der lokalen Sicherung zurück: Es geht die Stände vom neuesten zum ältesten durch (täglich, monatlich, jährlich) und nimmt den ersten, dessen Prüfsumme mit dem gespeicherten Referenzwert übereinstimmt. Die beschädigte Fassung wird nicht gelöscht, sondern in eine Quarantäne kopiert; jeder Vorgang steht als Ereignis in der Historie der Datei.

Anton ersetzt eine Datei nur durch eine, deren Inhalt nachweislich dem Original entspricht. Und die Anwendung liest die Sicherung nur, über eine schreibgeschützte Einhängung; ist die Sicherung beschreibbar, verweigert media:repair die Reparatur. Bei vielen Abweichungen auf einmal repariert es nichts und schlägt Alarm, denn dann liegt die Ursache anderswo (Platte, Einhängung, Schadsoftware).

Findet sich lokal kein passender Stand — etwa weil die Datei jünger ist als die Sicherung —, holen wir sie bei Anton as a Service von Hand von einem der externen Backupserver zurück. Die Meldung von media:repair nennt dafür alles Nötige. Mandanten mit DIMAG sind ausgenommen: Dort liegt der Master im Langzeitarchiv.

Ein lokales behaltenes Original repariert media:repair auf dieselbe Weise; die Schwelle für zu viele Abweichungen zählt Master und Originale zusammen.

Einrichtung durch den Betrieb

media:repair braucht eine lokale Sicherung, welche die Mediendateien enthält, für die Anwendung nur lesend eingehängt ist und in der Konfiguration steht (siehe Installation). Wo das nicht eingerichtet ist, meldet der Befehl das und tut nichts.

Redundante Speicherung¶

Die redundante Speicherung ist Sache der Infrastruktur: Anton schreibt in einen lokalen Speicher und optional in einen Cloud-Speicher, die Kopien darunter legt der Betrieb an. Bei Anton as a Service liegen die Daten in vier Kopien an drei Standorten, zwei davon in Zürich; on Premises verantwortet das die betreibende Institution.

Sicherung oder Publikation?¶

Die wichtigste Unterscheidung, und die am leichtesten zu verwechselnde:

Artefakt	Zweck
Nativer Export (`anton:export-native`)	Sicherung. Verlustfrei und wieder einlesbar: Metadaten in allen Sprachen, Ereignisse, Textfelder — auch private —, Normdaten-Bezüge über UUID und die Master-Medien.
SQL-Dump	Sicherung. Das einzige Artefakt mit Benutzern, Einstellungen, Formularen und der NARA-Bewertung der Dateien (nur der aktuelle Wert, keine Historie). Die Ereignisse am Medium, darunter seit Version 0.107 jede Formaterkennung, stehen auch im PREMIS von DIP, OCFL und nativem Export. Enthält keine Mediendateien.
DIP (BagIt) und OCFL	Abgabepakete. Medien und Metadaten gebündelt, mit Prüfsummen im Manifest.
RDF/CIDOC, EAD, TEI, Memobase	Publikationsansichten. Gefiltert und verlustbehaftet — aus ihnen lässt sich Anton nicht wiederherstellen.
A+ Bundle mit `--include-protected --include-originals`	Migrationspaket. Graph inklusive gesperrter Daten plus Originaldateien — für den Weg in ein anderes System. Kein Restore-Werkzeug nach Anton, und wegen der enthaltenen Personendaten nicht öffentlich zu hosten.

Ein RDF- oder EAD-Export ist kein Backup

Diese Formate sind für Recherche und Austausch gebaut. Ihnen fehlen unter anderem die UUIDs und die Rohwerte; im Standardfall sind private Inhalte herausgefiltert. Für eine Sicherung braucht es den nativen Export und den SQL-Dump.

Das gilt auch dann, wenn mit --include-protected --include-originals exportiert wird: dieses Paket ist als Migrationsweg hinaus gedacht. Ein Rückweg wäre mit Aufwand konstruierbar, ein Werkzeug dafür gibt es nicht.

Die Provenienz einer Datei (Formaterkennung, Prüfungen, Formatregeln, Übernahme) führt Anton in der Datenbank. DIP, OCFL und nativer Export geben sie zusätzlich als PREMIS 3 aus, eine Datei je Datensatz mit Medien; ein empfangendes Langzeitarchiv übernimmt so die Vorgeschichte jeder Datei ohne Antons Datenbank. Nicht darin steht die NARA-Bewertung; METS gibt es nicht.

Welche Daten jedes Format im Einzelnen mitnimmt, welche nur im SQL-Dump stehen und wer welches Artefakt auslösen kann, zeigt die Export-Matrix. Kurz: Der SQL-Dump und die Standard-Exporte gehen über die Oberfläche, der native Round-Trip und das Migrationspaket nur über die CLI.

Für die statische Publikation eines Bestandes als eigenständige Website gibt es ein eigenes Bundle.

Mit angebundenem Langzeitarchiv¶

Bei Installationen mit DIMAG-Anbindung übergibt Anton jede Mediendatei beim Upload über die Middleware Inge an DIMAG und führt Buch, ob die Übergabe verifiziert ist — siehe Upload-Status. Danach liegt die Bitstream-Sicherung des Masters bei DIMAG.

Die Fixity liegt dann bei DIMAG

Auf diesen Installationen prüft das Langzeitarchiv die Master. media:check überspringt sie deshalb mit dem Hinweis, dass die Dateien in DIMAG liegen. Auf Wunsch löscht Anton nach verifizierter Übergabe die lokale Kopie.