Tiered Storage Setup for Frigate Using NVMe and Magnetic Disk

[skykingjwc]

Overview

This guide describes how to configure Frigate NVR to use a tiered storage setup where recent recordings are saved to a fast NVMe SSD for performance, and older recordings are automatically migrated to a large, slower magnetic (HDD) drive for long-term storage. This approach provides optimal performance for recent events while maximizing storage capacity over time.

Frigate runs inside a Docker container and maps the host storage volume to /media/frigate by default. We preserve this mapping and implement the tiered storage beneath this structure using mergerfs, allowing Frigate to operate without needing to be aware of the underlying complexity.

Goals

Use NVMe SSD (/media/frigate_nvme/recordings) for new, high-performance video writes

Automatically move older recordings to a magnetic HDD (/mnt/frigate_hdd/recordings) nightly

Mount both directories under a unified path (/frigate/media/recordings) using mergerfs

Ensure Frigate only sees /media/frigate, preserving existing container configs

Setup Instructions

NOTE: ALL CONFIGURATION IS DONE ON THE HOST COMPUTER, NOT THE FRIGATE DOCKER CONTAINER.
NO CHANGES TO THE FRIGATE CONTAINER OR DOCKER STACK ARE NECESSARY

1. Stop your Frigate container. We don't want it writing to disk while we are moving things around.

2. Prepare the Drives

NVMe SSD is already in use (as it is the system drive in my setup), and is mounted under root /

Installed an external USB 16TB drive on my Intel NUC.

Format and mount the magnetic HDD (e.g., /dev/sdb1) to /mnt/frigate_hdd

sudo mkfs.ext4 /dev/sdb1
sudo mkdir -p /mnt/frigate_hdd
sudo mount /dev/sdb1 /mnt/frigate_hdd

Set the new drive to mount automatically at boot, add to /etc/fstab:

/dev/sdb1 /mnt/frigate_hdd ext4 defaults 0 2

2. Install mergerfs

sudo apt update
sudo apt install mergerfs

3. Move the existing recordings folder to a new folder on the fast drive
   sudo mv /frigate/media/recordings /media/frigate/recordings_nvme

4. Create the unified mount point where the recordings folder was before we moved it:

sudo mkdir -p /frigate/media/recordings

Edit /etc/fstab and add:

/media/frigate_nvme/recordings:/mnt/frigate_hdd/recordings /frigate/media/recordings fuse.mergerfs defaults,allow_other,use_ino,minfreespace=20G,moveonenospc=true,category.create=ff 0 0

This will make both recording folders located on the fast drive and the archive drive appear to Frigate as a single folder mounted under /frigate/media/recordings New files will be written to the fast storage unless it has less than 20GB free space, in which case the archive storage will be used.

Mount the new folder:

sudo mount -a

5. Move-Old-Files Script

Create a script to move old files from the fast storage to archive storage. Adjust DAYS_OLD as needed, and set it to run nightly.

This script moves files older than 2 days from NVMe to HDD.

/usr/local/bin/move_old_recordings.sh

#!/bin/bash

SSD_PATH="/media/frigate_nvme/recordings"
HDD_PATH="/mnt/frigate_hdd/recordings"
DAYS_OLD=2
LOGFILE="/var/log/move_old_recordings.log"

# Start log
echo "$(date '+%F %T') - Starting move_old_recordings job" >> "$LOGFILE"

find "$SSD_PATH" -type f -mtime +$DAYS_OLD -print0 | while IFS= read -r -d '' file; do
    rel_path="${file#$SSD_PATH/}"
    dest_dir="$HDD_PATH/$(dirname "$rel_path")"
    mkdir -p "$dest_dir"
    mv -n "$file" "$dest_dir/" && echo "Moved: $file -> $dest_dir" >> "$LOGFILE"
done

echo "$(date '+%F %T') - Finished move_old_recordings job" >> "$LOGFILE"

Make it executable:

chmod +x /usr/local/bin/move_old_recordings.sh

5. Create the service

/etc/systemd/system/move_old_recordings.service

[Unit]
Description=Move old Frigate recordings to HDD

[Service]
Type=oneshot
ExecStart=/usr/local/bin/move_old_recordings.sh

6. Create the timer
   /etc/systemd/system/move_old_recordings.timer

[Unit]
Description=Nightly move of Frigate recordings

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true

[Install]
WantedBy=timers.target

Enable and start:

sudo systemctl daemon-reexec
sudo systemctl enable --now move_old_recordings.timer

6. Restart the Frigate Docker container

Notes

category.create=ff in mergerfs ensures new files are written to the NVMe unless it is nearly full

minfreespace=20G prevents mergerfs from writing to the NVMe if less than 20GB is free

The script runs nightly and moves files in-place while preserving Frigate’s directory structure

Frigate remains unaware of the tiered setup, continuing to write to /media/frigate

The System Metrics > Storage tab in Frigate will show a larger storage space available when everything is working.

Summary

This tiered storage setup provides fast access to recent footage and maximizes long-term capacity — all transparently handled under a single mount point. It's ideal for systems where a balance of speed and storage is required, and it can scale with minimal complexity.

[NickM-27]

Thank you for this guide, if you want to submit a PR we can look at including this guide in the documentation as well

[skykingjwc]

Yea, I can do that if you like. Just put the PR in https://github.com/blakeblackshear/frigate/pulls?

[NickM-27]

Yes 👍

[banthungprong]

Very nice! Exactly what I need for my installation in Thailand (smaller but fast SSD, soon a big external HDD) - only problem for me now: I need to fly to Thailand.

[MrNews89]

Not to hijack this thread @NickM-27, but is there any chance that Frigate in the future could have fast and slow data mount points? I would think I substantial percentage of the userbase would fit in to this use case.

Love the project, and I am amazed by all the commits you can get done on a weekly basis:-)

[NickM-27]

eventually, I don't believe it is currently a priority since it is quite achievable outside of Frigate

[DrSpaldo]

eventually, I don't believe it is currently a priority since it is quite achievable outside of Frigate

Hopefully you can reconsider, because it isn't for most people. This is pretty complex

[rhatguy]

@skykingjwc thanks for posting this write up. Its excellent. I followed this using a NAS mount point as my HDD_PATH and it worked beautifully. Rather than keeping a set number of days on my fast local NVMe drive, I wanted to target keeping the drive full. I wanted to keep as much data on the fast disk as possible and only move data if the fast disk was over a given percentage full. I also wanted to move entire days of recordings at a time such that dates were never split between the two storage mediums regardless of when the script was run. ChatGPT helped craft a slightly different "mover" script which accomplishes these goals. Maybe this will be helpful for someone else. I intend to run this fairly frequently through cron since as long as the source disk is not full, it will just check the capacity and exit (very low impact). Since it moves at most one day of recordings at a time it can be executed frequently to keep up with reducing capacity on the fast disk as needed.

First pass in a mount point to check for capacity, and then the threshold utilization above which to move a days worth of recordings. Finally pass the source directory and the destination directory, and optionally a --dry-run if you want to see what would happen without changing anything. The source (fast) and destination (slow) directories should be the directories that contain the date stamped dates on each of the underlying mediums that make up the mergerfs.

Usage: ./check_and_move.sh <mount_point> <threshold_percent> <source_dir> <dest_dir> [--dry-run]

#!/bin/bash

# Usage: ./check_and_move.sh /mount/point <threshold_percent> /source/directory /destination/directory [--dry-run]

MOUNT_POINT="$1"
THRESHOLD="$2"
SOURCE_DIR="$3"
DEST_DIR="$4"
DRY_RUN="$5"

# Helper function for logging with timestamps
log() {
  echo "$(date '+%F %T') - $*"
}

# Validate arguments
if [[ -z "$MOUNT_POINT" || -z "$THRESHOLD" || -z "$SOURCE_DIR" || -z "$DEST_DIR" ]]; then
  log "Usage: $0 <mount_point> <threshold_percent> <source_dir> <dest_dir> [--dry-run]"
  exit 1
fi

# Ensure threshold is a valid integer between 1 and 100
if ! [[ "$THRESHOLD" =~ ^[0-9]+$ ]] || (( THRESHOLD < 1 || THRESHOLD > 100 )); then
  log "Error: Threshold must be an integer between 1 and 100."
  exit 1
fi

# Ensure mount point is valid
if ! mountpoint -q "$MOUNT_POINT"; then
  log "Error: $MOUNT_POINT is not a valid mount point."
  exit 1
fi

# Check disk usage
USAGE=$(df "$MOUNT_POINT" | awk 'NR==2 {print $5}' | tr -d '%')

if [[ "$USAGE" -lt "$THRESHOLD" ]]; then
  log "Disk usage at $MOUNT_POINT is ${USAGE}%. Below threshold of ${THRESHOLD}%. No action taken."
  exit 0
fi

log "Disk usage at $MOUNT_POINT is ${USAGE}%. Above threshold of ${THRESHOLD}%. Proceeding to move oldest dated directory..."

# Find the oldest directory matching YYYY-MM-DD format in SOURCE_DIR
OLDEST_DIR=$(find "$SOURCE_DIR" -mindepth 1 -maxdepth 1 -type d -printf "%f\n" \
  | grep -E '^[0-9]{4}-[0-9]{2}-[0-9]{2}$' \
  | sort \
  | head -n 1)

if [[ -z "$OLDEST_DIR" ]]; then
  log "No dated directories found in $SOURCE_DIR."
  exit 0
fi

SOURCE_PATH="$SOURCE_DIR/$OLDEST_DIR"
DEST_PATH="$DEST_DIR/$OLDEST_DIR"

# Rsync options (common to both modes)
RSYNC_OPTS=(-av --remove-source-files "$SOURCE_PATH/" "$DEST_PATH/")

if [[ "$DRY_RUN" == "--dry-run" ]]; then
  log "Dry run enabled. Executing rsync in dry-run mode: rsync --dry-run ${RSYNC_OPTS[@]}"
  rsync --dry-run "${RSYNC_OPTS[@]}"
else
  log "Syncing $SOURCE_PATH to $DEST_PATH using rsync..."
  rsync "${RSYNC_OPTS[@]}"
  RSYNC_STATUS=$?
  if [[ $RSYNC_STATUS -eq 0 ]]; then
    log "Rsync successful. Removing source directory: $SOURCE_PATH"
    rm -rf "$SOURCE_PATH"
  else
    log "Rsync failed. Source directory was not removed."
    exit 1
  fi
fi

[skykingjwc]

Nice. This is more complete than the script I made. Thank you.

[thirst4truth]

Hi, complete novice here, feel free to delete if this isn't relevant.
I wasn't sure what mount_point should be, so I asked ChatGPT for help. I am running Frigate on a Pi 5 with a 1TB SSD and a 4TB HDD and using mergerfs to combine the two. My query was what mount_point should be because I wasn't sure whether it should be my whole SSD or just the directory on the SSD used to store Frigate data.
ChatGPT gave me the option to monitor both as a way of protecting the SSD from running out of space, and avoiding moving files if the SSD was full for unrelated reasons like logs or downloads (this is a direct quote from ChatGPT).
Here is the file from ChatGPT:

#!/bin/bash

# Usage: ./check_and_move.sh <ssd_mount_point> <ssd_threshold_percent> <source_dir> <source_threshold_percent> <dest_dir> [--dry-run]

SSD_MOUNT="$1"
SSD_THRESHOLD="$2"
SOURCE_DIR="$3"
SOURCE_THRESHOLD="$4"
DEST_DIR="$5"
DRY_RUN="$6"

log() {
  echo "$(date '+%F %T') - $*"
}

# Validate args
if [[ -z "$SSD_MOUNT" || -z "$SSD_THRESHOLD" || -z "$SOURCE_DIR" || -z "$SOURCE_THRESHOLD" || -z "$DEST_DIR" ]]; then
  log "Usage: $0 <ssd_mount_point> <ssd_threshold_percent> <source_dir> <source_threshold_percent> <dest_dir> [--dry-run]"
  exit 1
fi

# Validate thresholds
for TH in "$SSD_THRESHOLD" "$SOURCE_THRESHOLD"; do
  if ! [[ "$TH" =~ ^[0-9]+$ ]] || (( TH < 1 || TH > 100 )); then
    log "Error: Thresholds must be integers between 1 and 100."
    exit 1
  fi
done

# Ensure mount points are valid
if ! mountpoint -q "$SSD_MOUNT"; then
  log "Error: $SSD_MOUNT is not a valid mount point."
  exit 1
fi

if ! mountpoint -q "$DEST_DIR" && ! mountpoint -q "$(dirname "$DEST_DIR")"; then
  log "Error: Destination $DEST_DIR is not on a valid mount point."
  exit 1
fi

# Get usage values
SSD_USAGE=$(df "$SSD_MOUNT" | awk 'NR==2 {print $5}' | tr -d '%')
SOURCE_USAGE=$(df "$SOURCE_DIR" | awk 'NR==2 {print $5}' | tr -d '%')

log "SSD usage: ${SSD_USAGE}%, threshold: ${SSD_THRESHOLD}%"
log "Source dir usage: ${SOURCE_USAGE}%, threshold: ${SOURCE_THRESHOLD}%"

# Check both thresholds
if [[ "$SSD_USAGE" -lt "$SSD_THRESHOLD" ]]; then
  log "SSD usage below threshold. No action taken."
  exit 0
fi

if [[ "$SOURCE_USAGE" -lt "$SOURCE_THRESHOLD" ]]; then
  log "Source directory usage below threshold. No action taken."
  exit 0
fi

log "Both thresholds exceeded. Proceeding to move oldest dated directory from $SOURCE_DIR to $DEST_DIR..."

# Find oldest dated folder
OLDEST_DIR=$(find "$SOURCE_DIR" -mindepth 1 -maxdepth 1 -type d -printf "%f\n" \
  | grep -E '^[0-9]{4}-[0-9]{2}-[0-9]{2}$' \
  | sort \
  | head -n 1)

if [[ -z "$OLDEST_DIR" ]]; then
  log "No dated directories found in $SOURCE_DIR."
  exit 0
fi

SOURCE_PATH="$SOURCE_DIR/$OLDEST_DIR"
DEST_PATH="$DEST_DIR/$OLDEST_DIR"

# Rsync options
RSYNC_OPTS=(-av --remove-source-files "$SOURCE_PATH/" "$DEST_PATH/")

if [[ "$DRY_RUN" == "--dry-run" ]]; then
  log "Dry run enabled. Executing rsync in dry-run mode..."
  rsync --dry-run "${RSYNC_OPTS[@]}"
else
  log "Syncing $SOURCE_PATH to $DEST_PATH..."
  rsync "${RSYNC_OPTS[@]}"
  RSYNC_STATUS=$?
  if [[ $RSYNC_STATUS -eq 0 ]]; then
    log "Rsync successful. Removing source directory: $SOURCE_PATH"
    rm -rf "$SOURCE_PATH"
  else
    log "Rsync failed. Source directory was not removed."
    exit 1
  fi
fi

[DrSpaldo]

Thanks for the posts @skykingjwc & @rhatguy

[baudneo]

Hell. Yeah.

[Solear]

Hello! Thank you for the step by step manual for tiered storage.
It is save, to use mergers over nfs? Local nvme and the spinning hdd is an nfs share mounted via autos?
I would like to use tiered storage over local and unraid storage.

[rhatguy]

Hi, I'm using an NFS share from unraid and a local NVMe disk for tiered storage. MergerFS doesn't care where the storage comes from as it's just merging mount points. I don't see any dependency on spinning HDD, SSD, or NFS. You could use either type for either mount point.

[slijordan]

This looks awesome. Thanks for the work you put into this.

I would also like to see an HSM feature integrated directly nto frigate+ future releases.

Sent from phone, I'll expand on this later.. I would try this myself now but I just use an 8tb iscsi lun on a large zfs array.

[EJones86]

Thanks very much for this, however i'm running into a problem once i've created the mergerfs entry - Frigate is unable to create directories due to a permissions issue. I've tried to chown the directory but the problem remains. I am using an unpriviledge container. Should I be setting permissons in the fstab entry? If so, can anyone advise which to use? Thanks.

[baudneo]

Set others +rw

chmod -R o+rw /path/to/frigate

[Doug-Phoenix]

Thank you very much for this guide. I'm a novice with docker and could use some help.

I've been running frigate using docker compose for several months. No significant issues, except my 2TB ssd is almost full (recordings uses 1.1 TB). Today I installed an 8 TB HDD and mounted as /mnt/frigate_hdd.

The next step is to move the recordings folder:
sudo mv /frigate/media/recordings /media/frigate/recordings_nvme

... but I have no recordings there. Instead my recordings are at:
~/frigate_docker/storage/recordings
(my frigate docs are all under ~/frigate_docker).

... even though the relevant lines in compose.yml are:
volumes: - /etc/localtime:/etc/localtime:ro - ./config:/config - ./storage:/media/frigate - type: tmpfs # Optional: 1GB of memory, reduces SSD/SD Card wear target: /tmp/cache tmpfs: size: 1000000000

So - do I simply replace /frigate/media/recordings with ~/frigate_docker/storage/recordings? And the destination should be in the same parent directory as well? I'm confused about the path starting with /media/frigate since I have no media folder above frigate_docker, despite the line in compose.yml.

After that I need to get the fstab lines to be correct. I recall that errors in fstab are not good.

Thanks in advance!

[rhatguy]

This is hard to follow. One thing I noticed is that you have a . before the directory in the SOURCE of your mount point "./storage:/media/frigate". Note in the docs that there is not normally a . in the volume mount point specification.

Normally a period in linux signifies the current directory. I'm not sure how docker handles this. Maybe it mounts the "/storage" directory underneath the current directory you were in when you started frigate? I would suggest making this an absolute path that starts with a "/", that way there is no confusion about what directory is getting mounted to the /media/frigate mountpoint inside your container. Remember the directory to the left of the colon is the directory on the container host system. It gets mounted into the container at the mount point on the right side of the colon. Frigate (inside the container) will always store its media at /media/frigate (inside the container). So for example if you wanted all of your media to be stored in the /mnt/frigate_hdd folder outside the container, you would specify this as "/media/frigate_hdd:/media/frigate".

[Doug-Phoenix]

Thank you, @rhatguy

I appreciate this. I'm sorry my message was unclear - It can be challenging to explain a problem when you don't understand very much.

I'll work on my compose.yml after re-reviewing the docs (and reading your reply a few times). I think I had copied the config from the docs at the time, but that doesn't matter.

Thanks again!

[Doug-Phoenix]

A quick follow-up.

I followed your suggestion and moved everything to the hdd folder as in the last line of your message. Frigate is running well this way - I only have four cameras, and I'm not noticing a lag in performance recording everything on HDD. Will keep testing, but so far I'm very happy. I may have no need for fast recording using SSD.

Thanks for your good support!

[bazuchan]

Although mergefs is a good solution for local storage, it won't work so well if "big" storage is connected over internet. It would be good to have native tiered storage supporting number of options for second storage, like S3, HTTP, ...

[tartakynov]

I made this repo that can offload recordings from SSD to HDD for long term storage. It uses symlinks instead of mergefs 🙈

Retention is still controlled by Frigate. You can configure Frigate to keep recordings for 3 months, and recordings will be offloaded to the HDD daily, so the SSD will have no more than a day of recordings at any point in time. At the end of the retention period, the recordings will be removed from HDD.

Recordings offloaded to the HDD can still be viewed through Frigate.

https://github.com/tartakynov/nvr-sync

[banthungprong]

No Image, had to move nvr-sync to a separate folder besides frigate. Build and start ok. Waiting for the first job (changed run time in cron). Not working.

Running the sync-Script in the docker container moves files.

I assume using UTC in the Container is a reason. After changing the job time it works without problems!

Right now I use an USB-HDD, I want to try this with as Samba Share from my NAS .

Very nice!

[kirsch33]

Is it possible to configure a similar setup to this but have the SSD store only detections / alerts and the HDD store 24/7 continuous? The idea being to maximize the most likely desired recordings which will be events.

Not sure if it's possible to do this while keeping the HDD as storing 24/7 continuous data while making sure the Frigate UI / API ensures it always serves the SSD media where available else falling back to the HDD

[banthungprong]

No, not possible. The above script does not change anything "inside" of frigate. Only moves files and creates a symlink.
And these files do not contain information about detections or alerts or whatever - these are stored in the frigate databse.

[DrSpaldo]

The are all stored in one spot. Thousands of little clips, then the Frigate database stores which is detection, alert or 24/7 and deletes based on retention settings

[baudneo]

I would make this a feature request. It is a legit ask, but I would guess at it being low priority or something someone else besides core maintainers can engineer and put a PR in.

I would love dialed in storage management native in frigate. My biggest wet dream at the moment is 'timed' / 'scheduled' config changes for zones; I want more sensitive zones at night and in different areas than I do the daytime (I will implement this one day, after I get all my other crap done, lol). I currently run cron jobs to stop the docker stack, move config files and then restart the docker stack, but native would be nice.

[NickM-27]

There is already a feature request for this #3673

[slijordan]

You could use zfs and assign a portion or all the NVme as l2arc. It's not exactly the same, the data will all live on the spinning drives but the hot data will stay in the l2arc and replace reads / recent videos should be on the hot tier..

…

On Wed, Feb 11, 2026, 3:41 PM Dr Spalding ***@***.***> wrote: The are all stored in one spot. Thousands of little clips, then the Frigate database stores which is detection, alert or 24/7 and deletes based on retention settings — Reply to this email directly, view it on GitHub <#18343 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BCCPMYRAYI6V7AU62QW72Z34LOHXFAVCNFSM6AAAAAB5TUYF3CVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKNZXGQYDKOI> . You are receiving this because you commented.Message ID: ***@***.*** com>

[miguelvega76]

How can this be implemented if your frigate and homeassistant live in a virtual box vm in ubuntu ? I have 2 tb ssd that i use for ubuntu and the vm . 1.5 tb are dedicated to frigate , i recently bought a 4 drive das with 4 bays . I have a 10 tb drive that i am sharing through smb and mounting in homeassistant as /media/frigate. Frigate stores the videos there but it seems to be too slow to keep up with multiple cameras (10 4k) . I think implementing tiered storage make sense as it will allow to have recent videos on the ssd and older ones in the smb drive .

[skykingjwc]

I'm not a VirtualBox expert, but if you can set up USB passthrough to the VM running Frigate, the rest of the setup steps would be nearly identical. Just don't do the Docker-specific stuff. Set up your mounts and configure mergerfs.

[rhatguy]

The discussions and scripts here largely have nothing to do with how you are running frigate. If you can get the disks/nas mounted into frigate, thats the only requirement to use these scripts.

That being said, I've stopped using the script I pasted above as I moved to a N100 mini PC with an internal 1TB SSD running as an "app" on my home assistant server. After moving to H.265 and some recording tuning, I'm getting over 8 months of recordings on my SSD. That was enough for me to stop messing with this setup and just live with the amount of storage I have locally on the machine.