TrueNASTrueNAS Stable Version Documentation
This content follows TrueNAS 24.10 (Electric Eel) releases. Use the Product and Version selectors above to view content specific to a different software release.

Adding Periodic Snapshot Tasks

Periodic snapshot tasks allow you to schedule creating read-only versions of pools and datasets at a given point in time. You can also access VMWare snapshot integration and TrueNAS SCALE storage snapshots from the Periodic Snapshot Tasks widget.

How should I use snapshots?

Snapshots do not make not copies of the data so creating one is quick and if little data changed, they take very little space. It is common to take frequent snapshots as soon as every 15 minutes, even for large and active pools. A snapshot where no files changed takes no storage space, but as files changes happen, the snapshot size changes to reflect the size of the changes. In the same way as all pool data, after deleting the last reference to the data you recover the space.

Snapshots keep a history of files, providing a way to recover an older copy or even a deleted file. For this reason, many administrators take snapshots often, store them for a period of time, and store them on another system, typically using the Replication Tasks function. Such a strategy allows the administrator to roll the system back to a specific point in time. If there is a catastrophic loss, an off-site snapshot can restore data up to the time of the last snapshot.

Creating a Periodic Snapshot Task

Create the required datasets or zvols before creating a snapshot task.

Go to Data Protection > Periodic Snapshot Tasks and click Add.

AddPeriodicSnapshotTaskScreen

First, choose the dataset (or zvol) to schedule as a regular backup with snapshots, and how long to store the snapshots.

Next, define the task Schedule. If you need a specific schedule, choose Custom and use the Advanced Scheduler section below.

Configure the remaining options for your use case. For help with naming schema and lifetime settings refer to the sections below.

Click Save to save this task and add it to the list in Data Protection > Periodic Snapshot Tasks.

You can find any snapshots taken using this task in Storage > Snapshots.

To check the log for a saved snapshot schedule, go to Data Protection > Periodic Snapshot Tasks and click on the task. The Edit Periodic Snapshot Tasks screen displays where you can modify any settings for the task.

Using the Advanced Scheduler

Advanced Scheduler

DataProtectionSMARTTestAdvancedSchedSCALE

Choosing a Presets option populates in the rest of the fields. To customize a schedule, enter crontab values for the Minutes/Hours/Days.

These fields accept standard cron values. The simplest option is to enter a single number in the field. The task runs when the time value matches that number. For example, entering 10 means that the job runs when the time is ten minutes past the hour.

An asterisk (*) means match all values.

You can set specific time ranges by entering hyphenated number values. For example, entering 30-35 in the Minutes field sets the task to run at minutes 30, 31, 32, 33, 34, and 35.

You can also enter lists of values. Enter individual values separated by a comma (,). For example, entering 1,14 in the Hours field means the task runs at 1:00 AM (0100) and 2:00 PM (1400).

A slash (/) designates a step value. For example, entering * in Days runs the task every day of the month. Entering */2 runs it every other day.

Combining the above examples creates a schedule running a task each minute from 1:30-1:35 AM and 2:30-2:35 PM every other day.

TrueNAS has an option to select which Months the task runs. Leaving each month unset is the same as selecting every month.

The Days of Week schedules the task to run on specific days in addition to any listed days. For example, entering 1 in Days and setting Wed for Days of Week creates a schedule that starts a task on the first day of the month and every Wednesday of the month.

The Schedule Preview displays when the current settings mean the task runs.

Examples of CRON syntax

SyntaxMeaningExamples
*Every item.* (minutes) = every minute of the hour.
* (days) = every day.
*/NEvery Nth item.*/15 (minutes) = every 15th minute of the hour.
*/3 (days) = every 3rd day.
*/3 (months) = every 3rd month.
Comma and hyphen/dashEach stated item (comma)
Each item in a range (hyphen/dash).
1,31 (minutes) = on the 1st and 31st minute of the hour.
1-3,31 (minutes) = on the 1st to 3rd minutes inclusive, and the 31st minute, of the hour.
mon-fri (days) = every Monday to Friday inclusive (every weekday).
mar,jun,sep,dec (months) = every March, June, September, December.

You can specify days of the month or days of the week.

TrueNAS lets users create flexible schedules using the available options. The table below has some examples:

Desired scheduleValues to enter
3 times a day (at midnight, 08:00 and 16:00)months=*; days=*; hours=0/8 or 0,8,16; minutes=0
(Meaning: every day of every month, when hours=0/8/16 and minutes=0)
Every Monday/Wednesday/Friday, at 8.30 pmmonths=*; days=mon,wed,fri; hours=20; minutes=30
1st and 15th day of the month, during October to June, at 00:01 ammonths=oct-dec,jan-jun; days=1,15; hours=0; minutes=1
Every 15 minutes during the working week, which is 8am - 7pm (08:00 - 19:00) Monday to FridayNote that this requires two tasks to achieve:
(1) months=*; days=mon-fri; hours=8-18; minutes=*/15
(2) months=*; days=mon-fri; hours=19; minutes=0
We need the second scheduled item, to execute at 19:00, otherwise we would stop at 18:45. Another workaround would be to stop at 18:45 or 19:45 rather than 19:00.

Using Naming Schemas

The Naming Schema determines how automated snapshot names generate. A valid schema requires the %Y (year), %m (month), %d (day), %H (hour), and %M (minute) time strings, but you can add more identifiers to the schema too, using any identifiers from the Python strptime function.

For Periodic Snapshot Tasks used to set up a replication task with the Replication Task function:

You can use custom naming schema for full backup replication tasks. If you are going to use the snapshot for an incremental replication task, use the default naming schema.

This uses some letters differently from POSIX (Unix) time functions. For example, including %z (time zone) ensures that snapshots do not have naming conflicts when daylight time starts and ends, and %S (second) adds finer time granularity.

Examples:

Naming SchemeSnapshot Names Look Like
replicationsnaps-1wklife-%Y%m%d_%H:%Mreplicationsnaps-1wklife-20210120_00:00, replicationsnaps-1wklife-20210120_06:00
autosnap_%Y.%m.%d-%H.%M.%S-%zautosnap_2021.01.20-00.00.00-EST, autosnap_2021.01.20-06.00.00-EST
When referencing snapshots from a Windows computer, avoid using characters like colon (:) that are invalid in a Windows file path. Some applications limit filename or path length, and there might be limitations related to spaces and other characters. Always consider future uses and ensure the name given to a periodic snapshot is acceptable.

Setting Snapshot Lifetimes

A snapshot lifetime value defines how long the snapshot schedule ignores that snapshot when it looks for obsolete snapshots to remove. For example, defining a lifetime of two weeks on a snapshot created after a weekly snapshot schedule runs can result in that snapshot actually being deleted three weeks later. This is because the snapshot has a timestamp and defined lifetime that preserves the snapshot until the next time the scheduled snapshot task runs.

TrueNAS also preserves snapshots when at least one periodic task requires it. For example, you have two schedules created where one schedule takes a snapshot every hour and keeps them for a week, and the other takes a snapshot every day and keeps them for 3 years. Each has an hourly snapshot taken. After a week, snapshots created at 01.00 through 23.00 get deleted, but you keep snapshots timed at 00.00 because they are necessary for the second periodic task. These snapshots get destroyed at the end of 3 years.

About Snapshot Granularity

Snapshot granularity refers to the frequency and detail of snapshots, and directly impacts the recovery precision and storage efficiency of a system. Heightened snapshot granularity is directly linked to an increase in the rate of snapshots taken. Raising the overall snapshot granularity often leads to the need for lower retention times, as this configuration routinely takes up more space. Similarly, a high level of snapshot granularity tends to decrease system performance overtime due to a raise in processing and indexing needs. Provided this, configuring your system with high snapshot granularity is typically recommended to users who need detailed recovery options for vital system data.

To lower snapshot granularity decrease the rate the system takes snapshots. With this configuration the snapshots tasks use less system storage and overall snapshot retention increases; however, this does limit the amount of reliable recovery options.

Cloud and Local Snapshot Storage

Snapshot granularity refers to the frequency and detail of snapshots, and directly impacts the recovery precision and storage efficiency of a system. Using a cloud sync task to upload snapshots to a cloud storage provider decreases snapshot granularity and can provide a way to reduce costs associated with data transfer and cloud storage.

Using local snapshot storage provides a more optimum environment for periodic snapshot tasks with high levels of granularity, as local storage tends to have lower latency and faster access speeds. We generally recommend configuring snapshot replication tasks with lower recovery time objective (RTO) requirements for rapid recovery when implementing local storage.