What are we building?

By the end, Immich v3 runs behind your Traefik proxy, reachable at https://photos.YOUR_DOMAIN with valid HTTPS. The official Immich phone app then backs up your new photos and videos automatically to your server – like the cloud backup of Google Photos, except the images live exclusively with you. Via the web interface you browse your timeline, search by full text (“beach”, “dog”) and let Immich group faces.

Immich consists of four containers: the server (web + API), a machine-learning service (for search and face recognition), a PostgreSQL database with a vector extension, and a cache (Valkey). Sounds like a lot – but the official template takes most of it off your hands, and we only hang the server onto Traefik.

The appeal over Google Photos: the images don’t leave your server, there are no storage subscriptions and no automatic analysis of your shots by a corporation. In return, you bear responsibility for operation and – very importantly – for backups: if the server dies and you have no backup, the photos are gone. That’s exactly why the backup below is not optional but mandatory.

Prerequisites

• A running Traefik reverse proxy with the proxy network and the Let’s Encrypt resolver le – see reverse proxy with Traefik.
• A subdomain photos.YOUR_DOMAIN with a DNS record to your server IP – see connecting a domain to your server.
• A backup. Your photo collection is irreplaceable – first set up backups with Restic.

How much RAM your photo library including AI search really needs is calculated by the server calculator.

Step by step

Step 1: Create the DNS record

Create an entry photos.YOUR_DOMAIN that points to your server IP, and check it:

dig +short photos.YOUR_DOMAIN

Your server IP must come back – otherwise Traefik won’t fetch a certificate later.

Step 2: Prepare the folder and .env

Immich is configured via a .env file. Create the project:

mkdir -p ~/immich && cd ~/immich

Create a .env with the core values (set a strong DB password – letters and digits only, no special characters, Immich’s DB init doesn’t like those):

UPLOAD_LOCATION=./library
DB_DATA_LOCATION=./postgres
DB_PASSWORD=YOUR_DB_PASSWORD
DB_USERNAME=postgres
DB_DATABASE_NAME=immich
IMMICH_VERSION=v3.0.3

• UPLOAD_LOCATION – this is where your photos and videos land. It’s the most important directory for the backup.
• DB_DATA_LOCATION – the PostgreSQL data. Must be on a local disk (no network drive/NFS – the DB resents that).
• IMMICH_VERSION – the pinned version.

Step 3: Create the compose.yaml

We adopt the official Immich template and only add the Traefik labels on the immich-server. Create compose.yaml:

name: immich
services:
  immich-server:
    image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION}
    volumes:
      - ${UPLOAD_LOCATION}:/data
      - /etc/localtime:/etc/localtime:ro
    env_file: .env
    environment:
      DB_HOSTNAME: database
      REDIS_HOSTNAME: redis
    depends_on:
      redis:
        condition: service_started
      database:
        condition: service_healthy
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.immich.rule=Host(`photos.YOUR_DOMAIN`)"
      - "traefik.http.routers.immich.entrypoints=websecure"
      - "traefik.http.routers.immich.tls.certresolver=le"
      - "traefik.http.services.immich.loadbalancer.server.port=2283"
    networks: [default, proxy]
    restart: unless-stopped

  immich-machine-learning:
    image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION}
    volumes:
      - model-cache:/cache
    networks: [default]
    restart: unless-stopped

  redis:
    image: docker.io/valkey/valkey:9
    networks: [default]
    restart: unless-stopped

  database:
    image: ghcr.io/immich-app/postgres:14-vectorchord0.4.3-pgvectors0.2.0
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_USER: ${DB_USERNAME}
      POSTGRES_DB: ${DB_DATABASE_NAME}
    volumes:
      - ${DB_DATA_LOCATION}:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${DB_USERNAME} -d ${DB_DATABASE_NAME}"]
      interval: 10s
      timeout: 5s
      retries: 5
    networks: [default]
    restart: unless-stopped

volumes:
  model-cache:

networks:
  default:
  proxy:
    external: true

Important to understand:

• Only immich-server is on the proxy network and carries Traefik labels. The ML service, Valkey and the database stay exclusively on the internal default network – not reachable from outside.
• loadbalancer.server.port=2283 – Immich listens on port 2283 in the container.
• The database is deliberately the prebuilt Immich Postgres image with the vector extension VectorChord (for image search). Don’t just use a standard postgres – the extension is then missing.
• Valkey is the Redis successor; the service is still called redis in the Immich template for compatibility reasons.
• The healthcheck on the database reports when Postgres is really ready. Via depends_on: … condition: service_healthy, immich-server only starts then – this prevents migration errors and the “database not reachable” start on the first boot.

Step 4: Allow large uploads (Traefik timeout)

This is the stumbling block with Immich behind Traefik: by default Traefik aborts connections after 60 seconds (readTimeout). When uploading large videos from the phone this leads to aborted uploads (error 502/499). Increase the timeout on the websecure entrypoint in your Traefik configuration (the traefik service from the Traefik tutorial):

    command:
      # ... your existing lines ...
      - "--entrypoints.websecure.transport.respondingTimeouts.readTimeout=600s"

Restart Traefik afterwards (docker compose up -d in the Traefik folder). Unlike nginx, Traefik has no fixed size limit for uploads – only this timeout has to be high.

Step 5: Start and run through the initial setup

Pull the images (several GB – this takes a while) and start:

docker compose up -d
docker compose logs -f immich-server

The images are several gigabytes in size – the first pull takes a few minutes depending on your connection. Then check that all four containers are running:

docker compose ps

You should see immich-server, immich-machine-learning, redis and database with status running (the database healthy). Wait until Immich Server is listening on http://[::1]:2283 [v3.0.3] appears in the log. Then open https://photos.YOUR_DOMAIN. Traefik fetches the Let’s Encrypt certificate on the first access (be patient for a moment). On the very first start, Immich greets you with “Welcome to Immich” and the choice of whether you start fresh or restore a backup:

Click Getting Started (you only need Restore if you’re importing a backup). Then you create the administrator account – as the first user you automatically become admin:

After the first login, a short setup wizard guides you through theme, language and basic privacy settings:

After that you land on your (still empty) timeline – the heart of Immich:

Step 6: Connect the phone app

The real benefit comes from the app. Install Immich from the App Store or Play Store (or F-Droid). At launch it asks for the server address – enter https://photos.YOUR_DOMAIN and log in with your account. Then, in the app settings, enable the backup and choose the albums to be uploaded.

From now on your phone backs up new photos automatically to your server – in the background and over Wi-Fi. The first pass of a large library takes a while; after that only new shots are added.

After the upload, Immich keeps working in the background: it generates thumbnails, reads the capture metadata (date, location) and lets the ML service recognize faces and index the images for smart search. These jobs run for some time after the first big import – so faces and search hits only appear gradually. You see the progress under Administration → Job queues. In the sidebar you then find the typical photo features: Explore (by people and places), the map with geolocation, albums for sharing and the memories (“a year ago”).

When things go wrong

Maintenance & backups

• Two things belong in the backup – consistently together. Your photos (UPLOAD_LOCATION, i.e. ~/immich/library) and the database. The DB dump contains only the metadata; without the matching files it’s worthless, and vice versa. Cleanest is to stop Immich briefly and back up both together:

  Terminal

  docker compose stop immich-server
  docker compose exec -T database pg_dump --clean --if-exists \
    --dbname=immich --username=postgres | gzip > immich-db.sql.gz
  docker compose start immich-server

  Back up the dump together with the library folder encrypted and off-site with Restic. Alternatively, Immich can generate automatic DB dumps under Administration → Job queues – you still have to back up the photos separately.

• Rehearse the worst case once. A backup you’ve never restored is just a hope. To restore, you import the DB dump into a fresh Immich instance of the same version and place the library folder in the same spot – Immich offers the option “Restore from database” on the first start for this (the second button from step 5). What matters is the same version: the database state and the program must match.

• Backup before every update. Because migrations aren’t reversible, the backup is your only way back. Back up first, then raise IMMICH_VERSION, then docker compose pull && docker compose up -d.

• Honest about the effort: Immich often brings several releases per month. You don’t have to follow every one – but before a jump across several versions, read the release notes, and stick to the pinned version until you deliberately update.

• Keep an eye on disk space. Photos and videos grow steadily; Immich additionally creates thumbnails and converted videos. Monitor the disk usage (e.g. with Uptime Kuma) so the server doesn’t fill up.

What are we building?

By the end, Restic backs up your important data – app volumes, configurations, database dumps – end-to-end encrypted and deduplicated into a repository, ideally off-site (a second server or storage). You can restore individual files or whole snapshots at any time, automatically thin out old backups by a retention policy, and check integrity. Finally, everything runs automatically via a systemd timer and alerts you if a run fails to happen.

Tested with Restic 0.18 (the version from the Debian 13 package sources); upstream already has 0.19.x – how to update is in step 1. Restic always encrypts – there is no unencrypted repository.

Prerequisites

• A server (Debian 13) with the data you want to back up – e.g. the volumes and Compose files of your Docker apps.
• An off-site target for the backups. Restic speaks, among others:
  • SFTP – a second server or a storage box (easiest to start with),
  • S3-compatible – e.g. an object-storage bucket,
  • rclone – as a bridge to Backblaze B2, Google Drive and dozens more.
• Basic familiarity with the shell.

Step by step

Step 1: Install Restic

Restic is in the package sources and is updated with the system:

sudo apt update
sudo apt install -y restic

Check the version:

restic version

restic 0.18.0 compiled with go1.24.4 on linux/amd64

Step 2: Create the encrypted repository

A Restic repository is the encrypted storage location of your backups. It’s protected with a password – and this password does not belong in a script and not next to the repository. Put it in a file only root may read:

sudo install -d -m 700 /etc/restic
openssl rand -base64 32 | sudo tee /etc/restic/password > /dev/null
sudo chmod 600 /etc/restic/password

The openssl command generates a long random password and stores it under /etc/restic/password (the install command before it creates the directory, the chmod after it protects the file). Tell Restic via environment variables where the repository is and where the password is – here first an off-site target via SFTP:

export RESTIC_REPOSITORY="sftp:BACKUP_USER@YOUR_BACKUP_HOST:/backups/YOUR_SERVER"
export RESTIC_PASSWORD_FILE="/etc/restic/password"

Replace BACKUP_USER, YOUR_BACKUP_HOST and the path with your real target. If you want to practice locally first, use a folder instead: export RESTIC_REPOSITORY="/srv/restic-repo". The commands afterwards are identical – only the repository address differs.

You use other off-site targets via the same variable, only with a different prefix:

• S3-compatible: s3:https://ENDPOINT/BUCKET – plus the credentials as AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY in the environment (or in the environment file from step 7).
• rclone: rclone:REMOTE:path – the bridge to Backblaze B2, Google Drive and many more, once you’ve set up the rclone remote.

No matter which backend: encryption, deduplication and all the following commands stay the same.

Now initialize the repository (the example output shows the local practice repository – with the SFTP target, your sftp: address appears there instead):

restic init

created restic repository d29613209a at /srv/restic-repo

Please note that knowledge of your password is required to access
the repository. Losing your password means that your data is
irrecoverably lost.

Step 3: The first backup

Back up the directory with your data. The --tag helps with filtering later:

restic backup /root/backup-demo --tag demo

no parent snapshot found, will read all files

Files:           3 new,     0 changed,     0 unmodified
Dirs:            2 new,     0 changed,     0 unmodified
Added to the repository: 2.002 MiB (2.001 MiB stored)

processed 3 files, 2.000 MiB in 0:00
snapshot f16c6ffd saved

On the second run, Restic’s strength shows: it only backs up the changes (deduplication). If a file changes and you back up again:

using parent snapshot f16c6ffd
Files:           0 new,     1 changed,     2 unmodified
Added to the repository: 1.820 KiB (1.121 KiB stored)
processed 3 files, 2.000 MiB in 0:00
snapshot 0bb5e679 saved

Instead of 2 MiB again, only 1.1 KiB land in the repository – just the changed part.

What belongs in the backup? For Docker apps that’s three things – recipe, payload, DB:

• Compose files (your “recipe”) and .env: small but indispensable for rebuilding the stack.
• Bind mounts (./data:/…) live directly in the project folder – you back those up right along. Named volumes you’ll find under /var/lib/docker/volumes/<name>/_data; include the path.
• Databases never as a live file – a backup mid-write is potentially unusable. Instead create a consistent dump (pg_dump/mariadb-dump) and back that up (see step 7).

You exclude the unnecessary:

restic backup /opt --tag apps --exclude='*.log' --exclude='**/cache/**'

Step 4: Restore

A backup is only as good as its restore. First list the snapshots:

restic snapshots

ID        Time                 Host                  Tags        Paths              Size
---------------------------------------------------------------------------------------------
f16c6ffd  2026-07-16 20:52:35  v2200000000000000000  demo        /root/backup-demo  2.000 MiB
0bb5e679  2026-07-16 20:52:36  v2200000000000000000  demo        /root/backup-demo  2.000 MiB
---------------------------------------------------------------------------------------------
2 snapshots

Restore a complete snapshot to a target directory (use latest for the newest or a specific ID):

restic restore latest --target /root/restore-test

restoring snapshot 0bb5e679 of [/root/backup-demo] ... to /root/restore-test
Summary: Restored 5 files/dirs (2.000 MiB) in 0:00

If you only need one file, there are two ways – restore that specific path:

restic restore latest --target /tmp/wiederher --include /root/backup-demo/config.yaml

… or stream the file directly to standard output, without any detour:

restic dump latest /root/backup-demo/config.yaml > /tmp/config.yaml

To browse, you can even mount the repository as a filesystem (restic mount /mnt/backup, requires FUSE) and copy out what you need in the file manager – handy when you no longer know which snapshot the version you’re looking for is in.

Step 5: Check integrity

check verifies that the repository’s structure is intact:

restic check

load indexes
check all packs
check snapshots, trees and blobs
[0:00] 100.00%  2 / 2 snapshots
no errors were found

That checks the metadata, but not the actual data. So regularly read part of the real data along with it – e.g. 10% per run, i.e. everything over the course of weeks:

restic check --read-data-subset=10%

Step 6: Prune with a retention policy

Without pruning, the repository grows forever. forget applies a retention policy, --prune frees the storage of the removed snapshots:

restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

Applying Policy: keep 7 daily, 4 weekly, 6 monthly snapshots
keep 2 snapshots:
2 snapshots

This keeps the last 7 daily, 4 weekly and 6 monthly snapshots – a good default. The tiers interlock: fine resolution for the recent past (one per day), coarser the further back (one per week, then one per month). So, if in doubt, you can get close to the desired state without the repository growing unbounded. Older snapshots drop off automatically. --prune is the expensive part (it repacks data); on large repositories you often run it only once or twice a week, not on every backup.

Step 7: Automate everything (systemd timer)

A backup you have to start by hand is one you forget. Put the credentials in an environment file (so the service knows them):

# /etc/restic/restic.env
RESTIC_REPOSITORY=sftp:BACKUP_USER@YOUR_BACKUP_HOST:/backups/YOUR_SERVER
RESTIC_PASSWORD_FILE=/etc/restic/password

Then a wrapper script /usr/local/bin/restic-backup.sh – it first dumps the database (PostgreSQL example), backs up, prunes and finally reports success to Uptime Kuma (the push monitor as a “dead man’s switch”):

#!/usr/bin/env bash
set -euo pipefail
# 0) Ensure the target directory for the dump (otherwise the first run aborts)
mkdir -p /opt/dumps
# 1) Dump the database consistently (never back up the live DB file)
docker exec YOUR_DB_CONTAINER pg_dumpall -U postgres > /opt/dumps/db.sql
# 2) Backup
restic backup /opt/apps /opt/dumps --tag auto
# 3) Prune (retention)
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
# 4) Report success to Uptime Kuma
curl -fsS "https://status.YOUR_DOMAIN/api/push/YOUR_TOKEN?status=up&msg=restic+OK" > /dev/null

sudo chmod 700 /usr/local/bin/restic-backup.sh

The service loads the environment file and runs the script – /etc/systemd/system/restic-backup.service:

[Service]
Type=oneshot
EnvironmentFile=/etc/restic/restic.env
ExecStart=/usr/local/bin/restic-backup.sh

And the timer /etc/systemd/system/restic-backup.timer starts it nightly:

[Timer]
OnCalendar=*-*-* 02:30:00
Persistent=true

[Install]
WantedBy=timers.target

Persistent=true catches up a missed run (e.g. because the server was off at night) on the next start. Enable it:

sudo systemctl daemon-reload
sudo systemctl enable --now restic-backup.timer

Check with systemctl list-timers restic-backup.timer when the next run is due.

Step 8: Rehearse the worst case once

A backup you’ve never restored is just a hope. So deliberately run through a complete restore once – ideally on a different or freshly set-up server, so you also need the credentials (repository address and password) under real conditions:

export RESTIC_REPOSITORY="sftp:BACKUP_USER@YOUR_BACKUP_HOST:/backups/YOUR_SERVER"
export RESTIC_PASSWORD_FILE="/etc/restic/password"
restic snapshots
restic restore latest --target /tmp/dr-test

Then compare samples with the original (diff, file hashes) and boot the app from the restored data as a test. Only once that works do you know your backup holds up in an emergency – and that you’ll remember the procedure when it really counts.

When things go wrong

Maintenance & backups

• Test restores regularly – that’s the single most important point. A backup you’ve never restored is not a backup but a hope. Schedule a test restore into an empty directory monthly.
• 3-2-1 rule: at least 3 copies, on 2 different media, of which 1 is off-site. Restic covers the off-site piece – but “off-site” really means a different provider/location, not the same data center.
• Monitor backups: without monitoring, you only notice a dead backup in an emergency. The push call from step 7 to Uptime Kuma raises the alarm when a run fails to happen.
• Check integrity: run restic check --read-data-subset regularly so silent bit rot is caught before you need the data.
• Password/key management: keep the repository password separate from the server. For individual clients you can assign additional passwords with restic key add without sharing the main password.

What are we building?

You get to know the netcup Server Control Panel (SCP) – the web interface to your server – and create a snapshot there: a complete image of your server disk, to which you return in a few minutes if a mishap happens. By the end you know when a snapshot is your rescue – and why it’s still no substitute for a real backup.

Prerequisites

• A netcup server, e.g. your first VPS.
• Your SCP credentials – they are in the netcup welcome email and are different from your SSH login.

Step by step

Step 1: Log into the SCP and find the server

Open servercontrolpanel.de and log in with your SCP credentials. You land in the server list; a click on your server opens the overview with product, status and hardware. At the top you see the tabs through which you control everything – snapshots are under “Media”.

Step 2: Create a snapshot

Go to Media → Snapshots. Under Create snapshot you fill in:

• Name: name it after the why, not the date alone – e.g. before-update-2026-07. That way you later know what it was for.
• Description: one sentence of context (optional, but helpful).
• Disk: usually vda (your system disk).
• Type: here lies the most important decision – see below.

Offline or online snapshot?

• Offline snapshot: the server is briefly shut down for the capture. This guarantees a consistent state – the right choice when databases are running, and when you can afford the brief downtime.
• Online snapshot: capture while running, without downtime. Convenient, but with active writes (e.g. a database mid-write) the image can be inconsistent.

A click on Create starts the process; depending on the amount of data it takes a few minutes. It runs in the background – the creation date and type then appear in the list above once it’s done. Best schedule the brief downtime of an offline snapshot for a quiet time; after that your return point is set and you can tackle the planned change.

Step 3: Restore a snapshot

If something went wrong, you find the snapshot in the list under Snapshots; in the Actions column there’s Restore.

Step 4: The other safety lines in the SCP

The SCP has more than snapshots – good to know for an emergency:

• Display (VNC console): direct screen access to the server, even when SSH refuses – the safety line from the SSH tutorial.
• Rescue system: boots the server into an emergency Linux to repair a broken installation.
• Media → Images / DVD drive: install a different operating system.

When things go wrong

Maintenance & backups

• Snapshot ≠ backup – the most important point. A snapshot lives at netcup, under your account, in one slot and is meant as a momentary snapshot. If the account, the data center or your access fails, it’s gone too. It’s a quick safety net, not an off-site backup.
• Snapshot before every risky action. Before big updates, migrations or delicate config changes: snapshot first, then start. Afterwards you can calmly replace it with the next one.
• Snapshots age. A months-old snapshot brings you back to a long-outdated state – when in doubt, worse than no snapshot. Renew it specifically before every larger action; a fresh return point is worth more than an old one.
• For real safety you need both. Complement the snapshot with encrypted off-site backups – how that works is shown in the tutorial on backups with Restic. Rule of thumb: snapshot for the quick return, Restic for “my server is gone”.