SNAPM(5)

💖 SNAPM(5) 💖

okay bestie, welcome to the FILE FORMATS MANUAL section of the snapm cinematic universe ✨ this is the page about schedule.d, and it's genuinely so good, sit down, hydrate, let's go 🍓

---

🌸 NAME 🌸

schedule.d — snapm schedule configuration files 💅

---

🎀 SYNOPSIS 🎀

/etc/snapm/schedule.d/*.json

that's it. that's the whole synopsis. iconic behaviour honestly 👑

---

🦋 DESCRIPTION 🦋

so, the files chillin' in /etc/snapm/schedule.d get loaded when snapm does its initialisation thing 🫶 and they describe user-defined snapshot set creation schedules on the local machine. your own schedules. your own rules. main character energy fr fr.

they're structured in JSON format — and no cap, they are not generally intended to be manually edited 😭 like, you can, but the intended path is that the snapm schedule create command makes these files for you, based on whatever command line arguments you handed it. so the command is doing the journaling, you're just living your life ✨

---

🌈 STRUCTURE 🌈

a valid schedule file is literally just one single JSON object describing the schedule. that's the whole vibe. here it is in all its glory:

{
    "name": "hourly",
    "sources": [
        "/",
        "/var"
    ],
    "default_size_policy": "25%SIZE",
    "autoindex": true,
    "calendarspec": "hourly",
    "boot": true,
    "revert": true,
    "gc_policy": {
        "policy_name": "hourly",
        "policy_type": "COUNT",
        "keep_count": 2
    }
}

look at her. flawless. no notes 💖

---

✨ KEYS ✨

these are the keys defined at the top level, bestie. memorize them, they're the whole plot 👑

• name — a JSON string: the name of this schedule. it gets used for display AND as the basename for snapshot sets. it's giving "identity crisis but make it functional" 🎀
• sources — a JSON array (a list, bestie): a list of mount point or block device paths to include in the snapshot sets that this schedule creates. optionally you can slap a size policy suffix on there too 💅
• default_size_policy — a JSON string: a default size policy applied to all the sources in sources that didn't get their own explicit size policy. it's the "everyone gets a party favour unless you brought your own" of the config world 🍓
• autoindex — a JSON boolean, telling you whether snapshot sets created by this schedule should use the --autoindex argument. yes or no, true or false, slay or slay 🦋
• calendarspec — a JSON string holding a systemd calendar event expression, which says when this schedule should trigger snapshot set creation. go read systemd.time(7) for the deets, iykyk ⭐
• boot — a JSON boolean indicating whether snapshot sets created by this schedule should use the --bootable argument, so they come out bootable 👑
• revert — a JSON boolean indicating whether snapshot sets created by this schedule should use the --revert argument, to create a failsafe revert boot entry. safety first, bestie 🛟
• gc_policy — a JSON object describing the garbage collection policy for this schedule. this object always contains the two keys policy_name and policy_type, and both of them take a JSON string value:
  • the first one (policy_name) is a human readable name for the policy — normally it's the same as the schedule name 💖
  • the second one (policy_type) selects a policy type via one of the values ALL, COUNT, AGE, or TIMELINE 🌈

after those two keys come the policy-type specific parameters. every parameter has a policy defined name and a JSON integer number value 🔢

🌸 Policy types 🌸

💜 ALL

the ALL policy type takes no parameters. all snapshot sets are retained until you manually delete them. hoarder mode: activated. no shame 🎀

💜 COUNT

the COUNT policy type accepts a single parameter, keep_count, indicating the maximum number of snapshot sets to retain. keep it cute, keep it capped ✨

💜 AGE

the AGE policy type accepts four parameters: keep_years, keep_months, keep_weeks, keep_days. snapshots that are more recent than the sum of these values are retained. math but make it fashion 💅

💜 TIMELINE

the TIMELINE policy implements a more complex strategy 👀 snapshot sets get classified according to when they were taken, so for example:

• the first snapshot set in any given hour is considered an "hourly snapshot set" ⏰
• the first snapshot set after midnight on any given day is considered a "daily snapshot set" 🌙
• and so on, you get the pattern, it's giving very organized 🦋

the TIMELINE policy type accepts up to six parameters: keep_hourly, keep_daily, keep_weekly, keep_monthly, keep_quarterly, keep_yearly, and each one accepts a count argument. up to count snapshot sets are retained for each classification. six whole knobs to turn. go off 🔥

---

💅 AUTHORS 💅

Bryn M. Reeves <bmr@redhat.com> — thank you for your service, legend 🫶

---

👑 SEE ALSO 👑

• snapm(8)
• systemd.time(7)
• Snapm project page: https://github.com/snapshotmanager/snapm

---

and that's the page, bestie 💖 this was Linux, dated Jun 15 2025, straight from the FILE FORMATS MANUAL, SNAPM(5) — now go forth and schedule your snapshots responsibly, periodt ✨🌈🦋