Hi all,
Disclosure first: I am the author of the tool below, and it is open source.
I run PBS on a dedicated box at home. It does its job in twenty minutes a night and sits idle the rest of the day, so I wanted it powered off between backups. PVE's own scheduler cannot do that on its own: the target has to be reachable when the job fires, and nobody shuts the box down afterwards. I ended up writing a small tool for it and I have been running it for a while now, so here it is in case it is useful to someone else.
Joulenap is a self-hosted web UI plus scheduler that runs as one Docker container on the LAN. At the scheduled hour it:
Nothing is installed or modified on the PVE host or on the PBS. It talks to both through their APIs with scoped tokens (one per device); the setup wizard creates the tokens and the SSH key for you. It keeps its own scheduler, so it does not touch cron or systemd timers.
A few things beyond the basic cycle, because they came up in my own setup:
Known limitation: it reads the root namespace of the datastore. If your storage entry writes into a namespace, backups, retention and GC all work, but the per-guest "last backup" reads "never" for those guests. On the list.
I would appreciate feedback from people with setups different from mine, especially clusters, several datastores on one box, and PBS installs that are not on their own machine. Bug reports on GitHub, questions here are fine too.
Not affiliated with Proxmox Server Solutions.
Disclosure first: I am the author of the tool below, and it is open source.
I run PBS on a dedicated box at home. It does its job in twenty minutes a night and sits idle the rest of the day, so I wanted it powered off between backups. PVE's own scheduler cannot do that on its own: the target has to be reachable when the job fires, and nobody shuts the box down afterwards. I ended up writing a small tool for it and I have been running it for a while now, so here it is in case it is useful to someone else.
Joulenap is a self-hosted web UI plus scheduler that runs as one Docker container on the LAN. At the scheduled hour it:
- sends the Wake-on-LAN packet and waits for the PBS API to answer
- runs vzdump on the selected guests (all guests of a host, or a list) through the PVE API
- applies retention, then optional garbage collection and verify on the datastore
- powers the PBS off (one SSH command, since there is no API for that) and sends a notification
Nothing is installed or modified on the PVE host or on the PBS. It talks to both through their APIs with scoped tokens (one per device); the setup wizard creates the tokens and the SSH key for you. It keeps its own scheduler, so it does not touch cron or systemd timers.
A few things beyond the basic cycle, because they came up in my own setup:
- several PVE hosts to one PBS, or one PBS to another (sync, pull or push) for an off-site second copy that only comes up once a week; each of these is a "route" with its own schedule and retention
- an "external schedule" mode: if you prefer to keep your backup and sync jobs on PVE/PBS themselves, Joulenap only wakes the box, watches the tasks and powers it off when they go quiet
- run history with a per-step timeline and the live PVE/PBS task output, runs can be stopped mid-flight
- notifications through Apprise (Telegram, ntfy, email, Discord, ...), status for Homepage/Homarr/Dashy/Glance, a Prometheus endpoint
Known limitation: it reads the root namespace of the datastore. If your storage entry writes into a namespace, backups, retention and GC all work, but the per-guest "last backup" reads "never" for those guests. On the list.
- Site: https://joulenap.com
- Live demo: https://www.joulenap.com/demo/
- Source (AGPL-3.0): https://github.com/Joulenap/joulenap
- Docker: docker run with one data directory mounted, no config file to prepare; details in the README
I would appreciate feedback from people with setups different from mine, especially clusters, several datastores on one box, and PBS installs that are not on their own machine. Bug reports on GitHub, questions here are fine too.
Not affiliated with Proxmox Server Solutions.