Storage & Tiered Storage
Meridian VMS uses a tiered storage system inspired by Milestone XProtect, where recordings flow through storage pools (hot, warm, cold) based on configurable policies. Each pool can use different media types, and recordings transition automatically between tiers as they age.
Storage Pools
Section titled “Storage Pools”A storage pool is a named storage destination on a recording server. Each server can have multiple pools assigned to different physical media.
Pool Types
Section titled “Pool Types”| Pool | Media | Purpose |
|---|---|---|
| Hot | NVMe / SSD | Active recording target. Fastest I/O for concurrent writes from all cameras. |
| Warm | HDD / RAID | Medium-term storage. Lower cost per TB for footage that is still accessed occasionally. |
| Cold | NAS / network mount / cloud | Long-term archive. Lowest cost for footage that is rarely accessed but must be retained. |
Creating Pools
Section titled “Creating Pools”Pools are configured per server from Settings > Servers > {server} > Storage Pools:
| Field | Description |
|---|---|
| Name | Descriptive name (e.g., “SSD Primary”, “HDD Archive”, “NAS Cold”) |
| Path | Filesystem path on the recording server (e.g., /recordings/hot, /mnt/nas/archive) |
| Type | Hot, Warm, or Cold |
| Max Usage % | Stop writing to this pool when disk usage exceeds this threshold (default: 90%) |
Each recording server must have at least one Hot pool configured. Warm and Cold pools are optional.
Storage Policies
Section titled “Storage Policies”A storage policy defines the lifecycle of recordings — how long they stay in each pool tier before transitioning or being deleted.
Policy Structure
Section titled “Policy Structure”Each policy specifies retention per tier:
| Tier | Retention | Description |
|---|---|---|
| Hot | 3 days | Recordings stay on fast SSD for 3 days |
| Warm | 30 days | After 3 days, move to HDD for up to 30 days |
| Cold | 365 days | After 30 days, move to NAS/cloud for up to 365 days |
After the final tier’s retention expires, recordings are permanently deleted.
Creating Policies
Section titled “Creating Policies”Create policies from Settings > Storage > Policies:
Policy: "Standard Retention" Hot: 3 days --> pool: SSD Primary Warm: 30 days --> pool: HDD Archive Cold: 365 days --> pool: NAS Cold
Policy: "High Security" Hot: 7 days --> pool: SSD Primary Warm: 90 days --> pool: HDD Archive Cold: 730 days --> pool: NAS Cold
Policy: "Short Term" Hot: 14 days --> pool: SSD Primary (no warm or cold -- delete after 14 days)Assigning Policies
Section titled “Assigning Policies”Policies are assigned at two levels:
| Level | Description |
|---|---|
| Site | All cameras at a location (site) use this policy by default |
| Camera | Override the site policy for a specific camera |
Camera-level assignment takes precedence over site-level. If neither is set, the system-wide default policy applies.
Configure assignments from Settings > Locations > {site} > Storage Policy or Settings > Cameras > {camera} > Storage Policy.
Batch Transitions
Section titled “Batch Transitions”Recordings move between pools in automated batch operations:
Transition Process
Section titled “Transition Process”- A background scheduler runs every 15 minutes on each recording server.
- For each camera, it evaluates the assigned storage policy.
- Segments in the Hot pool older than the hot retention period are queued for transition to Warm.
- Segments in the Warm pool older than the warm retention period are queued for transition to Cold.
- Segments in the Cold pool older than the cold retention period are queued for deletion.
- The batch mover copies segment files to the destination pool, verifies integrity (checksum), and updates the segment index in the management database.
- After successful copy and index update, the source file is deleted.
Transition Performance
Section titled “Transition Performance”| Factor | Impact |
|---|---|
| File size | Larger segments (longer duration) move faster per unit of footage |
| I/O bandwidth | SSD to HDD transitions are limited by HDD write speed |
| Network speed | Transitions to NAS/cloud pools are limited by network throughput |
| Concurrent moves | Configurable concurrency limit prevents saturating I/O (default: 4 concurrent file moves) |
Multi-Server Storage
Section titled “Multi-Server Storage”In multi-server deployments, each recording server manages its own pools independently. The management server maintains a unified segment index that tracks which server and pool holds each segment.
Remote Browsing API
Section titled “Remote Browsing API”The management server proxies storage queries across all recording servers:
| Method | Endpoint | Description |
|---|---|---|
GET | /api/servers/{id}/pools | List pools on a recording server |
GET | /api/servers/{id}/pools/{pool}/usage | Disk usage for a specific pool |
GET | /api/servers/{id}/pools/{pool}/segments | Browse segments in a pool |
When playing back footage, the management server automatically routes segment requests to whichever server and pool currently holds the data. Operators do not need to know which tier or server stores a specific segment.
Retention Cleanup
Section titled “Retention Cleanup”Per-Tier Retention
Section titled “Per-Tier Retention”Each tier in a storage policy has its own retention period. The retention daemon on each recording server evaluates all tiers:
- Hot tier cleanup — Moves aged segments to Warm (or deletes if no Warm tier).
- Warm tier cleanup — Moves aged segments to Cold (or deletes if no Cold tier).
- Cold tier cleanup — Deletes segments past the cold retention period.
Disk Full Strategy
Section titled “Disk Full Strategy”When a pool exceeds its configured maximum usage percentage:
| Strategy | Behavior |
|---|---|
| Stop Recording | Pause recording on cameras assigned to the full pool (default) |
| Overwrite Oldest | Delete the oldest segments in the pool to free space |
| Overflow to Next Tier | Move segments to the next tier early, bypassing normal retention |
Segment Format
Section titled “Segment Format”Recordings are stored as fMP4 (fragmented MP4) segments:
/recordings/{pool_path}/{camera_id}/YYYY/MM/DD/HHMM.mp4| Component | Description |
|---|---|
{pool_path} | The pool’s filesystem path |
{camera_id} | UUID of the camera |
YYYY/MM/DD/ | Date-based directory structure |
HHMM.mp4 | Segment file named by start time |
Segments preserve the original camera stream with no re-encoding. The original camera codec (H.264 or H.265) is preserved byte-for-byte.
Segment Duration
Section titled “Segment Duration”| Duration | Default | Range |
|---|---|---|
| Segment time | 120 seconds | 60s to 3600s |
Configure from Settings > Storage > Segment Duration. Changing the segment duration restarts the recording processes on all servers.
Segment Index
Section titled “Segment Index”Every segment is indexed in the management database with its camera, server, pool, file path, start and end timestamps, file size, and current storage tier. The index is optimised for fast timeline queries and playback lookups.
Danger Zone
Section titled “Danger Zone”Settings > Storage > Danger Zone includes:
- Delete All Recordings — Permanently deletes all segments from all servers and pools. Requires double confirmation.
- Reset Pool Configuration — Removes all pools and reverts to single-path storage. Existing segments remain on disk but must be re-indexed.
API Reference
Section titled “API Reference”| Method | Endpoint | Description |
|---|---|---|
GET | /api/settings/storage | Get storage configuration |
PATCH | /api/settings/storage | Update storage settings |
GET | /api/storage/pools | List all pools across all servers |
POST | /api/storage/pools | Create a storage pool |
PATCH | /api/storage/pools/{id} | Update a pool |
DELETE | /api/storage/pools/{id} | Delete a pool |
GET | /api/storage/policies | List storage policies |
POST | /api/storage/policies | Create a storage policy |
PATCH | /api/storage/policies/{id} | Update a policy |
DELETE | /api/storage/policies/{id} | Delete a policy |
DELETE | /api/settings/recordings | Delete all recordings |