Enterprise

Backup archive

A nightly copy of your whole organization — settings, DevOps secrets, company vaults and audit log — encrypted to keys only you hold and delivered to your own storage bucket.

The backup archive is your organization's own copy of everything it keeps in PulsVault, in a file you can open without us. Every night it is built, encrypted to public keys you register, and written to a storage bucket you own. You can also build one on demand and download it.

It answers a different question from Vault backups. Those nightly vault snapshots live on our side and restore inside PulsVault. The archive is for the day you need your data somewhere PulsVault is not.

What an archive contains#

Section	What is in it
Organization configuration	Settings and every policy, verified domains, members with their roles, custom roles and their permissions, direct grants, teams, projects and their members, validation configurations, alert routes, tasks
DevOps secrets	Every secret's current value, readable once the archive is decrypted, with its project, environment, path, version, and who last changed it. Machine-plane policies and machine identities too
Company vaults	Each company vault exactly as we store it — still encrypted — with its attachments and the wrapped keys of the people who hold it
Audit log	Your organization's audit entries since the previous delivered archive; the exact text each entry's fingerprint covers, so every entry and every link can be checked with SHA-256 alone; and a signed integrity receipt of what the platform verified

A manifest.json lists every file with its size and SHA-256, and a README.txt repeats how to open it.

Why it is encrypted to your keys#

An archive holds every production secret your organization stores here, so it is encrypted before it leaves our servers — to the age public keys you register, and to nothing else. We never hold a private key, so we cannot open an archive, and nor can anyone who reads your bucket without one of your keys.

Company vault items get a second layer: they were encrypted on your members' devices and we have never seen them in the clear. In the archive they stay that way, and they open only with the password and Access Key of someone who held that vault's key.

This permission receives every DevOps secret

Whoever configures the archive decides which key and which bucket receive all of your organization's secrets. That is why it has its own permission, business:backup:manage, that is never part of any role, that is only granted by the owner or a business:permission:delegate holder, and why every change it makes waits 48 hours and is announced to every administrator.

Setting it up#

The archive is part of the Enterprise plan.

Generate a key pair on a machine you trust, with the open-source age tool: age-keygen -o key.txt. It prints the public key (it starts with age1). Store key.txt offline — on paper, in a safe, on a hardware token. If it is lost, archives encrypted to it are lost too.
Grant the permission. The owner — or a member holding business:permission:delegate — grants Manage Backup Archive to the people who will run the archive, one person at a time, from their entry under People → Members. Until you hold it, Organization → Backup Archive shows administrators this step instead of the archive.
Add the key under Organization → Backup archive → Add key. You are asked for your password again. Register a second key held by someone else, so losing one person's key does not lose the archive — any one registered key opens it, up to ten.
Add a destination: any S3-compatible object storage. Enter the endpoint URL (leave it empty for Amazon S3 itself), the region, the bucket, an optional key prefix, and an access key that can write to that prefix. Test connection writes one small marker object to prove the credentials work. Saving asks for your password again.
Wait 48 hours. A new key and a new destination receive nothing until their wait is over. The first archive is delivered the night after both are active.

Archives are named org-<name>-<date>T<time>Z.pvbak and filed under <prefix>/<year>/<month>/ in your bucket. We only ever write there — we never list, read or delete anything — so how long archives are kept is decided by your bucket's own lifecycle rules. Turning on versioning or object lock protects them against deletion, including by anyone holding the access key.

Give the access key the least it needs

The destination's credentials only need permission to write objects under the key prefix. A key that cannot read, list or delete means a leak of it cannot expose or destroy the archives already there.

Back up now and Download now#

Back up now builds and delivers an archive immediately instead of waiting for the night. If something it needs is missing — no active key, no active destination — the run is recorded as skipped, with the reason, and nothing is built.

Download now builds a fresh archive and hands it to your browser. It needs an active key but no destination. Nothing is kept on our side, and the download is recorded in the audit log before its first byte leaves. A downloaded archive does not move the audit log's starting point, so the copies in your bucket still follow on from each other without gaps.

Each run appears under Runs with its result, its size and its SHA-256. A delivery that failed says why, and everyone who is told about archive changes (see Security notes) is notified.

Opening an archive#

With the private key (key.txt) and the free age tool:

bash

age -d -i key.txt org-acme-20260926T014503Z.pvbak > archive.zip
unzip archive.zip -d archive

Everything but the company vault items is now readable: configuration and audit log as JSON, and devops/secrets.json with every secret value.

To read company vault items, use the recovery kit — a single web page you download from the Backup Archive screen. Open it in any browser, even with no network: choose the .pvbak and paste your age identity (or choose the archive.zip you already decrypted, which is the way for a key held on hardware), then enter the password and Access Key of someone who held the vault's key — its owner or a custodian. The kit checks every file against the manifest, then decrypts the items and lets you download their attachments.

The kit also checks the audit log on its own, without contacting us: that the archive's integrity receipt carries a genuine PulsVault signature, that every audit entry recomputes to its recorded fingerprint and links to the entry before it, that the readable audit/audit-log.json says exactly what those fingerprints cover, and that the entries the receipt signed are in the archive as signed. It only reports the trail as checked when a genuine signature anchors it; entries that merely agree with each other are reported as consistent, not as proven. For each chain it shows where this archive's entries continue from and where they end at — the first value must equal the previous archive's last one, which is how you confirm nothing was removed between two archives.

Download the recovery kit now

The kit is how you read vault items if PulsVault is unavailable, so get it while it is. Keep it with your age identity and compare it with the SHA-256 shown on the screen (sha256sum pulsvault-recovery-kit.html).

What is not included#

Members' personal vaults. Only company vaults belong to the organization.
Secret history. Each DevOps secret's current value only, not its earlier versions.
Third-party credentials. Integration tokens and the webhook URLs and signing secrets of alert routes are left out; they are set up again wherever you restore.
API keys. Only their hashes exist, and a hash cannot be used, so none are exported.
Short-lived and derived data: notifications, pending invitations, validation alerts, machine activity and security-posture history.
Test Lab entries and validation templates.
The archive's own settings — its keys and its destination's credentials.

An archive can be imported back into the organization it was taken from.

Importing an archive#

An archive can be brought back into the organization it was taken from — after something was deleted by mistake, or if PulsVault itself ever had to be restored from its own backups and lost what came after. Another organization's archive is refused.

Import is additive. It creates what is missing and never overwrites or deletes anything that exists, with one exception you choose yourself: a policy you tick is replaced by the archived one. Two things it adds to are worth knowing: a secret that sits in the recycle bin is brought back with a new version, and people in an archived team are added to that team if it already exists.

What comes back#

Part	What happens	Needed besides `business:backup:manage`
DevOps secrets	Every path that does not exist today is created, with the projects, environments and namespaces that hold it. A path that exists is never overwritten, even when its value differs. You are recorded as the author, and version numbers start again at 1	Nothing for the values. `business:project:create` to create a missing project; environments and namespaces need what they need by hand
Company vaults	Each vault you tick comes back as a new vault, still encrypted exactly as it was; the original, if it still exists, is not touched. Its owner and custodians who are members today open it with the keys they already hold, and are told it is back. Attachments come back with it	`business:config:manage`
Organization policies	Each policy you tick becomes exactly what the archive holds — a setting the archive leaves unset is cleared today too	`business:config:manage`
Custom roles, teams, direct grants	Missing roles and teams are created; an existing role is never edited, and an existing team only gains the archived members it is missing. People are matched by email, and only if they are members today. Each grant is given as if you gave it by hand, so one you could not give is refused and reported	`business:member:manage`

Each part you are not permitted to import is shown in the preview, and left out.

Never imported:

The audit log. Putting old entries back would forge a history that is meant to be tamper-evident. The archive keeps its copy.
Members. Each person needs their own account and keys. The preview lists everyone in the archive who is not a member today and gives you a file for Add several. Once they have joined, import the same archive again to give them their team places, grants and project memberships.
Validation configurations, alert routes and tasks.
Earlier versions of a secret. An archive holds each secret's current value only.

Step by step#

Open Organization → Backup archive and choose Import an archive.
Choose the .pvbak file and paste the age identity of one of its keys — or, for a key held on hardware, decrypt it first with age -d and choose the .zip. The archive is opened and every file checked against its manifest in your browser: neither the identity nor the archive is uploaded, and leaving the page forgets both.
Choose Start import and confirm your password. Every administrator is told that an import has started. It stays open for two hours, for you only.
Review the preview and choose what to bring back. Nothing is written yet.
Choose Import. Each part shows its progress and, at the end, what was created, skipped or refused, and why.

Only what you import leaves your browser: each missing secret's value, and each company vault you ticked, still encrypted. To compare secrets with today's, the preview sends a fingerprint of each value, never the value.

Reading the preview#

DevOps secrets are counted as missing, already here with the same value, already here with a different value, or impossible to import (with the reason). Only the missing ones are written. A different one is left as it is — change it by hand if the archived value is the one you want.
Company vaults show whether each one still exists. One that still exists starts unticked; one that was deleted, or that PulsVault has no record of, starts ticked. When PulsVault has no record of who owned a vault, choose its owner from the people who held its key — a wrong choice gives nobody access, because the vault's key opens only with the real owner's. When the owner has left, choose who will own it from its custodians; they are offered ownership and must accept it. A vault that nobody who is a member today could open is not offered, and neither is one imported earlier while that copy still exists.
Organization policies show whether each one is the same as today or different. Nothing is ticked for you.
Roles, teams and grants show what would be created, what is already here, and who is not a member today.

Network and authentication policies can lock people out

An archived network policy that no longer matches where your members connect from — you included — locks them out at their next session refresh; one that would lock you out is refused. An archived authentication policy can require two-step verification or single sign-on of everyone, and stops anyone not set up for it at their next sign-in. Tick these two only if you mean it.

A SIEM webhook's signing secret is never archived. If you import the audit policy and it has a webhook, set the secret again on the audit policy page.

If it stops, import it again#

If the import is interrupted — the page closed, the connection lost, or the two hours up — import the same archive again. Everything already imported is skipped: secrets that now exist, and vaults whose imported copy still exists. What was created stays created.

Every import is listed under Imports on the Backup Archive screen, with who ran it, which archive it was, and what it created, skipped and refused.

Security notes#

Every change waits 48 hours and is announced. Adding a key or saving a destination notifies the owner, every administrator with business:config:manage and every holder of business:backup:manage, and nothing is sent to the new key or bucket until the wait is over. The previous destination keeps receiving until then.
Revoking is immediate. Archives built after you revoke a key are not encrypted to it. Copies already delivered still open with it — delete them from your bucket if that key is compromised.
Removing the destination is immediate and stops nightly delivery, including a destination still in its wait.
Every change is recorded permanently in the audit log: keys added and revoked, destination changes, every delivery and download, and every failure.
Imports are fenced like the archive. Starting one asks for your password; every administrator is told when one starts and when it ends; each part it imports is recorded permanently in the audit log, with counts and never a value. Only the person who started an import can continue it.
If your subscription becomes read-only, you can still back up now, download an archive and revoke a key — getting your data out is what that window is for. Adding a key, changing the destination or importing an archive waits until the subscription is active again.

Was this page helpful?