Draft

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

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.

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.
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.