S3-Replikation, Sicherung und Wiederherstellung per REST API
Mit der administrativen REST API können Sie native Standortreplikation, externe S3-Spiegelung, Sicherung und Wiederherstellung automatisieren. Verwenden Sie für Änderungen die Rolle admin oder s3-admin. Die Endpunkte sind für Administratoren vorgesehen. Die API-Nutzung erfolgt in eigener Verantwortung und ist nicht durch den Support abgedeckt.
Anfragen und zwei Arten von Jobs
Senden Sie den API-Schlüssel im Header X-API-Key über HTTPS. Zugangsdaten, Passphrasen, Einladungspakete und private Schlüssel gehören in einen JSON-Anfragekörper. Base64 ist eine Kodierung und keine Verschlüsselung. Für wiederholbare Änderungen verwenden Sie einen Idempotency-Key.
- API-Job: Einrichtung, Export/Import eines Wiederherstellungspakets und Anwendung einer Konfiguration können mit HTTP 202 angenommen werden. Die Antwort enthält eine Jobkennung und Statusadresse. Fragen Sie
GET /api/v1/jobs?job_id=...biscompleteoderfailedab. Abbrechen erfolgt überDELETE /api/v1/jobs?job_id=.... - Wiederherstellungsjob: Eine Wiederherstellungsvorschau liefert eine Kennung des Restore-Workers. Überwachen und steuern Sie diesen Job über
backup_statusundbackup_control, nicht über den allgemeinen API-Job-Endpunkt. - Konfigurationswiederherstellung:
backup_configuration_applystartet zunächst einen API-Job, der die Arbeit an den Restore-Worker übergibt. Prüfen Sie anschließend den Sicherungsstatus bisconfiguration_complete.
Native eEKAS-Replikation
GET /api/v1/object-storage/replication listet Beziehungen auf. Mit relationship_id rufen Sie deren Zustand ab. Die Ansichten invitations, audit, buckets, backfill und destinations liefern Einladungen, Protokoll, Bucket-Statistiken, Nachsynchronisierungsaufträge und lokale Dienstinstanzen. Bucket-Abfragen unterstützen marker, query und limit von 1 bis 50. Folgen Sie dem zurückgegebenen Fortsetzungsmarker.
curl --cacert /pfad/ca.pem --get \
--header 'X-API-Key: <API_KEY>' \
--data-urlencode 'relationship_id=<RELATIONSHIP_ID>' \
--data-urlencode 'view=buckets' --data-urlencode 'limit=50' \
'https://eekas.example.com:18443/api/v1/object-storage/replication'POST /api/v1/object-storage/replication verwendet ein action-Feld und die Parameter der gewählten Aktion:
| Aufgabe | Aktionen |
|---|---|
| Einrichtung und Richtlinien | enable, set_mode, set_policy, set_advanced_policy, refresh_topology |
| Synchronisierung und Bestandsobjekte | pause, resume, start_backfill, pause_backfill, resume_backfill, cancel_backfill |
| Schlüsselrotation | rotate_credentials, adopt_credentials, activate_credentials, finalize_credentials |
| Wiederherstellung und Prüfung | recovery_validate, recover_gateway, promote, orchestrate_recovery, dr_test, compliance_report |
| Archivierung und Stilllegung | run_archive, remove_site, decommission_local, revoke_invitation, purge_invitations |
Ein Beispiel für den JSON-Anfragekörper einer Richtlinienänderung ist:
{"action":"set_policy","relationship_id":"RELATIONSHIP_ID","bucket_scope":"all","rpo_seconds":300,"allow_untrusted":false}Die Warnschwelle ist keine garantierte RPO. Ausgewählte native Buckets und Nachsynchronisierungs-Buckets können als JSON-Array oder durch Semikolons getrennte Namen angegeben werden. Bestätigungen für Schreibkonflikte, Datenlöschung und Isolation bleiben erforderlich.
Einladungen und Beitritt
Verwenden Sie POST /api/v1/object-storage/replication/invitations, POST /api/v1/object-storage/replication/invitations/redeem und POST /api/v1/object-storage/replication/join. Beim Beitritt führt validate_only:true eine Vorprüfung aus. Das Ziel muss weiterhin leer sein. Für private Zertifikate können Sie ca_pem als öffentliches CA-Zertifikat oder ca_file als Dateipfad auf dem Server angeben. Lassen Sie die Zertifikatsprüfung aktiviert; allow_untrusted ist eine ausdrücklich gewählte Ausnahme.
Spiegelung und unabhängige Sicherung unterscheiden
Eine externe Spiegelung wird über set_advanced_policy mit config_b64 eingerichtet und durch run_archive ausgeführt. Sie folgt der Spiegelungs- und Löschrichtlinie. Eine Sicherung mit aufbewahrten Generationen verwendet dagegen einen eigenen Katalog, Wiederherstellungspunkte und ein verschlüsseltes Wiederherstellungspaket.
Der Sicherungsmodus direct liest abgeschlossene Objektgenerationen direkt aus der Quelle. Eine bereits vor der Erfassung überschriebene oder gelöschte Generation kann nicht nachträglich gesichert werden. history verwendet eine zusätzliche Archivzone und benötigt eigenen Speicher sowie einen Gateway-Endpunkt.
Sicherungsaktionen und Parameter
Alle folgenden Aktionen verwenden POST /api/v1/object-storage/replication/backups mit {"action":"...","request":{...}}. Erfolgreiche synchrone Antworten enthalten status und data.
| Aktion | Anfrage und Ergebnis |
|---|---|
backup_discover |
Leeres request-Objekt; lokale Realms, Zones und Worker ermitteln. |
backup_bucket_search |
realm, source_zone, query, cursor, limit; maximal 100 Treffer pro Seite. Folgen Sie next_cursor. Ein Index kann zunächst building melden. |
backup_list |
Leeres request-Objekt; gespeicherte Konfigurationen ohne Zugangsdaten auflisten. |
backup_save |
id; für neue Konfigurationen zusätzlich mode, realm, zonegroup, source_zone, host, source_endpoint, endpoint, bucket, access_key und secret_key. bucket_scope=zone umfasst zukünftige Buckets; selected verwendet ein buckets-Array. History benötigt archive_zone, archive_endpoint, gateway_certificate und gateway_private_key. Weggelassene Einstellungen und Geheimnisse bleiben bei Änderungen erhalten. Für eine neue Speicheridentität verwenden Sie eine neue ID. |
backup_setup |
id; API-Job richtet die Sicherung auf dem ausgewählten Worker ein und startet ihn. |
backup_status |
id; Aktivität, Fortschritt, Scans, Jobs, Wiederherstellungspunkt, Ereigniswarteschlange und Schutzprüfungen lesen. |
backup_checkpoints |
id, optional continuation_token; begrenzte Liste, UTC-Anzeigename mit ursprünglicher ID und gegebenenfalls weiterer Fortsetzungstoken. |
backup_preview |
id, checkpoint, target_endpoint, target_access_key, target_secret_key. Filter: source_bucket, object_key, prefix, object_id. Standardpräfix recovery-; target_bucket benötigt source_bucket. Auf preview_ready warten und Vorschau prüfen. |
backup_control |
id und control. Ohne job_id: Sicherung pausieren/fortsetzen. Mit Jobkennung: Wiederherstellung starten, pausieren, fortsetzen oder abbrechen. Der Start benötigt confirm=job_id nach Prüfung. |
backup_bundle_export |
id, bundle_password mit mindestens 16 Zeichen; API-Job. Nach Abschluss das verschlüsselte Ergebnis über GET /api/v1/object-storage/replication/backups/bundle?job_id=API_JOB_ID herunterladen. |
backup_bundle_import |
id, bundle_b64, bundle_password; API-Job. Auf dem Ersatzknoten eine unbenutzte Archivkennung verwenden. Die importierte Konfiguration dient nur der Wiederherstellung. |
backup_configuration_preview |
id, job_id; Eigentümer und Bucket-Konfiguration aus dem importierten Paket prüfen. |
backup_configuration_apply |
id, job_id, confirm=job_id, target_realm, target_zone; API-Job, anschließend Restore-Worker bis configuration_complete überwachen. |
Optionale Einstellungen: concurrency 1–8, interval 10–3600 Sekunden, catalog_interval mindestens 60 Sekunden (Standard 3600), staging_limit, recall_timeout, scale_enabled, protection_concurrency und lock_check_interval. Verwenden Sie source_ca_pem, destination_ca_pem und target_ca_pem für private CAs an Quelle, Sicherungsziel und Wiederherstellungsziel.
Worker, Paketgröße und WORM
Senden Sie Konfiguration und Start an den Server, der Transfer-, Katalog- und Wiederherstellungsjobs ausführt. Die Sicherungsroute akzeptiert bis zu 24 MiB JSON, damit ein verschlüsseltes Paket bis 16 MiB nach Base64-Kodierung übertragen werden kann. Andere Routen behalten ihr konfiguriertes Limit, normalerweise 1 MiB. Laden Sie exportierte Pakete über den separaten Download-Endpunkt und nicht aus gekürzten Jobausgaben.
Für WORM oder nicht klassifizierten Schutz dürfen vorhandene Wiederherstellungsbuckets nicht überschrieben werden. Schutzmetadaten müssen verifiziert sein; verwenden Sie neue Buckets. Aktive Aufbewahrung und Legal Holds bleiben nach den Schutzprüfungen erhalten. Die Konfigurationswiederherstellung erfordert eine eigene geprüfte Bestätigung; automatische Lifecycle-Löschung bleibt deaktiviert. Den Abschluss einer physischen Bandsicherung am externen Ziel kann eEKAS nicht bestätigen.
Einrichtung und vollständige Referenz
Lesen Sie REST API – Einstieg und Automatisierung, S3-Replikation und Wiederherstellung und die API-Referenz. Prüfen Sie aktionsbezogene Pflichtfelder in der OpenAPI-Spezifikation Ihrer Installation.