File System

File System Persistence

The local backend stores every database in a subdirectory below -data. It is the simplest persistent backend and is appropriate when one MemCP process owns the writable data directory.

On-disk layout

• schema.json is the authoritative database schema and names the published table/shard generation.
• schema.json.old is a rescue link to the previous committed schema generation and is read when the live schema is missing or empty.
• <shard-uuid>-<column> stores a serialized main column. Long column names are replaced in filenames by a stable hash.
• <shard-uuid>.log is the WAL for safe and logged shards.
• blob/aa/bb/<hash> stores content-addressed large values below fan-out directories.

Schema publication writes a same-directory temporary file, optionally fsyncs it, then atomically renames it into place. For durable writes, the directory is synchronized afterwards. A rebuild writes new immutable column files before schema.json makes that generation authoritative; obsolete files are removed only after publication.

Backup and recovery

For a simple offline backup, stop MemCP cleanly and copy the complete data directory, including schema generations, column files, WALs and blobs. Do not copy only schema.json. A live filesystem snapshot must preserve a mutually consistent point in time; test restore and WAL replay with the actual filesystem and ENGINE modes.

Never let two independent MemCP processes write the same directory. A shared filesystem does not provide cluster ownership, invalidation or fencing. The planned multi-node design uses explicit coordination and RADOS; see Cluster Monitor.

See Storage Backends, Persistency and Performance Guarantees and Deployment.