Disaster Recovery

Disaster recovery on MemorySync is built on two non-negotiable invariants:

• No data loss for committed writes. A successful POST /memory/add is a durable commitment. The memory is replicated across redundant storage before the response is returned, so a single-zone or single-node failure cannot lose it.
• Deleted data stays deleted. Once data is removed via API, retention policy, or a Data Subject Request, it must never return — not even after a backup restore inside the platform. This is enforced by tombstone records that survive any internal restore operation.

All backup, replication, and restore operations are run by the platform on your behalf. You don’t initiate restores, run recovery scripts, or coordinate cutovers — the recovery surface you interact with is limited to data export, audit verification, and the public status page.

The platform takes care of every layer of backup automatically. The properties you can rely on:

When data is removed — whether via API delete, retention enforcement, or a Data Subject Request — the platform records a tombstone marker that survives all internal backup and restore operations. The marker says: this data was deliberately removed and must not be reintroduced.

• Tombstone retention. Tombstones are retained for 90 days by default — longer than any internal backup window — so that any internal restore the platform performs is automatically reconciled against the tombstone set.
• What is recorded. Each tombstone captures the resource type, the resource ID, the time of deletion, the reason (API delete, retention sweep, DSR delete, admin action), and the actor responsible.
• Reconciliation. If an internal restore reintroduces any tombstoned record, the platform automatically re-applies the deletion using the same cascading-delete logic as the original removal. The reconciliation event is recorded in the audit log.
• Lifecycle. Once 90 days have elapsed since the deletion, both the tombstone and any matching backup data are purged in tandem, leaving no trace of the deleted record.

The DSR export pipeline doubles as your customer-facing data recovery and portability tool. Any data you have written to MemorySync can be exported on demand:

• Per-user exports. Use access-type Data Subject Requests to export everything associated with a single user: profile, metadata, memories, memory events, recall history, and audit entries. The export is a structured JSON document.
• Bulk project export. Project-level exports include all memories, tags, and metadata for an entire project. These are produced as a single archive suitable for offline analysis or migration.
• Signed download links. Every export download is delivered via an HMAC-signed link with a 24-hour expiry. The link is single-use over its window: tampered, replayed-after-expiry, or cross-DSR links always fail verification.
• Audit trail. Every export generates an audit log entry with the requester, time of request, and scope. This is your record of what was extracted and by whom.

Treat the export pipeline as your customer-side recovery tool. If you need to seed a development environment, run an offline analysis, or hand a copy of a user’s data to a downstream system, this is the supported path.

The platform automatically enforces data lifecycle policies in the background. There is no operational action required from your team — your only input is the retention configuration in tenant settings.

User-facing delete operations use a soft-delete grace period as a safety net before the data is purged for good:

• Soft-delete phase. When a memory is deleted through the API, it is immediately marked as soft-deleted and stops appearing in recall results. The memory remains in the system long enough to support audit reviews and undo flows.
• Vector removal. The memory’s vector is removed from the active index immediately, so it cannot be returned by any query during the grace period.
• Audit visibility. Soft-deleted memories remain visible to authorised admins through the dashboard’s audit views during the grace period, even though they are invisible to recall.
• Hard delete. Once the grace period expires, the memory is permanently removed and a tombstone is recorded. From that point on the data is unrecoverable, except via a copy your application has retained.

Because backups, restores, and reconciliation are all platform-managed, your runbook during an incident is short:

1. 1Check the public status page for the affected component and region. Major incidents are posted there with rolling updates and an estimated resolution time.
2. 2Watch the health endpoint. GET /health returns "status": "ok" when the platform is healthy and "status": "degraded" while a non-critical feature is impaired. Polling this from your client surface is enough to keep your own dashboards accurate.
3. 3Inspect your audit log. Once the incident is resolved, the dashboard’s audit view shows any reconciliation events the platform performed on your tenant. No action is required — the entries are informational.
4. 4Run a sanity query. A simple POST /memory/query against a known-good project confirms recall is functioning end-to-end after the all-clear.

If your team needs additional context on what happened to your tenant, contact support with your organization ID. Incident reports for major events are published as post-mortems on the status page within 5 business days.