SSD Nodes Learn Hosting plans →
Посібники Matt ConnorВід Matt Connor

Як правильно створити резервну копію та відновити Immich

Дізнайтеся, чому копіювання папки Postgres не є надійним методом. Отримайте інструкцію зі створення SQL-дампу та збереження UPLOAD_LOCATION, щоб уникнути порожньої часової шкали.

Що має містити резервна копія Immich

Резервна копія Immich складається з трьох компонентів, створених в один момент. Оригінали в UPLOAD_LOCATION. Дамп бази даних Postgres. .env і docker-compose.yml, що описують стек. Відновлення означає відтворення цього дампа у новій базі даних, коли сервер Immich зупинений, і запуск решти стека лише після цього. Якщо порушити порядок, можна отримати працездатний Immich із порожньою стрічкою на повністю заповненому диску.

Такий поділ важливий, оскільки Immich зберігає свій стан у двох місцях, які нічого не знають одне про одного. Postgres містить кожен альбом, кожен кластер облич, кожне спільне посилання, кожен обліковий запис користувача й API key, а також збережений шлях до кожного asset. Файлова система містить пікселі. Якщо відновити файли без бази даних, Immich нічого вам не покаже. Якщо відновити базу даних без файлів, кожен asset відкриватиметься як пошкоджене зображення.

Наведені тут команди написано для Immich v3.1.0 — релізу, актуального на початку серпня 2026 року. Станом на 2026-10-21 поточним релізом є v3.3.4, опублікований 2026-10-20, а його compose file, образ бази даних і задокументовані кроки резервного копіювання та відновлення відповідають описаним на цій сторінці. Проєкт швидко випускає нові версії, а задокументована процедура резервного копіювання змінювалася неодноразово, тому перед копіюванням перевірте версію, яку ви фактично використовуєте. Якщо стек ще не запущений, почніть із посібника зі встановлення Immich і поверніться сюди.

Визначте, на що вказують ваші шляхи

Дві змінні у .env визначають усе на цій сторінці. UPLOAD_LOCATION — це батьківський каталог, у який Immich записує всі медіафайли. DB_DATA_LOCATION — це каталог даних Postgres.

Стандартний example.env встановлює UPLOAD_LOCATION=./library. Це заплутане значення за замовчуванням, оскільки Immich потім створює в ньому папку з назвою library. Ваші оригінали опиняються в ./library/library. Установіть абсолютний шлях, щоб скрипт резервного копіювання ніколи не залежав від каталогу, з якого його запустили.

UPLOAD_LOCATION=/srv/immich/data
DB_DATA_LOCATION=/srv/immich/postgres
DB_USERNAME=postgres
DB_DATABASE_NAME=immich
IMMICH_VERSION=v3.1.0

У UPLOAD_LOCATION Immich створює кілька папок. Три з них містять дані, які жодне завдання не може відновити:

  • library: оригінали, розкладені відповідно до вашого шаблону зберігання
  • upload: оригінали, які ще не переміщено до структури за шаблоном, а також файли, що завантажуються
  • profile: фотографії профілів користувачів

Якщо втратити library, фотографію буде втрачено. Immich ніде не зберігає другу копію оригіналу.

Чому копіювання каталогу даних Postgres не є резервною копією

DB_DATA_LOCATION виглядає простою ціллю. Це каталог, rsync скопіює його, і копіювання завершиться без помилки. Якщо копіювати каталог під час роботи Postgres, результат не буде резервною копією. Якщо спочатку зупинити Postgres, це буде резервна копія, але ненадійна. Нижче наведено дві причини, і ви можете побачити, як кожна з них призводить до збою.

Перша причина — неузгоджене копіювання. Postgres спочатку записує кожну зміну в журнал попереднього запису (WAL), а потім застосовує її до файлів таблиць під час контрольної точки. Тому в будь-який момент файли на диску перебувають у проміжному стані, а послідовне копіювання тривалістю чотири хвилини прочитає перший файл о 02:00, а останній — о 02:04. Ці два файли не належать до однієї транзакції. Коли ви запустите Postgres із такої копії, він або відмовиться запускатися з помилкою PANIC: could not locate a valid checkpoint record, або запуститься, а потім завершить роботу під час першого читання пошкодженої сторінки з помилкою invalid page in block 1234 of relation base/16384/.... Відновити дані з такої копії неможливо.

Друга причина стосується копії, створеної після повної зупинки сервісу. PostgreSQL вважає повну копію каталогу даних після завершення роботи дійсною резервною копією, але такий каталог можна відкрити лише бінарними файлами, які мають сумісний формат зберігання. Immich фіксує образ бази даних за digest, наразі ghcr.io/immich-app/postgres:14-vectorchord0.4.3-pgvectors0.2.0. Це Postgres 14 із вбудованими розширеннями пошуку векторів VectorChord, pgvector і pgvecto.rs. Пізніший мінорний реліз Postgres 14 може відкрити каталог без змін, але інша мажорна версія Postgres — ні. Розширення, від яких залежать ваші таблиці, також мають бути встановлені в сумісних версіях. На хості відновлення потрібно запустити сумісний образ. SQL dump цього не потребує: це текст, який може відтворити будь-який сумісний сервер.

pg_dump повністю усуває проблему неузгодженого копіювання. Він читає всю базу даних у межах одного знімка MVCC (керування паралельністю за допомогою багатоверсійності), тому бачить базу даних саме в тому стані, у якому вона була в один момент часу, навіть якщо паралельно виконуються інші записи. Саме тому для створення dump не потрібно зупиняти Postgres.

Що можна виключити з резервної копії

Ці дані генеруються повторно, тому їх можна пропустити:

  • thumbs: зображення попереднього перегляду та мініатюри
  • encoded-video: транскодоване відео
  • DB_DATA_LOCATION: відновлюється з дампу
  • Docker-том model-cache: моделі машинного навчання, завантажуються знову за потреби

Пропуск цих даних — це компроміс, а не безкоштовна перевага. Відтворення мініатюр і транскодування для великої бібліотеки — це години роботи процесора на невеликому VPS, і весь цей час на часовій шкалі відображатимуться сірі заглушки. Ви запускаєте їх повторно через Administration > Jobs, встановивши "Generate Thumbnails" та "Transcode Videos" для виконання для відсутніх активів. Якщо на вашому цільовому носії для резервних копій є місце, включіть їх і уникніть очікування. Якщо ви наближаєтеся до ліміту сховища, відмовтеся від них і плануйте час на відновлення. Оцінка розміру бібліотеки Immich описує, наскільки великими стають ці папки відносно оригіналів.

Варто знати ще про одну папку. UPLOAD_LOCATION/backups містить власні автоматичні дампи бази даних Immich, які створюються щодня о 02:00, зберігається останні 14 копій, що налаштовується в Administration > Settings > Database Dump Settings. Вони нічого не коштують і є дійсно корисними. Однак вони знаходяться на тому самому диску, що й бібліотека, яку вони захищають, тому вони допоможуть у разі невдалої міграції, але не в разі виходу сервера з ладу. У будь-якому разі робіть власний дамп, оскільки дамп, ініційований вами, створюється в той самий момент, що й знімок файлів, який до нього належить.

Зробіть дамп бази даних

docker exec -t immich_postgres pg_dump --clean --if-exists \
  --dbname=immich --username=postgres \
  | gzip > /srv/immich/backup/immich.sql.gz

Замініть immich і postgres на ваші DB_DATABASE_NAME і DB_USERNAME, якщо ви їх змінювали. --clean --if-exists додає DROP ... IF EXISTS перед кожним CREATE, тому дамп відновлюється в базу даних, у якій уже є об’єкти, замість того щоб зупинитися на першому з них.

Тепер важлива деталь, яка непомітно руйнує скрипти резервного копіювання. Ця команда є конвеєром, а shell повертає код завершення останньої команди в конвеєрі. Якщо pg_dump завершується з помилкою через неправильний пароль або контейнер, який не запущено, gzip отримує порожній потік, записує цілком коректний gzip-файл і завершується з кодом 0. Скрипт записує успішний результат у журнал, а ви отримуєте резервну копію розміром 20 байт. Додайте pipefail на початок кожного скрипту резервного копіювання:

#!/usr/bin/env bash
set -euo pipefail

Потім перевірте результат, а не покладайтеся на код завершення:

ls -lh /srv/immich/backup/immich.sql.gz
gunzip -c /srv/immich/backup/immich.sql.gz | head -n 3

Перший рядок коректного дампу має вигляд -- PostgreSQL database dump. Файл розміром у кілька сотень байт є невдалим дампом, незалежно від того, що повідомив скрипт.

Запишіть поруч із дампом версію, яка його створила, отримавши її від запущеного сервера:

curl -fsS http://localhost:2283/api/server/version > /srv/immich/backup/immich-version.txt

Цій кінцевій точці не потрібна автентифікація. Вона повертає версію запущеного сервера у форматі номерів major, minor і patch, тому 3, 1 і 0 означають v3.1.0. Не покладайтеся для цього на .env або на docker inspect --format '{{.Config.Image}}' immich_server, який лише виводить посилання на образ, налаштоване вами. Стандартний файл задає IMMICH_VERSION=v3 — плаваючий тег, який відповідає кожному випуску 3.x. Тому запис, що закінчується на :v3, нічого не повідомляє про збірку, яка фактично створила дамп. Також зафіксуйте точний тег у .env.

Призупиніть сервер, а потім створіть знімок за допомогою restic

Файли в UPLOAD_LOCATION не є незмінними під час роботи Immich. Сервер записує нові завантаження, а завдання шаблону сховища переміщує файли між каталогами. Якщо засіб резервного копіювання читає файл під час запису, він зберігає прочитані байти як увесь файл, і жодна помилка не повідомляється. На час виконання операції зупиніть контейнер сервера:

docker stop immich_server

Залиште immich_postgres запущеним, оскільки дамп потребує його роботи. Вебінтерфейс і мобільний застосунок будуть недоступні, доки ви знову не запустите сервер. Для домашнього екземпляра о 03:00 це зазвичай прийнятно.

restic підходить для цього завдання, оскільки дедуплікує та шифрує дані до їх передавання за межі сервера. Вкажіть репозиторій, розташований не на цьому сервері:

export RESTIC_REPOSITORY=sftp:backup@backup.example.com:/srv/restic/immich
export RESTIC_PASSWORD_FILE=/root/.restic-password
restic init

Об’єктне сховище працює так само. Це кращий варіант, якщо копія має зберігатися повністю за межами вашого обладнання:

export RESTIC_REPOSITORY=s3:https://s3.example.com/immich-backup
export AWS_ACCESS_KEY_ID=your-access-key
export AWS_SECRET_ACCESS_KEY=your-secret-key
restic init

Цією кінцевою точкою може бути бакет MinIO, який ви запускаєте самостійно на іншій машині або будь-який S3-сумісний провайдер. Репозиторій на тому самому диску, що й бібліотека, захищає лише від помилкового видалення.

Потім створіть знімок, вказавши саме потрібні дані:

restic backup \
  /srv/immich/backup/immich.sql.gz \
  /srv/immich/backup/immich-version.txt \
  /srv/immich/data/library \
  /srv/immich/data/upload \
  /srv/immich/data/profile \
  /srv/immich/.env \
  /srv/immich/docker-compose.yml
docker start immich_server

restic щоразу читає все дерево каталогів, але передає лише блоки, яких ще не було в репозиторії. Тому перший знімок передає всю вашу бібліотеку, а кожен наступний — нові фотографії за день.

Ретенція та ключі, які потрібно зберігати в іншому місці

restic forget --prune --keep-daily 7 --keep-weekly 5 --keep-monthly 12

forget видаляє snapshot-и з індексу. --prune видаляє дані, на які ці snapshot-и були останніми посиланнями. Запустіть forget без --prune — і витрати на сховище не зменшаться.

Перевірки структури не потребують значних ресурсів, тому виконуйте їх раз на тиждень:

restic check

Це перевіряє узгодженість метаданих репозиторію. Дані при цьому не читаються. Раз на місяць повторно прочитайте вибірку даних і перевірте її за збереженими хешами:

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

Це єдина перевірка, яка виявляє непомітне пошкодження даних у бекенді сховища, оскільки завантажує реальні блоки та повторно обчислює їхні контрольні суми. Повний --read-data для фототеки означає завантаження всього репозиторію. У разі тарифікації об’єктного сховища за обсяг трафіку це коштує значних грошей, тому на практиці використовують ковзну вибірку.

Тепер про те, що часто пропускають. Пароль репозиторію restic неможливо відновити. Немає ані скидання пароля, ані звернення до служби підтримки. Якщо єдина копія зберігається в /root/.restic-password на сервері, який ви намагаєтеся відновити, ваші резервні копії перетворюються на зашифровані дані без можливості використання. Те саме стосується ключа доступу до об’єктного сховища та DB_PASSWORD з .env. Зберігайте все це в місці, яке не залежить від роботи цього комп’ютера: надрукуйте дані та покладіть їх у шухляду або використовуйте менеджер паролів на іншому обладнанні. Якщо цей менеджер також розміщений на власній інфраструктурі, для нього потрібен такий самий підхід, а резервне копіювання Vaultwarden — це окреме завдання.

Відновлюйте Immich у правильному порядку

Саме порядок відновлення може перетворити надійну резервну копію на порожню стрічку. Дотримуйтеся цієї послідовності на новому хості.

Спочатку відновіть конфігурацію. Вона визначає, яку версію запускати і куди вказують шляхи.

restic restore latest --target /restore \
  --include /srv/immich/.env \
  --include /srv/immich/docker-compose.yml \
  --include /srv/immich/backup

Зафіксуйте версію до запуску будь-чого. Прочитайте immich-version.txt, задайте в .env значення IMMICH_VERSION, що точно відповідає цьому релізу (v3.1.0 для major 3, minor 1, patch 0), і поки не використовуйте найновіший реліз. Immich не підтримує downgrade, навіть між patch-релізами, тому якщо новіший сервер запуститься зі старим дампом і виконає свої міграції, повернутися назад буде неможливо.

Відновіть медіафайли.

restic restore latest --target /restore --include /srv/immich/data

Потім перемістіть library, upload і profile так, щоб вони лежали безпосередньо всередині каталогу, на який вказує UPLOAD_LOCATION на цьому хості. Сам шлях на хості може змінитися, оскільки compose file монтує цей каталог у фіксований шлях усередині контейнера. Внутрішня структура цього каталогу не може змінюватися.

Запустіть лише базу даних. Залиште DB_DATA_LOCATION порожнім, щоб Postgres ініціалізував новий кластер.

cd /srv/immich
docker compose pull
docker compose create
docker start immich_postgres
docker exec immich_postgres pg_isready --username=postgres

pg_isready виводить accepting connections після завершення початкового налаштування, яке триває кілька секунд. docker compose create створює всі контейнери, не запускаючи їх, і саме в цьому полягає мета цього кроку: сервер Immich ще не повинен працювати. Якщо сервер запускається з порожньою базою даних, він застосовує міграції, створює нову схему і просить створити новий обліковий запис адміністратора. Після цього ви відтворюєте дамп під запущеним застосунком.

Відтворіть дамп.

gunzip --stdout /restore/srv/immich/backup/immich.sql.gz \
  | sed "s/SELECT pg_catalog.set_config('search_path', '', false);/SELECT pg_catalog.set_config('search_path', 'public, pg_catalog', true);/g" \
  | docker exec -i immich_postgres psql --dbname=immich --username=postgres \
      --single-transaction --set ON_ERROR_STOP=on

Два елементи цієї команди виконують важливу роботу. sed потрібен тому, що pg_dump записує порожній search_path у вихідні дані як запобіжний захід, щоб некваліфіковані імена в дампі не могли посилатися на непередбачену схему. Векторні типи для пошуку Immich містяться в public, тому з порожнім search path відновлення доходить до першого стовпця, оголошеного з vector type, і psql зупиняється з помилкою ERROR: type "vector" does not exist. Повернення public до search path усуває цю проблему.

--single-transaction --set ON_ERROR_STOP=on обгортає все відновлення в одну транзакцію, яка переривається під час першої помилки. У результаті ви отримуєте або повну базу даних, або базу без змін. Без цього помилка посеред процесу залишає базу даних, яка запускається, приймає ваш login і містить невідому кількість відсутніх альбомів; виявити це можна через кілька тижнів.

Тепер запустіть усе.

docker compose up -d
docker compose ps
docker logs -f immich_server

Дочекайтеся рядка запуску на кшталт Immich Server is listening on, потім відкрийте порт 2283 і увійдіть зі своїми старими обліковими даними, оскільки облікові записи користувачів повернулися разом із дампом. Якщо замість цього сторінка входу пропонує створити перший обліковий запис адміністратора, базу даних не відновлено. Зупиніться й знову прочитайте вивід psql.

Є одне застереження щодо офіційних інструкцій відновлення з командного рядка, які починаються з docker compose down -v. -v видаляє іменовані volumes. У стандартному compose file UPLOAD_LOCATION і DB_DATA_LOCATION є bind mounts, тому вони зберігаються. Якщо ви змінили будь-який із них на named volume, ця команда видалить ваші фотографії. Перед виконанням прочитайте свій compose file.

Чому після відновлення шкала часу порожня

Шкала часу формується з рядків бази даних. Immich не переглядає upload/ під час запуску, щоб повторно знайти фотографії, оскільки файл без відповідного рядка не має власника, дати й альбому. Тому найпоширеніша помилка під час відновлення — файли відновлено, а базу даних — ні. Immich запускається, створює порожню схему й надає працездатний екземпляр без даних, хоча диск заповнений вашими фотографіями. Нічого не втрачено. Але нічого не відображається. Виправлення: повторно імпортуйте дамп, коли сервер зупинено, точно як описано вище.

Другий варіант складніше помітити. Базу даних відновлено, шкала часу заповнена записами, але кожен об’єкт не відкривається. Це означає, що рядки вказують на файли, яких контейнер не бачить. Зазвичай library, upload і profile опинилися на один рівень глибше після restic restore --target /restore, який ніхто не перемістив у потрібне місце. Перевірте це зсередини контейнера, а не вгадуйте:

docker exec immich_server ls /data

Стандартний compose-файл монтує UPLOAD_LOCATION у /data, тому цей список має містити library, upload і profile. Якщо він показує порожній каталог або окрему папку srv, bind mount вказує не на той рівень, а рядки бази даних правильні.

Відповідність версій під час резервного копіювання та відновлення

Immich часто випускає нові версії, і схема змінюється разом із ними. Тому дамп містить схему того сервера, який його створив.

Відновлення старого дампу на новішому сервері зазвичай працює, оскільки сервер під час запуску застосовує невиконані міграції та послідовно оновлює схему. Цей шлях перевіряється в межах послідовності релізів. Проблеми виникають, якщо за один крок пропустити кілька основних версій. Проєкт зосереджує несумісні зміни в основних релізах і документує їх у журналі змін.

Відновлення новішого дампу на старому сервері взагалі не працює. Дамп містить таблиці та стовпці, про які старий код не знає. Immich зазначає, що пониження версії не підтримується навіть між patch-релізами. Команди для відкату немає.

Тому безпечне відновлення має бути передбачуваним. Запустіть точно ту версію, яка створила дамп, відновіть дамп, увійдіть у систему та переконайтеся, що вся хронологія доступна. Лише після цього виконуйте оновлення. Оновлюйте по одному релізу за раз: змінюйте IMMICH_VERSION і після кожної зміни запускайте docker compose pull && docker compose up -d. Зберігати дампи за тиждень також корисно: якщо виявиться, що найновіший дамп створено під час невдалого оновлення, учорашній дамп усе ще буде в репозиторії.

Перевіряйте резервну копію щомісяця

Резервна копія, з якої ви ніколи не виконували відновлення, є лише припущенням. Раз на місяць відновлюйте її в тимчасовому екземплярі та переглядайте фотографію. Така перевірка займає близько двадцяти хвилин. Лише вона перетворює решту цієї сторінки на план відновлення.

restic snapshots
restic stats latest

snapshots має показувати запуск минулої ночі. stats latest має повідомляти розмір, близький до розміру вашої бібліотеки, а не кілька мегабайтів.

Відновлюйте дані в тимчасовий каталог, бажано на резервному хості:

restic restore latest --target /tmp/immich-drill

Скопіюйте docker-compose.yml і .env із відновленого набору, а потім змініть у копії три речі. Вкажіть для UPLOAD_LOCATION і DB_DATA_LOCATION каталоги всередині /tmp/immich-drill. Опублікуйте вебпорт на іншому порту: 12283:2283 замість 2283:2283. Видаліть рядки container_name:, оскільки стандартний compose-файл жорстко задає імена на кшталт immich_server. Через це другий стек на тому самому хості конфліктує з першим, і Docker відмовляється його створювати.

Виконайте описану вище послідовність відновлення: спочатку лише базу даних, потім відтворіть дамп і виконайте docker compose up -d. Тепер виконайте чотири перевірки, які підтверджують результат.

  1. Увійдіть із паролем, який використовували до перевірки. Якщо облікові записи працюють, дамп відновлено.
  2. Відкрийте часову шкалу та прокрутіть її до найстарішого місяця. Якщо ресурси охоплюють увесь діапазон дат, відновлено всі рядки, а не лише останні.
  3. Відкрийте одну фотографію в повному розмірі та завантажте оригінал.
  4. Порівняйте його з тим самим файлом у робочій бібліотеці за допомогою sha256sum. Однакові хеші означають, що байти збереглися під час проходження через restic і зворотного відновлення.

Після цього видаліть результати перевірки за допомогою docker compose down -v у каталозі перевірки та видаліть /tmp/immich-drill. Запишіть дату там, де ви її побачите, оскільки цінність цієї процедури повністю залежить від повторення наступного місяця. Якщо ви ще вирішуєте, який фотосервер обрати, порівняння PhotoPrism та Immich пояснює, чим вони відрізняються саме в цьому аспекті.

FAQ

Чи потрібно зупиняти Immich для створення резервної копії?

Зупиніть immich_server, а immich_postgres залиште запущеним. Базу даних не потрібно призупиняти, оскільки pg_dump читає дані в межах одного знімка MVCC і бачить один узгоджений момент незалежно від інших операцій запису. Причина зупинити сервер — файли: сервер записує нові завантаження, а завдання шаблону сховища переміщує файли між каталогами. Тому засіб резервного копіювання може прочитати файл під час запису й без помилки зберегти його неповну копію. Виконання docker stop immich_server перед знімком і docker start immich_server після нього усуває цю проблему синхронізації.

Чи можна скопіювати каталог даних Postgres замість запуску pg_dump?

Ні, якщо Postgres працює. Копіювання активного каталогу даних у процесі роботи читає різні файли в різні моменти. Тому результат не відповідає одному узгодженому стану. Під час запуску Postgres відхиляє таку копію з помилкою PANIC: could not locate a valid checkpoint record або пізніше завершує роботу через пошкоджену сторінку. Повна копія, створена після зупинки Postgres, є коректною резервною копією, але її можна відкрити лише тією самою основною версією Postgres і сумісними розширеннями. Immich використовує образ Postgres 14 із VectorChord, pgvector і pgvecto.rs, тому цей каталог не відкриється в іншій основній версії. SQL-дамп є звичайним текстом і відновлюється на будь-якому сумісному сервері, тому саме його слід зберігати.

Чому після відновлення порожня часова шкала Immich?

Тому що часова шкала формується з рядків бази даних, а ви відновили файли без бази даних. Immich не сканує upload/, щоб повторно знаходити фотографії, тому файли без відповідних рядків залишаються невидимими. Самі фотографії не пошкоджені. Зупиніть сервер, відновіть дамп у щойно ініціалізований Postgres, а потім запустіть стек. Якщо часова шкала заповнена, але кожна фотографія не відкривається, причина протилежна: library, upload і profile не знаходяться безпосередньо в каталозі, підключеному до контейнера. Перевірте це за допомогою docker exec immich_server ls /data.

Які каталоги Immich можна не включати до резервної копії?

thumbs і encoded-video відновлюються з оригіналів, а DB_DATA_LOCATION повторно створюється з дампа, тому жоден із них не потрібно включати до набору резервної копії. Пропуск цих каталогів потребує часу після відновлення, але заощаджує місце до нього, оскільки повторне створення preview і transcode для великої бібліотеки займає години CPU. Це можна запустити через Administration > Jobs для відсутніх assets. Не можна пропускати library, upload і profile, оскільки саме вони містять єдину копію кожного оригіналу.

Чи можна відновити дамп Immich у новішій версії?

Зазвичай так, оскільки сервер під час запуску застосовує очікувані міграції та послідовно оновлює схему. Зворотна операція не працює: Immich не підтримує пониження версії, навіть між patch releases, тому дамп із новішого релізу не можна завантажити у старіший сервер. Для відновлення зафіксуйте IMMICH_VERSION на релізі, який створив дамп, перевірте повноту часової шкали, а потім виконайте оновлення. Записуйте реліз поруч із кожним дампом за допомогою curl -fsS http://localhost:2283/api/server/version, оскільки docker inspect лише виводить налаштоване посилання на образ, а стандартний IMMICH_VERSION=v3 є плаваючим тегом і не дає потрібної інформації.

#immich#backups#restic#postgres#disaster-recovery