1. Home
  2. Documentation
  3. Running your own server
  4. The storage root

Running your own server

The storage root

Where Joripo keeps its files, how they are laid out, why names never move data, moving to another drive, and what never to do.

Joripo documentation · https://joripo.com/docs/running-your-own-server/storage

On this page

The storage root (STORAGE_ROOT, or its older name SERVER_ROOT) is the folder that holds the record: every form and every submission, as plain files. It is the only place a machine path appears in Joripo's settings.

What is in it

One folder per organisation, and inside it one folder per form, keyed by the form ID:

  • the form's live definition, every version exactly as uploaded and as compiled, its attachments and the packages they came in;
  • every submission in a folder of its own: the XML as sent, its photos, recordings and audits, and a record of when and how it arrived (the person and phone that sent it, and the SHA-256 of every file);
  • each submission's review and corrections, beside it;
  • purge backups and the purge log, and the tester's saved sessions;
  • the workspace's server datasets and groupings;
  • a trash folder of deleted forms, which can be restored.

A submission is written attachments first and its XML last, each file under a temporary name and then renamed into place, so a crash leaves either a complete submission or none. With encryption at rest on, every collected file is sealed in place.

Names never move data

No folder is named after anything a user can rename. Renaming an organisation, a workspace or a form moves nothing, and a restart or a database rebuild finds the same folders. Folder names are made safe the same way on Windows, macOS, Linux and network shares, and never differ only in letter case, so a tree copies between them without two folders merging.

Each folder records whom it belongs to, and a folder that names no owner (one copied in by hand) belongs to nobody: the server names it in its log at startup and leaves it untouched until the maintainer decides.

Moving it

To move the data to another drive or a network share: stop the engine, copy the whole storage root, set STORAGE_ROOT to the new place, and start. Nothing else changes.

What never to do

  • Never point the storage root at a container's own disk on a hosted server: it is wiped on redeploy. Use a mounted volume.
  • Never edit, move or delete files in it by hand while the engine runs. Use the console (delete, purge, restore) or the maintainer's scripts, which keep the files and the index in step and keep a backup.
  • Never restore a backup over a live storage root: restore beside it and switch (see Backups and restore).
  • Never share one storage root between two servers.

How much room

Usage counts submissions and their attachments in binary megabytes, and a deleted form keeps using space until the maintainer empties the trash. Backups need about the tree's size again for each one kept, unless they are written to another disk.