TrueNas Scale needs a first party application backup and restore system

The whole purpose of a NAS to keep data secure and resilient to data loss. Currently there is no way to backup and restore applications.

Thoughts:

  • First party implementation by ix systems
  • Simple
  • Application independent
  • Backup and restore applications
    • Restoring/Backup application configuration and data set
    • Restoring application data
    • Restore applications even on a new Truenas Scale system from backup
  • End-user should be able to browse application data through a file explore

Application Backups/Restore should be plug-and-play. No other NAS software has implemented such a system that is open source. Third party isn’t good enough due to complexity.

React to the post with “thumbs up” or “down”

2 Likes

That’s apart of the scope of work we are doing in the new Apps implementation. Idea is to keep nearly all application config on-data pool, and if we have specific things land in our DB, provide an export / import functionality as well. We want to make it super simple to migrate an Apps workload to a new system and bring it back with minimal fuss.

4 Likes

That’s exciting to hear!

Once the team is further along with the design phase can you break that down from a technical perspective and the end-user experience for community feedback? Perhaps that could be here or a blog post?

Yep, I’ll be keeping folks updated as things land in the nightly images in the run-up to BETA. Once at BETA I will expect full docs to make an appearance as well.

2 Likes

One thing that would be important is to be able to back up and restore individual apps.

That’s not always trivial. Backing up a Nextcloud container for example, correctly, involves setting maintenance mode, running a mysqldump or pgdump, etc. You wouldn’t get a good backup just doing a server level backup of some sort. It’s not the only app with special backup procedures either. And with going to docker, it can get even worse as someone may run a separate postgres database “server” container for many purposes, making it even more difficult. I suppose they can make a best effort but it won’t be a substitute for me for a container based backup of the special apps.

1 Like

I could see that being an issue for live backups. If the app is properly shut down before back up and as long as separate containers are accounted for that shouldn’t be an issue.

My concern depending on how the apps are containerized if they (multiple independent apps) share infrastructure/backends like databases. That’s more efficient but I’m not seeing an easy technical route for backup and restore.

Yeah it is complex. However nextcloud is a great example that frequently breaks highlighting my concern.

Imagine nextcloud breaks in a way that’s not easily recoverable. It would be awful to have to roll back all applications (configuration and data) to an earlier state when it’s only one that needs to be restored. To me that puts a lot of data at risk. For example X application commits data which will be lost. That data might be important and unknown at the time of restore by the admin. This risk grows with the number of applications on the server.

This comes down to

  1. snapshotting data + config for each “app”, ie a compose folder + data dataset
  2. taking care backup/restore on a app compose basis, ie where necessary, there might need to be a backup/restore service implemented in the compose stack.

Not sure if 2) would be undertaken. Its something I do organize for some of my compose apps.

I definitely organise 1) to happen, and in many cases this is sufficient…