Manage and back up Local Storage
Unlike other managed services, Local Storage is meant to be worked with directly: you can open a shell in the service's own container to inspect and modify the volume contents, and Zerops backs the volume up automatically.
Access the volume directly
The Local Storage service runs one maintenance container with the volume mounted at /data, owned by the zerops user and group. You can access it like a runtime container:
- Web shell and file browser: open the service detail page in the Zerops GUI and use the built-in terminal or file browser
- SSH: connect through the Zerops VPN and SSH into the container
Everything you change under /data is immediately visible to all runtime services that mount the volume — the maintenance container is just another view of the same filesystem.
/data is the mount path inside the Local Storage container itself. Runtime services see the volume at their own configured mountPath (default /mnt/{hostname}).
Backups
Zerops provides automated data backup for Local Storage services with full encryption. Backups are enabled by default and strongly recommended: the volume is currently not replicated, so on a hardware failure they may be the only copy of your data.
For general backup information including configuration, scheduling, retention, tagging, quotas, and CLI tools, see the Zerops Backups documentation.
Backup format
- Format:
.tar.gz(archive of the volume contents) - Content: the entire volume (
/datain the maintenance container) - Storage: encrypted and stored in isolated object storage
The archive is created while the volume stays mounted and writable, so files that are being written at that moment can be captured mid-write. For databases like SQLite this can produce an archive that does not restore cleanly. Do not rely on the .tar.gz archive alone for a database — produce a consistent copy on the volume first and let the archive pick that copy up.
Consistent database backups
The reliable pattern is to let the database write its own consistent copy onto the volume on a schedule, so every platform backup contains a file that restores cleanly. Use a cron job in one of the runtime services that mounts the volume:
sqlite3 .backup(orVACUUM INTO) copies the database through SQLite itself, so the result is a consistent, restorable file even while the app keeps writingallContainers: falseruns the job in a single container, which keeps it a single-writer operation- The copy overwrites itself each run and lives on the volume, so it is included in every
.tar.gzbackup with the platform's own retention - The same approach applies to any other embedded database: use its native backup command rather than copying its live data files
- The
sqlite3CLI is not part of the base runtime images — install it inrun.prepareCommandsif your app doesn't already ship it
The alternative is to pause writes for the duration of the platform backup, which is usually not worth it.
Zerops is moving Local Storage towards snapshot-based backups, which will produce fast, consistent, point-in-time backups of the whole volume without any application-level coordination. Until then, use the pattern above for databases.
Restoring backups
- Download the backup file (
.tar.gz) from the Zerops UI. - Transfer the archive into the Local Storage container (or any runtime service that mounts the volume), for example over the Zerops VPN.
- Extract the archive into the volume:
Best practices
- Regularly clean up unnecessary files to reduce backup size
- Create manual backups with protected tags before major file operations or migrations
- Test your restore process periodically to ensure data integrity