NAS SETUP, MAINTENANCE & RECOVERY
An app disappearing from the TrueNAS dashboard is inconvenient; losing the library or database behind it is much worse. Build your backup around the files that contain the app's state, the settings that attach those files and a recovery test that proves the application can use them together.
Quick answer
Inventory each app's persistent storage, save its deployment settings and use the application’s documented database-backup method. Back up the required datasets consistently, then copy the recovery set to an independent destination. Test recovery in an isolated installation. A TrueNAS configuration export, a container image and a snapshot on the original pool each protect different things; none alone proves that an app is recoverable.
Steps to follow
-
Identify the app platform and record the deployed version
Check the TrueNAS release and whether the workload is a current Docker-based app, a custom deployment or a legacy installation that follows a different storage model. Record the app version, its catalogue or image source and its configured storage mappings. Avoid treating older Kubernetes-era instructions as interchangeable with a current app. Open the installed app's settings and list every persistent location, including uploads, database storage, configuration and any separate media share. Temporary transcode directories and recreatable caches should be identified separately from irreplaceable state.
-
Make a storage map that explains both sides of each mount
For each mount, record the TrueNAS dataset or other host location and the path presented inside the application. Mark external libraries that live outside the primary app directory. TrueNAS recommends manually managed host-path datasets for easier control of persistent app data; an ixVolume may hide more of that management from you. Do not convert a working deployment simply to follow an example. First establish where its existing data resides and how its supported export or backup can reach it without changing ownership or breaking the running service.
-
Obtain an application-consistent recovery point
Read the backup instructions for the actual app and database engine. Some workloads need a database dump, maintenance mode or a controlled stop to make their saved state consistent. A filesystem snapshot taken while a database is writing is not automatically equivalent to a supported database backup. Choose a quiet window, pause the relevant writers through the documented controls and take the required exports. Label the database export and matching file copy with the same recovery date so that a later restore does not combine unrelated points in time.
-
Copy the complete recovery set beyond the original pool
Include the persistent data, deployment information, essential secrets and application-specific exports. Add the TrueNAS configuration download as a separate supporting item. Place a protected copy on another storage system or independent backup destination, and verify that it is accessible without the source NAS. A snapshot on the application pool can provide convenient rollback but disappears with that pool if it is lost. Record how retention and deletion work at the destination rather than assuming that a synchronised folder retains older versions indefinitely.
-
Restore into an isolated target and check real app behaviour
Prepare an empty test destination with the appropriate application version, then follow that app's documented restore sequence. Keep its external integrations, upload clients and automated jobs from acting on production data while you test. Check a known old file, its associated metadata and the account that should own it. If the app has shared albums, permissions or database-backed collections, verify those too. A successful login and a running container are useful milestones, but the test is incomplete until the original information is available through the application itself.
Detailed guidance
Treat a photo library as files plus database relationships
Immich is a useful example because its database records the relationships that make a collection usable. Its automatic database dumps do not include the original photographs and videos. Protect both, and account for external libraries mounted from other datasets. During a recovery rehearsal, inspect an older image and its album membership rather than only counting thumbnails. This example also explains why an archive of application configuration files can be much smaller than the material it needs to recover. The backup inventory must describe the actual media locations.
Keep credentials recoverable without putting them in ordinary notes
Record where recovery secrets are held, including database credentials and the authentication needed to reach the backup destination. Store the secrets themselves in an appropriately protected location. A plain screenshot of every deployment setting can inadvertently expose passwords, tokens or private connection strings. Use a redacted operational record for routine troubleshooting and a separate protected recovery record for the sensitive values. Confirm that another authorised person can reach the recovery material when the NAS owner or their usual workstation is unavailable.
Verify permissions before reconnecting production clients
Restored files can be present yet unreadable because their user IDs, groups or ACLs do not match the new deployment. Compare the recorded app run-as context with the destination permissions and use the supported storage-permission controls for that app. Avoid recursively making an entire pool writable just to silence a startup error. Begin with a small restored dataset and confirm the required read and write operations. Reconnect clients only after verifying the restored application and its access boundaries, so a mistaken empty state does not spread to other devices.
Make retention fit the error you need to recover from
Keep enough dated recovery points to outlast mistakes that may remain unnoticed for days. A backup that runs after a damaging change can faithfully preserve the wrong state unless older copies remain available. Record successful completion, failed jobs and the last real restore test. After changing an app's storage paths or upgrading its database, revise the recovery notes and repeat the relevant test. Do not delete the previous working recovery set merely because a new container image starts; an upgrade and a recoverable data migration are different results.
Compare the options
| Situation | Recommended action | Check before continuing |
|---|---|---|
| Container image retained but data missing | Recover persistent datasets and application exports | An image recreates software, not the users and uploaded files |
| Database dump exists without media | Locate the matching originals and external libraries | The dump may contain references to files stored elsewhere |
| Restored files cause permission errors | Compare app identity and dataset ACLs | Do not grant broad pool-wide write access |
| Snapshot stays on the same pool | Create an independent retained copy | Pool failure can remove the app and all local snapshots |
Frequently asked questions
Can I back up every app with one universal command?
A single transfer job can collect a prepared recovery set, but preparing a consistent set depends on each application. Identify databases and external mounts first. Use the application’s supported export or stop procedure rather than assuming that copying a running directory covers every workload.
Should I replace all ixVolumes with host paths immediately?
No. Plan any migration separately and protect the current data before changing a working deployment. Host paths can make storage ownership and backups easier to understand, but changing mount paths without a verified migration can make an app appear empty or leave its database inaccessible.
Does testing a restore require replacing the live app?
Use an isolated target where practical. Keep the original service and protected backup intact while you test. Ensure the test instance cannot send production notifications, accept live uploads or modify external shares. This lets you investigate missing files and permissions before committing to a real recovery.
Official documentation
This guide combines current official documentation with practical recovery checks. It does not claim hands-on testing of your installation. Menu labels and supported procedures can vary by release; follow the documentation for your installed version.