How to Set Up Separate Backup Jobs for Documents, Photos, and App State

Eva Wong

IceWhale author

Eva Wong is the Technical Writer and resident tinkerer at ZimaSpace. A lifelong geek with a passion for homelabs and open-source software, she specializes in translating complex technical concepts into accessible, hands-on guides. Eva believes that self-hosting should be fun, not intimidating. Through her tutorials, she empowers the community to demystify hardware setups, from building their first NAS to mastering Docker containers.

How to Set Up Separate Backup Jobs for Documents, Photos, and App State

Set up separate backup jobs for documents, photos, and application state because those datasets have different change patterns, consistency requirements, retention needs, and restore procedures.

One giant job is simple to schedule but hard to reason about during failure. A deleted document needs version history, a lost photo library needs durable originals and metadata, and a database-backed app may need a coordinated dump plus configuration before it can start. Separate jobs let each recovery path be tested independently while still sharing the same NAS or offsite target.

Define Recovery Units Before Choosing Backup Tools

Start by listing what must come back together. A document folder may be independently useful as ordinary files. A photo application can require originals plus database state. A self-hosted service may require database dump, configuration, secrets, Compose files, and selected persistent volumes.

A 2026 files, VMs, and databases separates files, virtual machines, and databases by the mechanism needed to recover them. The useful lesson is to organize backups by restore semantics rather than by which top-level folder is easiest to select.

Create a small coverage table with dataset, authoritative source, backup method, schedule, retention, consistency requirement, offsite target, and restore test. Anything that cannot be placed in the table is not yet a complete backup plan.

Give Documents Version-Oriented Retention

Documents are usually small relative to photos and change frequently through edits, renames, and deletions. The main requirement is often the ability to recover an earlier version or an accidentally deleted file, not maximum sequential backup throughput.

Give documents their own destination and retention policy so edits, renames, and accidental deletions can be recovered without inheriting the much larger retention cost of photo archives.

Exclude caches and temporary files that can be recreated, but keep file metadata and permissions when they matter. Restore a changed office document and a deleted folder during testing rather than verifying only that files exist in the repository.

Protect Photo Originals Separately From Rebuildable Derivatives

Photo originals and personal videos are usually large, append-heavy, and difficult or impossible to recreate. Their backup job should prioritize complete authoritative media, efficient incremental transfer, offsite durability, and enough retention to survive accidental deletion.

A 2026 originals, database, and config distinguishes original assets from PostgreSQL state, configuration, and generated derivatives. That separation is useful beyond Immich: a photo app's thumbnails can often be rebuilt, while family originals cannot.

Do not let a media-heavy job delay tiny critical configuration backups. If photo transfer runs for hours, schedule documents and app-state jobs independently so they can still create fresh recovery points.

-15% OFF

ZimaBoard 2 - Mini Home Server for Your Big Idea

Single board computer zimaboard2

Capture App State With Application Consistency

Live application directories can contain transactional databases, caches, locks, queues, indexes, and generated files. A filesystem copy taken while a database is writing can be less trustworthy than a small database-native dump combined with the application configuration.

A practical home-server design for cross-system consistency highlights the difficulty of protecting photos, embedded databases, and service state under one generic copy model.

The related ZimaSpace guide on database-consistent container backups provides the specific boundary: protect a coherent database state before treating the surrounding volume as ordinary files.

Stagger Jobs and Test the Three Restore Paths Independently

Give each job its own account or credentials where practical, destination namespace, log, alert, retry policy, and maintenance window. Stagger large photo backups away from repository checks or database maintenance so one workload cannot silently consume the entire disk or network window.

A 2026 homelab case describing separate backup windows shows why different services are easier to monitor when their database capture, file backup, and offsite stages are explicit.

Perform three restore tests: recover one document version, reconstruct a small photo subset with metadata, and start one application from its saved state on a clean target. Separate jobs are successful only when they reduce recovery ambiguity without leaving hidden dependencies between them.