OpenStack Snapshot Scheduler

License	FOSS problems	Maintenance	SSO	Users	Tested
Custom (in-house)	—	Not built yet	—	Unlimited	❌

Evaluation

What it is

Not an existing product — a small custom Docker image, still to be built: the OpenStack CLI plus cron, running scoped openstack volume snapshot create/prune commands on a schedule, with credentials injected as Coolify-managed environment variables rather than a file sitting on the host. Copy-on-write, so near-instant regardless of volume size.

Why it could be useful

Nothing off-the-shelf combines OpenStack CLI access with scheduling the way Backrest bundles restic and scheduling together — this fills that specific gap. Running it as a Coolify-deployed service keeps it consistent with how every other scheduled job on this stack is handled, rather than a bare host cron entry nobody remembers exists.

Why not to go for it

It's unbuilt and unmaintained by anyone but this project — a Dockerfile and compose file still to be written, and the minimally-scoped credential it depends on (Keystone access-rules, restricting it to only snapshot actions) is unverified against Infomaniak's specific deployment. Every custom tool is one more thing only this project understands and has to keep working; before writing it, worth confirming no newer turnkey option has shown up to replace the need for it.

Setup

Needs its own, minimally-scoped application credential — not the main one, which can touch everything.

1. Create a credential restricted via Keystone's access-rules to only volume-snapshot actions:

   openstack application credential create operational-snapshots --access-rules '[
       {"path": "/v3/*/snapshots", "method": "POST", "service": "volumev3"},
       {"path": "/v3/*/snapshots/*", "method": "DELETE", "service": "volumev3"},
       {"path": "/v3/*/snapshots", "method": "GET", "service": "volumev3"}
   ]'

   Unverified against Infomaniak's specific deployment — access_rules support depends on the target service having it configured. Needs testing before this is trusted.

2. Schedule snapshot creation as a Coolify-deployed service, not a bare host timer — same pattern as Backrest, credential injected through Coolify's own env var management rather than a file sitting on the host. No turnkey image bundles OpenStack CLI + scheduling the way Backrest bundles restic + scheduling, so this needs a small custom image: an OpenStack CLI base (e.g. openstacktools/openstack-client, Debian-based) plus cron, running the create/prune commands on a schedule, with the scoped credential passed as env vars:

   openstack volume snapshot create --os-application-credential-id <scoped-cred-id> --os-application-credential-secret <scoped-cred-secret> --volume personal-services-data <name>

   Not yet built or tested — the Dockerfile/compose for this is still to be written.

3. To restore — a manual, deliberate action, using the normal full-access credential — create a new volume from the snapshot and reattach:

   pass-cli run --env-file .env -- openstack volume create --snapshot <snapshot-id> personal-services-data-restored

   Then detach whatever's currently attached to the instance and attach this one instead — same openstack_compute_volume_attach_v2 mechanism already in storage.tofu, just pointed at the restored volume's ID.