I’ve been working on a complete backup & restore solution for Directus, since I couldn’t find anything that really covers all real-world needs.
The system is based on a Docker setup (similar to starter kits), but extended with a dedicated backup service container and a custom Directus module for management.
It creates FULL backups of a Directus instance, including:
Database
Uploads / Assets
Extensions
Current features include:
Configurable backup frequency
Retention policies
Storage quotas
Backup download & upload via UI
Full restore directly from within Directus
Additionally, there is:
An API for backup management
Script-based restore (important if Directus itself is no longer accessible)
This means it is possible to recover even completely broken installations.
The tool has become extremely valuable in my own setup, and since I haven’t seen a comparable solution in the ecosystem, I’m wondering:
Would there be interest in this as an open-source Directus extension?
If so, I’d consider refining it for public release.
Have been working again on this extension lately and it got a lot of improvements, like a redesigned interface, making full use of the sidepanels. In addition to the settings moving to the left panel, there is also a new logging feature on the right which shows the latest activities:
Setup has also been simplified. It now requires one Directus extension and one additional backup container. As far as I can tell, it is not really possible to put all of this functionality into the extension itself.
There is still one thing that bothers me a bit: the backup container currently needs access to the Docker socket. This is necessary because it has to control the Directus container during a full restore — stop Directus, perform the restore, and then start it again.
A full restore can be initiated directly from Directus Studio, and I definitely want to keep that workflow.
So my question is: is there another way to achieve this without giving the backup container access to Docker? Any ideas or suggestions?
Also, is anyone actually interested in using something like this? It is already quite useful for me personally, and I would be happy to share it — but I don’t necessarily have to.
I’m really glad you started building something this useful and actually made it happen. A full backup and restore solution for Directus has been needed for a long time, especially since current extensions and scripts usually don’t cover everything in one place (schema, assets, permissions, and flows), so it’s very promising, and I think a lot of people in the community would benefit from it once it’s available.
One thing I think it would matter is support for different hosting setups, since not everyone has direct Docker access or uses the same deployment approach. I’m not the best person to speak on that part technically, but I hope the setup can stay simple and easy to use for those cases as well.
Keep it up man! I’m looking forward to seeing how this develops.
thanks for your feedback! Yes, the extension currently has a few limitations:
Docker-based – I think a large portion of Directus installations run in Docker environments, so it fits many use cases. It also provides a clean and controlled way to perform backups and restores. That said, I’m definitely open to ideas for setups that don’t require Docker.
Requires socket access – This is something I would like to overcome as well. I actually created a separate post discussing this challenge in more detail. I have an alternative approach in mind and outlined it there, but honestly, I’m not a huge fan of it. Suggestions are very welcome.
PostgreSQL only – At the moment, only PostgreSQL is supported, since the backup scripts operate at the database level rather than through Directus itself. PostgreSQL also happens to be the most common Directus deployment target. Supporting additional databases would mainly require implementing the respective adapters, so extending support in the future should be entirely possible.
Thanks again for taking the time to comment and share your thoughts!
OK, so the first beta of Directus Backup is now available:
So you are welcome to give it a try, feedback much appreciated!
But beware it is clearly not ready for production as it only has been tested with limited configurations.
Also, I am still not happy about the setup and limitations. Still exploring other ways to get rid of the socket access requirement or even the whole sidecar.
Something like a directus maintainance mode would be helpful.
Putting it into an extension alone would have two big drawbacks:
Ressources are shared, isolation with a separate container is better
Restoring while directus is running can result in inconsistent or even corrputed backups
Especially the latter one is the killer for me. So, one way or the other, directus has to be stopped before restoring. I already have another idea how to pull this off even without sidecar, while still keeping integrity intact. If this works, I might do a bigger refactoring (IF I decide to stay on the platform …)
This will solve 2), but not 1) and it also requires some - but less - setup - so the question is if the 1) tradeoff is worth it for a much simplified setup in exchange.
So I could not resist to try the alternate route … and it seems to work quite well! The trick was to move the restore functionality into a custom entrypoint. By this way, directus is also restarted by the backup module before restore, and if there is a pending restore, it is running before directus starts, providing basically the same safety and data integrity as the sidecar solution, but without need for a separate container and therefore no need for socket access (which is basically docker root access!)
All features were preserved, including the desaster recovery script. The only real disadvantage I see is that you loose some process / resource isolation. Installation is also easier, with all the functionality now rolled into the extension. However, it is still not possible to just do a marketplace one-click install. The extension is still not sandboxed (and probably never will be), and you will need to add pg_dump/pg_restore to your docker compose file, and you also have to add the entrypoint and restart: unless-stopped.
So I am wondering if there is still any valid usecase using a separate sidecar, vs the extension-only solution. I am not keen to support multiple codebases, so the question to you guys is: what solution would you prefer?
Quick follow-up: I decided to for the refactored extension-only version, this is now released. Ahhh I wish I had this idea sooner … a lot of refactoring was needed, but I think the result is worth it.
The sidecar container and Docker socket requirement are gone. The backup/restore logic now runs as a Directus extension, with a much simpler setup: install the extension, use a custom Directus image, mount a backup volume, and add a restart policy so restores can safely restart the container.
The main tradeoff is still the one discussed above: backups share the Directus container resources. In exchange, setup is significantly simpler and avoids Docker socket access.
I also added more documentation, example files, install guidance, and integration tests around backup, restore, import hardening, timeout handling, and disaster recovery.
Feedback is still very welcome, especially from different Docker/Directus setups.
After some consideration, I have decided to discontinue this project.
The extension has served me well and solved a problem I could not find a satisfactory solution for elsewhere. However, I have decided to move away from Directus for future projects, which means I will no longer be maintaining or developing this extension.
The repository will remain available - at least for a while - for anyone who finds it useful. Feel free to clone it, fork it, or build upon it.
Thanks to everyone who took the time to comment, provide feedback, show interest, or simply follow the project.
Wishing the Directus team and community all the best for the future.
