More control over snapshots?

1

Hi! :wave: New user here (paying :dollar: )

I have been experimenting with the snapshots feature. I was glad to see it configured out-of-the-box but it feels very bare-bones at the moment.

  1. Being able to trigger a snapshot manually
  2. Being able to specify snapshot interval (similar to cron schedule)
  3. Being able to somehow replace an existing volume (or explain how a step-by-step flow might look like)

Are any of these (or other features) in the pipeline? It feels as if this feature is almost useable.

Edit: Also, I didn’t see anywhere in the docs a specification of when snapshots are created and how long they are stored.

2

Hey! You’re right, the snapshot feature right now is a little barebones. We do have plans down the line to make it more robust but for the time being it does the job. To answer your questions:

  1. Right now, you can’t create a snapshot, we do nightly snapshots (every 24 hours) of a pg database automagically. We haven’t yet exposed a way to take a snapshot manually, though the building blocks are there for that later down the line. Also, retention policies for snapshots are currently 3 days.

  2. As in the above point, snapshots are automatic and not user configured right now, so there’s no way to specify a schedule.

  3. If I’m understanding your question correctly, you could replace a volume by creating a new volume that uses the snapshot id of an existing volume (sort of like a copy) and then delete the volume that you wanted to replace. Perhaps something like:

Step 1

Get volume id of existing volume by running fly volumes list. With the desired volume id, run fly volumes snapshots list <volume_id>

List of volumes

volumes
volumes1522Ă—540 42.4 KB

List of snapshots

snapshots
snapshots924Ă—320 37.7 KB

Step 2

Create a new volume from the existing volume’s snapshot and tie it to the desired app

fly volumes create <volume-name> --snapshot-id <snapshot-id-from-above-step> -s <volume-size> [-a <app-name>]

Step 3

Delete the existing volume that is no longer wanted

fly volumes delete <existing-no-longer-wanted-volume-name> -a <app-name>

Hope that helps!

3

It doesn’t quite do the job, if the premise is that user data is of utmost importance. Allowing users to export snapshots and specify lifetimes (at a cost, if need be), will go a long way, tbh.

1 Like
4

Fair criticism! More control over snapshots is definitely in the pipeline, but we’re working on fixing reliability first, so stay tuned!

1 Like
5

@shortdiv

Thank you, I will! I’m just glad to hear that you understand the issue, that it’s on the radar and that you work in a logical order and solving critical issues like this (reliability + control over data) before “nice-to-haves”. Also plus to get fast feedback.

2 Likes
6

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.