Snapshot schedules: automatic snapshots with their own retention

A snapshot schedule takes snapshots of an instance's boot disk for you, at a time you choose, and deletes them again once they are older than you want to keep them. An instance can have up to 10 schedules, each with its own timing and its own retention, so you can keep recent snapshots close together and older ones further apart. For example:

• Daily, kept 14 weeks: a snapshot for every day of the last three months.
• Monthly, kept 12 months: one for each of the last twelve months.
• Yearly, kept 7 years: one for each year.

Each schedule deletes only the snapshots it took. Snapshots you take by hand, and snapshots taken by the instance's other schedules, are never touched.

This article covers:

1. Adding a schedule in the portal
2. Timing
3. Retention: how long snapshots are kept
4. Pausing, editing and deleting
5. When a run takes no snapshot
6. Billing
7. Through the API

1. Add a schedule in the portal

1. Open Instances and click the instance.

2. Open the Snapshots tab. The Schedules card is above the list of snapshots.

3. Either pick a Quick start:

   • Daily, kept 14 days
   • Daily kept 7 days + weekly kept 8 weeks
   • Daily kept 14 weeks + monthly kept 12 months + yearly kept 7 years (adds the three schedules in one go)
   • Hourly, newest 48 kept

   The card lists what will be added; click Add to confirm.

4. Or click Add schedule and fill in the form:

   • Frequency: hourly, daily, weekly, monthly or yearly. Only the fields that frequency needs are shown.
   • Name: filled in from the frequency (daily, monthly ...). Its snapshots are named after it, for example daily-20261102-0300.
   • When, in UTC, with your own local time shown next to it.
   • Keep: the newest N snapshots, delete them after a time, or both (section 3).

   The form shows the rule in plain words, when the first snapshot will be taken, and about how many snapshots the schedule will hold.

5. Click Add schedule.

Each schedule in the card shows its rule, its next and last run, how many snapshots it holds now, and the reason if its last run took no snapshot. In the snapshot list, a snapshot a schedule took is marked Schedule: name; the others are marked Manual.

2. Timing

All times are in UTC, so a schedule does not move when clocks change for daylight saving time. The portal shows the time in your own zone next to it.

The first snapshot is taken at the next matching time after you add the schedule. If you need one right away, take a manual snapshot as well.

Spread schedules on the same instance a little apart (for example 03:00, 04:00 and 05:00) so they do not all start at once.

3. Retention

Choose one or both:

• Keep the newest N: when the schedule has more than N snapshots, the oldest are deleted.
• Delete after N days, weeks, months or years: a snapshot is deleted once it is older than that.

With both, whichever deletes a snapshot first. Old snapshots are checked every minute. A snapshot that is still being created is never deleted.

Retention counts only the snapshots that schedule took. Deleting a scheduled snapshot by hand is fine: the schedule simply holds one fewer.

4. Pause, edit or delete

• Pause stops new snapshots. A paused schedule still deletes old snapshots by its retention. Resume starts it again at its next run.
• Edit changes the timing, the retention or the name. A shorter retention applies to the snapshots it already took, within a minute.
• Delete stops the schedule. By default its snapshots stay, as manual snapshots that you delete yourself. Tick Also delete the N snapshots it took to delete them with the schedule; they cannot be restored afterwards.

When an instance is deleted, its schedules stop. Snapshots they took stay until you delete them.

5. When a run takes no snapshot

A run can be refused for the same reasons as a manual snapshot: the account has reached its snapshot limit, there is no usable card on file, or the instance is busy (for example still being created, or neither running nor stopped). The schedule then shows The last run took no snapshot with the reason, and the next run tries again as usual. Fix the cause, for example delete old snapshots, ask for a higher limit on the Limits page, or add a card in Billing.

6. Billing

Scheduled snapshots are billed like manual ones: per GB-month of stored size, hourly, until they are deleted. They count against the same snapshot limits. A long retention multiplies the snapshots you keep: a daily schedule kept 14 weeks holds about 98 snapshots once it has run for 14 weeks. The form shows that number before you add the schedule.

An enabled schedule needs a usable card on file, like a manual snapshot.

7. Through the API

POST /v1/instances/{id}/snapshot-schedules adds a schedule:

curl -sS -X POST https://api.nextifynow.com/v1/instances/$ID/snapshot-schedules \
  -H "Authorization: Bearer $NEXTIFY_TOKEN" -H "Content-Type: application/json" \
  -d '{"name": "daily", "frequency": "daily", "hour": 3, "minute": 0, "retain": {"value": 14, "unit": "weeks"}}'

• keep_count keeps the newest N; retain ({"value": 14, "unit": "weeks"}) deletes older ones. Give one or both.
• GET /v1/instances/{id}/snapshot-schedules lists them with next_run_at, last_run_at, last_error and snapshots.
• PATCH /v1/snapshot-schedules/{id} changes one; {"enabled": false} pauses it.
• DELETE /v1/snapshot-schedules/{id} deletes it and keeps its snapshots; add ?delete_snapshots=true to delete them too.
• Each snapshot carries schedule_id: the schedule that took it, or null for a manual one.

The API documentation has a complete example that adds the daily, monthly and yearly schedules together.