What is tenant-level backup and restore for memory?

This Part has spent considerable time on isolating memory correctly while a system is running normally. This chapter looks at what that same isolation has to mean during a genuinely different moment, recovering from a failure, and why a memory system built on structural, per-tenant isolation actually makes disaster recovery safer than one that wasn’t designed with that separation in mind from the start.

Why Does Backup and Restore Actually Matter as a Continuation of This Part’s Isolation Theme Rather Than a Separate Topic?

Every isolation guarantee covered earlier in this Part, hard boundaries between users, structural multi-tenancy, scoped access, exists to protect data during ordinary operation. A backup and restore process is the same guarantee tested under a different condition entirely, a failure has occurred, and data now has to be recovered without accidentally undoing the very isolation that made the system trustworthy in the first place. A restore that brought back one tenant’s data mixed together with a different tenant’s, or that silently reintroduced a boundary that was supposed to stay firmly in place, would be a genuine isolation failure, even though it happened during recovery rather than during normal use.

Why Does Physically Separating Each Tenant’s Data, Covered Earlier in This Part, Actually Matter Even More During a Backup or Restore?

Because each tenant’s data lives in its own dedicated, self-contained shard, a backup capturing that data preserves the same separation the system relied on while running, rather than flattening everything into one undifferentiated archive that would then need to be carefully re-sorted during restore. This matters directly for the kind of scoped recovery a real incident often calls for, restoring one specific customer’s data after an accidental deletion without disturbing anyone else’s, which is a fundamentally more tractable operation when that customer’s data was never physically mixed with anyone else’s to begin with.

Why Does a Backup Need to Capture a Tenant’s Data Regardless of Whether That Tenant Happens to Be Actively in Use at the Moment the Backup Runs?

A tenant that hasn’t been active recently, one whose data has been moved to lower-cost storage because nobody’s been querying it, still deserves the same recovery guarantee as a tenant seeing constant activity, since a failure doesn’t consider how frequently a given tenant’s memory was actually being used before it happened. A backup process that only captured actively used tenants would leave a quiet gap in exactly the population least likely to notice, and least equipped to complain, that their data was never actually protected in the first place.

Why Does It Matter That a Backup Can Be Created Without Interrupting a System That’s Still Actively Serving Requests?

A memory system genuinely being relied upon in production can’t reasonably pause every write while a backup runs, since that would mean choosing between protecting the system’s data and keeping the system actually available to the people depending on it. A backup process designed to run safely alongside live traffic, capturing a consistent snapshot without blocking ongoing reads or writes, avoids forcing that tradeoff entirely, letting an organization protect its data continuously rather than treating backups as a disruptive event that has to be scheduled around active usage.

What Does It Actually Mean to Trust That a Restore Preserves the Same Isolation Guarantees the System Had Before the Failure Occurred?

Trusting a restore means more than trusting that the right data comes back, it means trusting that the same boundaries, the same scoping, the same access rules that governed that data before the failure still govern it identically afterward. A restore that recovers the right content but subtly loosens an isolation boundary in the process would technically succeed at data recovery while quietly failing at the actual goal, since the point was never simply to have the bytes back, it was to have the system’s full set of guarantees back intact.

How Does Weaviate’s Backup Architecture Support Recovering a Memory System Without Compromising the Isolation It Depended On?

Weaviate’s backup process captures each tenant’s data from its own dedicated shard, including tenants that were inactive at the time of the backup, and restores that same structural separation intact, rather than merging everything into one undifferentiated archive along the way. Consider a regional credit union’s member-services memory system, built on separate tenants per member so that one member’s financial conversation history can never reach another’s, where an operations team needs confidence that a disaster recovery event won’t quietly undo that separation:

import weaviate
from weaviate.classes.config import Configure

client = weaviate.connect_to_local()

collection = client.collections.get("EngramMemories")

backup_result = collection.backup.create(
    backup_id="creditunion-nightly-backup",
    backend="s3",
    wait_for_completion=True,
)

restore_result = collection.backup.restore(
    backup_id="creditunion-nightly-backup",
    backend="s3",
    wait_for_completion=True,
)

Because every member’s memory lives in its own dedicated shard within this collection, the backup captures each member’s data with the same isolation it had while the system was running, including members who hadn’t had a recent conversation and would otherwise be easy to overlook, and restoring from that backup brings the entire collection back with every member’s data occupying exactly the same isolated position it held before. This is exactly the value structurally isolated backups deliver for a use case like a credit union’s member-services system, where a disaster recovery event needs to bring the system back not just with the right data, but with the exact same guarantee that one member’s financial history can never surface in a different member’s records, intact and unweakened by the recovery process itself.

Backup and restore extend this Part’s isolation guarantees into the moment a system needs to recover from failure, proving that structural separation isn’t just a normal-operation convenience, it’s what makes disaster recovery trustworthy in the first place. A related concern arises the moment a memory system involves not just many users but many separate agents acting on their behalf. Our next chapter, How should memory be isolated in multi-agent deployments?, takes up exactly that setting.