Back up and restore

MOS creates manual, whole-suite backups on storage that is mounted on the server running MOS. The practical destination depends on where that server lives.

A backup holds every secret your server has

Any backup contains your data, credentials, and secrets. Backups are encrypted on the drive with a key held on the server itself, so the drive alone cannot be read—but the key lives on the server, so a stolen server is still a stolen backup, and MOS cannot yet hand you that key to keep elsewhere. Keep backups on access-controlled storage. Bundles you downloaded from an earlier MOS are not encrypted at all: move them out of Downloads and off casual cloud storage.

What a backup contains

A MOS backup captures:

• every installed app and its declared data volumes,
• the exact installed app-package snapshots and settings,
• the owner account, app secrets, and app connections,
• the Home dashboard layout,
• domain and HTTPS configuration.

Restore requires a working MOS installation on a compatible version. A backup is not a bare-metal installer by itself.

Choose a destination for your installation

Own hardware

Connect a writable USB disk or other external drive directly to the MOS machine. An encrypted drive is strongly recommended. MOS can detect supported local devices and offer to mount them from Suite Manager.

Do not save the only backup on the server’s internal system disk: a disk failure could take out both the suite and its backup.

Cloud server

A rented server cannot use a USB disk attached to your computer. Attach a separate persistent block-storage volume through your provider, format and mount it on the server, then select that mounted volume in Suite Manager. Provider block storage is billed separately and remains inside the provider’s trust boundary; use provider-supported encryption where available.

MOS does not currently copy the backup store to S3-compatible/object storage, another cloud account, or a backup service. Provider snapshots are outside MOS: they may be useful as an additional recovery layer, but MOS cannot verify their consistency, contents, retention, or restore behavior. They do not replace a tested MOS backup.

Taking a backup

1. Attach and mount the destination described above.

2. Open Suite Manager → Backup and click Refresh drives. Select the mounted, writable destination; MOS may offer to mount a supported local disk.

3. Review the full-secret warning, then click Back up now. Apps pause while their data is captured and start again when the job finishes.

4. Keep the drive itself on access-controlled storage. There is no separate file to download—the encrypted store on the drive is the copy you keep, and moving a backup to another machine means taking the drive there.

Backups are written under MOS-backups/ on the selected destination, into a single encrypted store that every backup on that drive shares. Because the store is content-addressed, a second backup only writes what actually changed, and one drive holds many restore points for far less space than one full copy each. Each restore point records which stored data it needs; MOS checks the store’s integrity and re-verifies every app package before a restore changes running services.

One drive holds one store. Bundles from MOS 0.19 or earlier, in the older unencrypted format, are still listed if they are on the same drive, but this version cannot restore them—restoring one needs MOS 0.19 or earlier. You can delete them here to free the space they take.

A workable routine

Backups are manual; there is no scheduler or retention policy yet. Take one before updates or uninstalling an app, keep more than one generation, and periodically test that the destination is still readable.

Restoring

Restore replaces the current suite with a backup on a machine that already has a compatible MOS installation.

1. Attach or mount the storage containing the backup, open Suite Manager → Backup, and select it.
2. Type RESTORE to confirm.
3. MOS verifies the stored data and each saved app-package snapshot before stopping services. It creates a small rescue copy of current state, restores settings, package definitions, and data, then rebuilds the app runtimes.

Important boundaries:

• Match the MOS version. Each backup records its source version. Restore onto that version unless a documented compatibility migration says otherwise.
• Backups from MOS 0.19 or earlier cannot be restored here. Those were unencrypted bundles, a format this version no longer reads. Restore one with MOS 0.19 or earlier, or take a fresh backup on the machine you are running now.
• Restore is whole-suite. Per-app restore is not supported.
• The machine must already run MOS. Install the compatible MOS version first, then attach the backup destination and restore. Bare-metal recovery has not yet been validated as a single end-to-end workflow.
• A replacement machine needs the key as well as the drive. The encryption key lives on the server that made the backup. Restoring onto the same server is unaffected, but restoring onto a new one currently means copying that key across by hand; a supported way to save and enter it is still being built.
• Package snapshots are preserved, registry artifacts are not. If an upstream registry removes a required digest-pinned image, MOS restores state and reports the affected app as failed rather than substituting another version.

Current limitations

Manual only · mounted local/block storage only · no object-storage destination · encryption key held only on the server · whole-suite restore only · version-sensitive restore.

A way to save and re-enter the encryption key, scheduled backups with retention, and object-storage destinations are the next things being built here. If you work with backup, storage, encryption, or recovery systems and want to shape how they land, join us on Discord or open a GitHub issue.