iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
The reliable answer is a 3-2-1 backup that protects two different kinds of data: the original photo and video files, and the application database that records paths, albums, users, and other metadata. Keep at least one copy on a separate local device and another copy away from the server’s site. For an Immich installation, create a database dump with Immich’s supported procedure, snapshot that dump together with the asset files using a versioned backup tool, and periodically prove that you can restore both.
A database backup alone cannot recreate missing originals. A second disk in the same room cannot protect against theft, fire, or a site-wide failure. A backup that has never been restored is only an assumption. The plan below treats media, metadata, configuration, credentials, and recovery testing as one system.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →What a self-hosted photo backup must survive
Start by naming the failure you are designing for. A server failure can mean a dead boot drive, a corrupted filesystem, an accidental deletion, ransomware, a stolen machine, or loss of the entire building. Each case needs a different level of separation.
- Drive or server failure: a second device that is not the failed device lets you rebuild locally.
- Malware, operator error, or silent corruption: versioned snapshots let you return to an earlier state instead of copying the damage to every mirror.
- Theft, fire, flood, or site outage: an off-site copy is required; another disk beside the server is not geographically separate.
- Encryption or credential loss: recovery depends on preserving the backup passphrase, encryption key, and access credentials separately from the host.
Use the 3-2-1 pattern as the baseline: three copies of the data, on at least two kinds of storage, with at least one copy off-site. Immich’s official documentation recommends this strategy. It also makes clear that Immich does not perform filesystem backups for you; arranging those copies is the administrator’s job.
#1 Best Overall
- High capacity in a small enclosure – The small, lightweight design offers up to 6TB* capacity, making WD Elements portable hard drives the ideal companion for consumers on the go.
- Plug-and-play expandability
- Vast capacities up to 6TB[1] to store your photos, videos, music, important documents and more
- SuperSpeed USB 3.2 Gen 1 (5Gbps)
The critical distinction: database versus original files
Photo applications usually maintain a database and a media tree. The database may contain file paths, users, albums, faces, sharing information, edits, and other metadata. The media tree contains the original photos and videos, plus application-generated derivatives such as thumbnails and transcoded video.
Immich documents this distinction explicitly: its database stores paths and user metadata, does not scan the library folder to reconstruct the database, and a database backup does not contain the photos or videos. Restoring only the database can therefore produce a perfectly valid catalog that points at files that no longer exist. Restoring only the files can leave you with media but no albums, users, or application state.
Free tools Windows power users keep installed
One-click scans. No signup required.
Treat the following as separate backup subjects that must be recoverable together:
- Original assets: the full-resolution photos and videos that you would still want if the application were replaced.
- Database dump: the application’s supported export of metadata and relationships.
- Configuration: compose files, environment settings, service definitions, reverse-proxy configuration, and any scripts used to start the stack.
- External-library paths: mounts or directories that the application reads but does not manage in its internal upload tree.
- Secrets and keys: database credentials, backup encryption passphrases, object-storage credentials, and any customer-managed encryption keys.
Regenerable thumbnails and encoded video may not need the same retention as originals. Immich’s Borg example excludes those derivatives, but that is an implementation example rather than a universal rule. If regenerating them would be too slow or impossible in your environment, include them or document the rebuild time and capacity you will need.
Build a copy layout that is independent of the server
| Copy | Typical location | Protects against | Important limitation |
|---|---|---|---|
| Primary library | Server storage | Normal operation | Not a backup; it can fail with the server. |
| Local backup | Separate external drive or another machine at the site | Single-drive and many server failures | Does not protect against a site-wide event while it remains on-site and connected. |
| Off-site backup | Remote machine, remote Borg repository, or object storage | Theft, fire, flood, and site loss | Recovery depends on bandwidth, credentials, retention, and provider costs. |
| Offline or disconnected copy | Drive unplugged or otherwise inaccessible except during backup | Ransomware and accidental deletion that reach online targets | Requires a deliberate rotation and restore checks. |
A mirrored directory or RAID array improves availability, but it is still part of the live storage system. Deletion, encryption, filesystem corruption, or a controller failure can affect every member. Keep a versioned backup outside that array, and keep at least one copy disconnected or otherwise protected from routine write access.
Inventory the application before choosing a tool
Do not begin by copying whatever folder looks largest. First map how your installation stores data. Storage templates, bind mounts, Docker volumes, and external libraries can make two installations of the same application use different paths.
- Record the application and release context. Write down the Immich version, database version, container image tags, operating system, and backup-tool version. Restore procedures can change between releases; Immich’s current documentation notes that its restore instructions changed in version 2.5.0.
- List every media location. Include the internal upload/library tree and every external-library mount. Follow symlinks and container mounts until you know which physical filesystem contains each original.
- Identify the database service. Note where the database runs, how Immich’s supported backup procedure is invoked, and where the resulting dump is written.
- Capture configuration. Preserve compose or service definitions, environment-variable names, mount points, reverse-proxy settings, and any custom scripts. Remove secrets from broadly shared notes, but make sure the real secrets are stored securely elsewhere.
- Measure the dataset. Record total bytes, file count, growth per month, and the largest files. These figures determine drive size, upload time, and the time required for a full restore.
- Document permissions. Record the user and group that must be able to read the restored folders. A successful file transfer is not enough if the rebuilt containers cannot access their mounts.
Keep this inventory with the backup documentation, not only on the server that may fail. A printed summary or an encrypted document stored with the off-site copy can be useful during a complete rebuild.
Rank #2
- Slim durable design to help take your important files with you
- Vast capacities up to 6TB[1] to store your photos, videos, music, important documents and more
- Back up smarter with included device management software[2] with defense against ransomware
- Help secure your important files with password protection and hardware encryption
- 3-year limited warranty
Create a consistent database-and-files snapshot
Consistency matters when the database and filesystem change at different moments. A database dump taken after a file was moved, followed by a filesystem copy taken before that move, can restore references to the wrong state.
Preferred method: stop writes during the backup
Immich recommends stopping the server during backup if possible. A maintenance window prevents uploads, deletions, metadata edits, and background jobs from changing one part of the dataset while another part is being copied.
- Notify users and stop uploads and mobile synchronization.
- Stop the Immich services using the method appropriate to your installation.
- Run Immich’s supported database-backup procedure and verify that a dump file was produced.
- Copy the database dump and the relevant media trees into the same versioned backup snapshot.
- Confirm that the snapshot completed and that its file list includes the dump and every required mount.
- Start the services again and check that the application opens normally.
Do not guess at a database command when the application supplies a supported procedure. The correct command, container name, and dump location depend on the installation and release.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWhen the service cannot be stopped
If continuous operation is required, Immich’s guidance recommends taking the database backup first and the filesystem backup second. This order reduces the chance that a restored database refers to files that are absent from the restored filesystem. It does not eliminate every race between uploads and file operations, so schedule a quiet period, pause clients if possible, and record the exact start and end times of each operation.
After an online backup, inspect the backup log for errors and compare the database dump timestamp with the media snapshot timestamp. A green exit code is not proof that every mounted directory was included.
Use versioned snapshots rather than a one-time copy
A plain copy can preserve today’s files but cannot recover yesterday’s state after an accidental deletion. Use a tool that creates immutable or append-only snapshots, verifies transferred data, and retains multiple points in time. Borg is one example used in Immich’s official backup template.
Immich’s example places the database dump and asset tree in the same Borg snapshot and excludes regenerable thumbnails and encoded video. Adapt that example only after confirming which directories are disposable in your deployment. Keep originals, the database dump, and any irreplaceable external-library content in the snapshot.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →Rank #3
- Ultra fast data transfers: the external hard drive works with USB 3.0 thickened copper cable to provide super fast transfer speeds. Theoretical read speed is as high as 110MB/s-133MB/s and write speed is as high as 103MB/s.
- Ultra-thin and quiet: the motherboard adopts a noise-free solution, giving you a quiet working environment. Lightweight and portable size designed to fit in your pocket for easy portability.
- Compatibility: compatible with PS4/xbox one/Windows/Linux/Mac/Android,Stable and fast downloading on game console no difference from fast transmission when using on PC.
- Plug and Play: no software to install, just plug it in and the drive is ready to use. The hard drive chip is wrapped with aluminum anti-interference layer to increase heat dissipation and protect data
- Package Contents: 1* portable hard drive, 1 *USB 3.0 cable, 1*USB to type C adapter，1 *user manual, shell packaging, three-year manufacturer's warranty and free technical support services
Retention is a policy, not a statistic
The Immich script example keeps four weekly and three monthly Borg snapshots. That is an implementation example, not a universal recommendation or a measured outcome. Choose retention from your recovery needs:
- Keep short-interval snapshots long enough to catch accidental deletions discovered a few days later.
- Keep monthly or quarterly points long enough to cover delayed corruption or an unnoticed ransomware event.
- Increase retention before major migrations or bulk edits.
- Monitor repository growth and test pruning so that a full destination does not silently stop new backups.
Use a separate backup identity with the minimum permissions needed. The account that runs the photo server should not automatically be able to delete every historical snapshot.
Choose local and off-site destinations deliberately
| Destination | Separation | Recovery speed | Automation and history | Cost considerations | Key and restore considerations |
|---|---|---|---|---|---|
| External hard drive | Separate device, but usually same site | Fast when directly attached | Requires a versioned tool and a rotation schedule | One-time hardware cost; capacity must exceed the retained dataset | Easy to test locally; unplug or store separately to reduce ransomware exposure |
| Remote machine | Can be geographically separate | Limited by network upload and download speed | Good fit for scheduled Borg repositories and retention policies | Hardware, hosting, and bandwidth costs vary | Protect remote access credentials and test a complete pull |
| Remote Borg repository | Off-site if the repository is elsewhere | Depends on provider bandwidth and repository availability | Snapshot, deduplication, and pruning can be automated | Storage and any transfer or recovery fees depend on the service | Keep the repository passphrase and recovery instructions independently |
| Object storage such as B2 | Normally off-site and highly separate from the host | Can be slower or more expensive for a large restore | Requires compatible client software, scheduling, and lifecycle rules | Storage, API operations, downloads, and retrieval behavior all matter | Decide who controls encryption keys and how a new host obtains them |
No destination is universally best. A local drive is valuable because a failed server can often be rebuilt quickly from it. It is not enough by itself because it shares the site. Object storage can provide strong geographic separation, but a full-library restore may incur download charges and take longer than reading a local disk. A remote machine can offer predictable access and familiar filesystem semantics, but it needs its own maintenance and security.
External hard drive: the practical local layer
Choose capacity from your measured library size, expected growth, and retained versions; do not buy a drive based on a generic photo count. Format and mount it so the backup job can identify it reliably, and make sure the backup account can write snapshots without granting unnecessary administrative access.
- Connect or mount the drive only for the scheduled backup window when practical.
- Run the database dump and media snapshot into a dedicated repository on that drive.
- Verify the repository and inspect a sample of original files.
- Record the last successful backup date in a log stored away from the server.
- Unmount and disconnect the drive, or move it to a different secure location, after the job.
If the drive stays permanently attached and writable, ransomware or an accidental deletion can reach it. Rotation between two local drives improves resilience, but at least one still needs an off-site destination to survive a site disaster.
Off-site copies: remote machine, Borg repository, or object storage
Remote machine or Borg repository
Immich’s backup script names a remote machine and BorgBase as examples of off-site destinations. The useful property is not the product name; it is that the repository is separate from the photo server and can retain historical snapshots. Configure encrypted transport, a dedicated repository, and a key that is not stored only on the source host.
Test the path in both directions: upload a small snapshot, list it from an independent device, and perform a restore into a temporary directory. A repository that accepts writes but cannot be read with the recovery key is not a usable backup.
Recommended Free Tools
Rank #4
- 【Versatile Storage Expansion – For Gaming, Work & Everyday Use】 Running out of space on your PS5 or Xbox Series X/S? This external hard drive lets you store and play PS4 / Xbox One games directly, instantly freeing up your console’s internal storage for next‑gen titles. At the same time, it handles work file backups, media libraries, and cross‑device data transfers with ease. One drive, all your needs. *（Note: PS5 / Xbox Series X|S games cannot be run or stored directly from the external hard drive. However, by offloading your PS4 / Xbox One games, you can free up valuable space for newer titles.）*
- 【Patented Silicone Sleeve – Data Protection You Can Count On】 Worried about drops? We’ve got you covered. The patented built‑in silicone sleeve acts like a shock‑absorbing armor, cushioning your drive against bumps and falls. Whether it’s important work documents, precious family photos, or hard‑earned game saves, your data deserves this level of protection.
- 【Plug & Play, Compatible with Computers & Consoles】 No complicated setup—just plug in and go. Works seamlessly with Windows, Mac, and Linux computers, as well as PS4, PS5, Xbox One, and Xbox Series X/S. Process files at the office, back up data at home, or enjoy gaming in your downtime—one drive handles all your devices, simply and hassle‑free.
- 【USB 3.0 Ultra‑Fast Transfer – No More Waiting】 Tired of watching progress bars crawl? With USB 3.0 speeds up to 5Gbps, large files transfer in seconds. Whether you’re moving work documents, transferring hundreds of gigs of games, or backing up a year’s worth of photos, you get more done in less time.
- 【Sleek, Lightweight, and Ready to Go】 Weighing just 0.16 kg—lighter than a can of soda—this compact drive features a stylish mirror‑and‑frosted finish. Toss it in your bag and go, whether you’re heading to the office, visiting a friend for a gaming session, or giving a presentation on the road.
Object storage such as B2
B2 is a generic object-storage category, not a complete backup plan. You need compatible backup software that can create, verify, retain, and restore snapshots. Before committing, calculate:
- monthly storage for current data plus historical versions;
- API or transaction charges generated by your snapshot design;
- egress or download costs for a full disaster recovery;
- time to retrieve the library over your available connection;
- how deletion protection and lifecycle rules interact with your retention policy.
Encryption deserves a separate decision. If the client encrypts data before upload, protect the client key and passphrase outside the server. If the provider uses customer-managed server-side encryption keys, losing an SSE-C key prevents the provider from decrypting the data. Store a recovery copy of the key in a secure offline location and test that a new host can use it.
Protect credentials, keys, and recovery instructions
Backups can fail at the moment they are needed if the only copy of the passphrase is on the dead server. Keep the following in a password manager or encrypted offline record accessible to the people responsible for recovery:
- backup-repository passphrase or encryption key;
- object-storage access credentials and endpoint details;
- customer-managed encryption keys, if used;
- database and application credentials required to rebuild the stack;
- the application version and backup-tool version associated with each repository;
- mount points, ownership requirements, and the order of restore operations.
Do not place unencrypted secrets in a public repository, a screenshot, or the same server that stores the originals. Restrict who can delete snapshots, enable multi-factor authentication where the destination supports it, and alert on failed or unexpectedly small backups.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Restore Immich after a server failure
Practice this procedure before an emergency. Use a spare host, a virtual machine, or a temporary directory so that a test cannot damage production. Follow the restore instructions that match your Immich release; the current guide specifically notes a change in version 2.5.0.
- Prepare a clean host. Install the operating-system and container prerequisites required by your Immich release. Record the exact image tags and configuration used by the failed host.
- Install the matching application version. Do not assume that the newest release can always consume an older database without an upgrade path. Keep the version context with the backup.
- Recreate storage mounts. Restore the internal data folders and every external-library mount at the paths expected by the configuration. A folder copied to a different path is not equivalent if the database still contains the original path.
- Restore the database dump. Use Immich’s documented database restore procedure for the matching release. Confirm that the import completes without errors before asking the application to index or serve media.
- Restore configuration and permissions. Apply compose files, environment settings, ownership, and access permissions. Verify that the containers can read the restored directories.
- Start the services and inspect the catalog. Check users, albums, dates, searches, and a representative sample of photos and videos. Open originals, not only thumbnails.
- Check external libraries separately. Confirm that each mount is present and accessible. If an external path is missing, the database may show references that appear broken even though the files exist in the backup.
- Record the result. Note restore duration, bandwidth used, errors, and any manual fixes. Update the runbook while the details are still fresh.
A restore test should include a recently added photo, an older video, an album, and an item from each external library. This catches path, permission, and incomplete-snapshot problems that a simple container start will not reveal.
Common failure modes and their fixes
“The database backup succeeded, but the photos are gone”
The database dump contains metadata, not the original media. Restore the asset tree and external-library paths from the filesystem snapshot, then restore the database. If no media copy exists, the catalog cannot recreate the originals.
Best Value
- Slim durable design to help take your important files with you
- Vast capacities up to 6TB[1] to store your photos, videos, music, important documents and more
- Back up smarter with included device management software[2] with defense against ransomware
- Help secure your important files with password protection and hardware encryption
- 3-year limited warranty
“The local backup drive failed with the server”
The drive was not independent enough. Replace it with a separate device and add an off-site copy. Keep one local layer for speed, but do not count two devices in the same room as geographic protection.
“The restored app shows missing files”
Check whether the database references a different mount path, whether an external library was omitted, and whether container permissions allow reads. Restore the directory structure expected by the configuration instead of merely placing files somewhere with similar names.
“The backup contains a damaged or already-encrypted state”
Use versioned snapshots so you can select an earlier point. Add an offline or disconnected copy, monitor for unusual changes in file counts and sizes, and test that historical snapshots can be mounted or extracted.
“The cloud copy exists, but recovery is unaffordable or too slow”
Estimate full-restore download costs and time before selecting object storage. Maintain a local recovery copy for routine server replacement and reserve the off-site destination for site-level disasters. Keep the software and credentials needed to perform the download.
“The repository cannot be decrypted”
The encryption key or passphrase was lost. Store a recovery copy independently, document which key belongs to which repository, and perform a decryption test from a clean device. For SSE-C, losing the customer-managed key means the provider cannot decrypt the objects.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsRun a maintenance and test schedule
Automation is useful only when it is observed. Set a calendar that matches the rate at which your library changes and the amount of data you can afford to lose.
- Each backup run: check the exit status, transferred byte count, snapshot creation, and available destination capacity.
- Monthly: restore several files, including a video, from the local repository and verify that they open.
- Quarterly: perform a database-and-files restore into an isolated environment, including an external-library mount.
- After upgrades: review the application’s current backup and restore documentation, especially when crossing a release that changes restore instructions.
- After infrastructure changes: update paths, permissions, compose files, credentials, and the recovery runbook.
Keep at least one test result with the date, software versions, repository identifier, and observed restore time. CISA’s StopRansomware guidance likewise advises maintaining offline, encrypted backups and regularly testing backup procedures.
Quick Recap
A concise implementation checklist
- ☐ Originals and videos are included, not just the application database.
- ☐ Every external-library path and mount is documented and backed up.
- ☐ A supported database dump is created for the application version in use.
- ☐ Database and filesystem data are captured consistently, preferably while the server is stopped.
- ☐ A versioned snapshot tool retains more than one point in time.
- ☐ One copy is on a separate local device for fast recovery.
- ☐ One copy is off-site; an on-site drive alone does not qualify.
- ☐ At least one copy is offline or protected from routine write access.
- ☐ Encryption keys, repository passphrases, and destination credentials are stored separately from the server.
- ☐ The restore procedure, mount structure, permissions, and application version are documented.
- ☐ A test restore has opened original photos, videos, albums, and external-library items.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
