# Backups > What to back up on a self-hosted Weald relay, what a backup cannot contain, how to restore one, and why a restore never resurrects a revoked device. Source: https://getweald.com/docs/self-hosting/backups Last modified: 2026-08-03 --- ## Backups and restores Last updated 2026-08-03 A Weald backup is a Postgres dump plus the media bucket, and both halves are ciphertext. A backup can therefore go anywhere, including a provider you would not otherwise trust, and it is worthless to anyone without a member device's keys. Take one before you invite the second person. ## What to back up - The relay's Postgres database, which holds envelopes, access sets, invites and the transparency log. - The object storage bucket, which holds encrypted media blobs the relay has no key for. wealdrelay backup wraps both into one tarball. pg_dump and a bucket sync are the same thing done by hand. ## What a backup cannot contain No key that opens any of it. Workspace keys are generated on member devices and never reach the relay, so a stolen backup is a pile of ciphertext plus a set of envelope sizes and timestamps. Say that plainly to whoever reviews your backup policy: the sensitivity of this backup is the metadata, not the content. Sizes, timing and connection patterns are what an adversary with the backup actually gets. ## Restoring wealdrelay restore puts a relay back. Clients reconcile on their next connection and repair gaps from their own local copies, so a restore from a slightly stale backup self-heals. That is a direct benefit of every client holding a full copy. It also means a restore is not a rollback of the workspace: members will push back everything the backup was missing, because they still have it. ## What a restore does not undo A restore does not resurrect a revoked device. Revocation is an epoch change in the workspace, carried by member devices, and a device that was removed stays removed even if the relay is rolled back to before it happened. The same is true in the other direction. A member added after the backup was taken is still a member, because the group state that admitted them lives on their device and everybody else's. ## Testing it Restore into a scratch relay and connect one client to it. That is the whole test, and it is worth doing once. Two failure modes are worth checking for specifically. A dump taken without the bucket restores a relay whose media references resolve to nothing, and a bucket copied without the dump restores nothing at all. ## Leaving Migration off the hosted tier, or off your own relay onto another, is the same three steps: back up, restore elsewhere, repoint the client. There is no export format and nothing to request, because there is nothing held on a relay that member devices do not already have.