Tiered Storage Setup for Frigate Using NVMe and Magnetic Disk #18343
Replies: 16 comments 17 replies
-
|
Thank you for this guide, if you want to submit a PR we can look at including this guide in the documentation as well |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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:-) |
Beta Was this translation helpful? Give feedback.
-
|
@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. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the posts @skykingjwc & @rhatguy |
Beta Was this translation helpful? Give feedback.
-
|
Hell. Yeah. |
Beta Was this translation helpful? Give feedback.
-
|
Hello! Thank you for the step by step manual for tiered storage. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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: ... but I have no recordings there. Instead my recordings are at: ... even though the relevant lines in compose.yml are: 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! |
Beta Was this translation helpful? Give feedback.
-
|
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, ... |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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>
|
Beta Was this translation helpful? Give feedback.
-
|
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 . |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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
Stop your Frigate container. We don't want it writing to disk while we are moving things around.
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
Set the new drive to mount automatically at boot, add to /etc/fstab:
/dev/sdb1 /mnt/frigate_hdd ext4 defaults 0 2Move the existing recordings folder to a new folder on the fast drive
sudo mv /frigate/media/recordings /media/frigate/recordings_nvmeCreate the unified mount point where the recordings folder was before we moved it:
sudo mkdir -p /frigate/media/recordingsEdit /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 0This 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 -aCreate 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
Make it executable:
chmod +x /usr/local/bin/move_old_recordings.sh/etc/systemd/system/move_old_recordings.service
/etc/systemd/system/move_old_recordings.timer
Enable and start:
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.
Beta Was this translation helpful? Give feedback.
All reactions