Build Not yet confirmed elsewhere 1 publisher2 min readPublished Aug 22, 2026, 1:03 AM PDT

npm run backup covers two payloads; the rest of a Hubs restore lives in your notes

Hubs Community Edition's bundled scripts archive the Postgres dump and the Reticulum file store. Everything between a bare host and a serving room is a rebuild you perform by hand.

The Engineer · Build desk

How we use AI Send a correction

Illustration accompanying npm run backup covers two payloads; the rest of a Hubs restore lives in your notes — Generated illustration

What happened

The bundled Hubs Community Edition scripts archive two things: the PostgreSQL database and the Reticulum file store with its GLB scenes, avatars, thumbnails and room media.
hcce.yaml, TLS material, DNS records, Kubernetes state and object storage credentials are not in the archive.
The archive is a data snapshot rather than a running system image, so a restore always lands on a freshly installed instance.
Point Hubs at an external database rather than the bundled Postgres pod and the scripts quietly back up the Reticulum files alone.
The author's recommendation is to treat restore as a fresh install plus a data load, and to time it once instead of guessing.

Why it matters

constraint The number your users ask about is rebuild time plus load time, and only the load has a command behind it, so the figure lives in an operator's notes rather than in the repository.
cost A studio pays for its own asset library in outage minutes: the file store and disk throughput set the clock while the database portion stays cheap.
exposure Anyone on managed Postgres is holding two recovery points that no script reconciles, and whatever falls between them is loss nobody agreed to.
decision Multi-client hosts now have to choose per instance archives with config and secrets stored alongside, or accept that one client's request pulls in the whole cluster.

The two payloads are two halves of one object. The database dump is the record of every room: its title, its permissions, its owner account, its scene assignment and the metadata rows that point at uploaded files, and if you lose it the GLB files are still sitting on disk without belonging to any room ^[9]. That interlock is a good reason for the scripts to exist. It is also the entire scope of what they hand you, a single timestamped archive in the `data_backup_1234567890123` pattern holding those two payloads and nothing else ^[8].

Count the inventory instead of reading the feature list. Of the seven categories of state the write-up names around a working instance, the archive owns two and the operator owns five ^[14]. That ratio is the article's real finding, and the author states the consequence directly: `npm run restore-backup` is the last step of a disaster recovery plan rather than the plan, and every step ahead of it is a rebuild you have to perform from your own notes ^[6].

Watch where the advice lands for the simplest deployment. A lecturer running one instance on one VPS is told to keep the built-in backup and add a nightly filesystem snapshot of the node, because the recovery target is the whole box rather than a selective extraction ^[17]. The snapshot is what carries the five categories the archive leaves behind. For the easiest case, in other words, the recommended primary artifact is an image of the machine, and the scripts ride on top of it.

The migration case shows what the rebuild actually contains. Move to a new provider or a new client domain and room URLs, the Reticulum host configuration and certificate issuance all have to be corrected before anyone can join a room, which is why the write-up says to rehearse the whole thing on a scratch host first ^[15]. None of that is a data-load problem, and none of it is timed by the tooling.

The tradeoff is put plainly in the source: the scripts are simple and they cover the data that matters, on the assumption that you can reconstruct the surrounding installation by hand, so effort saved at backup time is effort repaid, under pressure, at restore time ^[12]. The half of the procedure with a command attached is the half already documented. The half that decides how long your rooms are dark is the one sitting in somebody's notes, unversioned and untimed.

What to watch

Whether upstream extends the scripts to capture hcce.yaml and cluster state, which would move the rebuild inside the tooling instead of the notes.
Anyone publishing a measured end to end restore time against a stated file store size and disk throughput, which is the number currently missing.
Whether a documented procedure appears for reconciling a managed database's point in time recovery timestamp with the file store archive.

Clarity's read

What the record supports and how the coverage leans. The claims behind it follow.

Reality

Evidence30
Adoption: Insufficient
Hype gap+5
Incentives60
Confidence38

Why these scores

Claim ledger

Ranked by verification strength, evidence, and original report placement.

[1]
The Reticulum file store is the part of the archive that grows without limit and dominates archive size.
ReportedSupported2 sources— create a free account to open them View cited source
[2]
For a studio with hundreds of client uploaded GLB files, the write-up says to budget the restore window from file store size and disk throughput, because the database restores quickly and the assets dominate the clock.
ReportedSupported2 sources— create a free account to open them View cited source
[3]
The bundled scripts in Hubs Community Edition back up two things: the PostgreSQL database and the Reticulum file store that holds uploaded GLB scenes, avatars, thumbnails and room media.
ReportedSupportedView cited source
[4]
The scripts do not back up hcce.yaml, TLS material, DNS records, the Kubernetes cluster or object storage credentials.
ReportedSupportedView cited source
[5]
If Hubs is pointed at an external database instead of the bundled Postgres pod, the scripts fall back to backing up the Reticulum files only.
ReportedSupportedView cited source
[6]
According to the write-up, npm run restore-backup is not a disaster recovery plan on its own: it is the last step of one, and everything before it is a rebuild the operator must be able to perform from their own notes.
ReportedSupportedView cited source
[7]
The author advises planning for a restore that is a fresh install plus a data load, and timing it once so the real number is known rather than hoped for.
ReportedSupportedView cited source
[8]
Running npm run backup from the Hubs Community Edition checkout produces a single timestamped archive named in the data_backup_1234567890123 pattern, containing two payloads and nothing else.
ReportedSupportedView cited source
[9]
The Postgres dump is the record of every room, its title, permissions, owner account, scene assignment and the metadata rows that point at uploaded files; lose it and the GLB files still exist on disk but no longer belong to any room.
ReportedSupportedView cited source
[10]
The archive is a data snapshot rather than a running system image, so a restore always lands on a freshly installed instance.
ReportedSupportedView cited source
[11]
For a team on hosted Postgres with automated point in time recovery, the write-up says to treat the two halves separately, because the scripts stop covering the database once it leaves the bundled pod and the restore must line up two independent timelines.
ReportedSupportedView cited source
[12]
The write-up's stated central tradeoff: the built in scripts are simple and cover the data that matters, but they assume the surrounding installation can be rebuilt by hand, so effort saved at backup time is repaid under pressure at restore time.
ReportedSupportedView cited source
[13]
Total recovery time equals rebuild time plus data load time, and only the data load term is automated by the bundled scripts; the rebuild term has no scripted duration.
DerivedSupported1 source— create a free account to open them
[14]
The archive covers 2 of the 7 categories of state the source enumerates around a running instance: 2 captured payloads (Postgres, Reticulum files) against 5 named exclusions (hcce.yaml, TLS material, DNS records, Kubernetes cluster, object storage credentials).
DerivedContested2 sources— create a free account to open them
[15]
For a move to a new provider or a new client domain, the write-up says to rehearse the restore on a scratch host first, because room URLs, the Reticulum host configuration and certificate issuance all have to be corrected before anyone can join a room.
ReportedInsufficient2 sources— create a free account to open them View cited source
[16]
For a small agency running several client instances, the write-up says to wrap the scripts in per instance archives with hcce.yaml and secrets stored beside each archive, because a client asking for their world back is a per instance restore and not a cluster restore.
ReportedInsufficient2 sources— create a free account to open them View cited source
[17]
For a solo operator running one instance on one VPS, the write-up says the built in backup plus a nightly filesystem snapshot of the node is enough, because the recovery target is the whole box and not a selective extraction.
ReportedInsufficient2 sources— create a free account to open them View cited source

Sources

1 independent publisher whose own reporting we read for this story.

dev.to
1 article · August 22, 2026
Hubs Community Edition backup and restore: what npm run backup captures, what it misses, and how long recovery takes

Ask Clarity

Have a question this piece left open? The answer comes from its reporting and claim ledger — nothing else.

Clarity analysis

How the coverage leans and what the record actually supports. Read the methodology

Perspective Coverage

How much of the coverage speaks to builders, operators and investors. It measures emphasis, not whether the story is right.

Builder

For builders the useful content is command-level and small: `npm run backup` yields one timestamped data_backup_<epoch> archive with a Postgres dump and the Reticulum file store; `npm run restore-backup` with no argument takes the most recent archive. The consequential build-time facts are that the archive is a data snapshot rather than a system image, so restore always targets a fresh install, and that pointing Hubs at an external database silently reduces the scripts to file-store-only. Nothing here is verified against the upstream repository or script source, and no timings are given, so treat it as a starting hypothesis to confirm against your own checkout.

Reality

Evidence, adoption, hype gap, incentives and confidence, each read independently from the current record on the scale shown beneath it. How these are measured.

Evidence30: 0100
Single self-reported runbook, no external verification
All claims trace to one dev.to post by an individual author, with no citation of upstream Hubs Community Edition documentation, script source, issue threads or a second publisher. The tooling-behaviour claims are specific and internally coherent, which lifts them above assertion, but the article contradicts itself on how many categories of state fall outside the archive, supplies no measurements for the size and duration questions it raises, and the supplied body is truncated mid-enumeration.
AdoptionInsufficient: No adoption signal supplied
The cluster contains no release, deployment, benchmark, usage-disclosure or incident data for Hubs Community Edition or its backup scripts. Reader profiles such as 'a four person studio running six separate client instances' are illustrative personas in the write-up, not observed deployments, so no adoption measurement can be made without inventing facts.
Hype gap+5: −100 understated0 aligned+100 overstated
Modest claims, slightly overstated precision
The framing is deflationary rather than promotional: it argues the tool covers less than it appears and that saved backup effort is repaid at restore time, which is the opposite of overselling. The small positive gap comes from precision the evidence does not support — an exclusion count that conflicts with the article's own later enumeration, and a title promising to answer how long recovery takes while no duration is supplied.
Incentives60: 0100
Content-marketing shape with adjacent product placement
The post carries markers of promotional content engineering: an embedded block of a dozen search-style questions, and an unprompted product description of Yundera as a managed CasaOS-based Personal Cloud Server running self-hosted apps as Docker containers, inserted into a hosting-options aside. That placement gives the author an interest beyond neutral documentation, though the technical guidance itself does not steer readers away from self-hosting.
Confidence38: 0100
Plausible but uncorroborated
Confidence is limited by a single publisher, a single author, no upstream citation, an internal inconsistency in the exclusion count, absent measurements on the two quantitative questions the piece raises, a truncated body, and a marketing-adjacent publication context. It is not lower because the mechanism described — a data-only archive that omits configuration, secrets, certificates and cluster state — is specific, self-consistent and consistent with how a Kubernetes-hosted application with a bundled database pod behaves.

Topics and entities

Follow any of these and your For You feed starts watching them — no settings page required.

Topics

Kubernetes State ManagementFollow
Self-Hosting OperationsFollow
WebXR Virtual WorldsFollow
Backup and Disaster Recovery Follow