Перейти к основному содержимому

Резервное копирование и восстановление

Рекомендуется стратегия резервного копирования 3-2-1 для защиты данных. Вы должны сохранить копии загруженных фотографий/видео, а также базу данных Immich для обеспечения полной резервной копии. На этой странице представлено руководство по резервному копированию базы данных и местоположению пользовательских загруженных фотографий и видео. Шаблон скрипта bash можно использовать в качестве cron-задачи, он предоставлен здесь

опасность

Инструкции на этой странице показывают, как подготовить ваш экземпляр Immich для резервного копирования, и какие файлы нужно сохранять. Вам все равно необходимо использовать фактический инструмент резервного копирования, чтобы сделать копию данных вручную.

База данных​

осторожно

Immich сохраняет пути к файлам в базе данных, она не сканирует папку библиотеки для обновления базы данных, поэтому резервные копии имеют решающее значение.

информация

Обратитесь к официальной документации postgres для получения информации о резервном копировании и восстановлении базы данных Postgres.

осторожно

Не рекомендуется напрямую создавать резервную копию папки DB_DATA_LOCATION. Если сделать это, пока база данных работает, это может привести к поврежденной резервной копии, которую нельзя восстановить.

Автоматические дампы базы данных​

предупреждение

Автоматические дампы базы данных можно использовать для восстановления базы данных в случае повреждения файлов базы данных Postgres. Нет мониторинга этих дампов, и вы не получите уведомление, если они окажутся неуспешными.

осторожно

Дампы базы данных НЕ содержат никаких фотографий или видео, только метаданные. Они могут использоваться только с копией других файлов в UPLOAD_LOCATION, как указано ниже.

Для целей аварийного восстановления Immich автоматически создает дампы базы данных. Дампы сохраняются в UPLOAD_LOCATION/backups. Обязательно создавайте свою собственную независимую резервную копию базы данных вместе с папками ассетов, как указано ниже. Вы можете настроить расписание и количество сохраняемых дампов базы данных в настройках администратора. По умолчанию Immich сохраняет последние 14 дампов базы данных и создает новый дамп каждый день в 2:00 утра.

Запуск дампа​

Вы можете инициировать дамп базы данных на странице статуса задач администратора. Откройте страницу, выберите модальное окно "Создать задачу" в правом верхнем углу, выберите "Создать дамп базы данных" и нажмите "Подтвердить". Запустится задача и инициирует дамп, вы можете убедиться, что процесс прошел успешно, проверив журналы или папку backups/. Эти дампы учитываются в количестве последних X дампов, которые будут сохраняться на основе ваших настроек.

Восстановление​

Мы надеемся упростить восстановление в будущих версиях, пока что вы можете найти дампы базы данных в папке UPLOAD_LOCATION/backups на вашем хосте. На данный момент выполните шаги, перечисленные в следующем разделе, для восстановления базы данных.

Ручное резервное копирование и восстановление​

Резервное копирование
docker exec -t immich_postgres pg_dumpall --clean --if-exists --username=<DB_USERNAME> | gzip > "/path/to/backup/dump.sql.gz"
Восстановление
docker compose down -v  # ВНИМАНИЕ! Удаляет все данные Immich для новой установки
## Раскомментируйте следующую строку и замените DB_DATA_LOCATION на ваш путь Postgres для полного сброса базы данных
# rm -rf DB_DATA_LOCATION # ВНИМАНИЕ! Удаляет все данные Immich для новой установки
docker compose pull             # Обновление до последней версии Immich (при необходимости)
docker compose create           # Создание Docker-контейнеров для приложений Immich без их запуска
docker start immich_postgres    # Запуск сервера Postgres
sleep 10                        # Ожидание запуска сервера Postgres
# Проверьте пользователя базы данных, если вы отклонились от значения по умолчанию
gunzip --stdout "/path/to/backup/dump.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=postgres --username=<DB_USERNAME>  # Восстановление резервной копии
docker compose up -d            # Запуск остальных приложений Immich

Обратите внимание, чтобы восстановление базы данных прошло правильно, требуется полностью свежая установка (т. е. сервер Immich никогда не запускался с момента создания контейнеров Docker). Если приложение Immich работало, могут возникнуть конфликты Postgres в процессе восстановления базы данных (отношение уже существует, нарушение внешних ключевых ограничений, несколько первичных ключей и т. д.), в таком случае необходимо удалить папку DB_DATA_LOCATION для сброса базы данных.

совет

Некоторые методы деплоя затрудняют запуск базы данных без запуска сервера. В таких случаях вы можете установить переменную окружения DB_SKIP_MIGRATIONS=true перед запуском сервисов. Это предотвратит запуск миграций сервера, которые мешают процессу восстановления. Убедитесь, что вы удалили эту переменную и перезапустили сервисы после восстановления базы данных.

Файловая система​

Immich сохраняет два типа контента в файловой системе: (а) оригинальные, неизмененные активы (фото и видео), и (б) созданный контент. Мы рекомендуем создавать резервные копии всего содержания UPLOAD_LOCATION, но только оригинальный контент является критически важным, который сохраняется в следующих папках:

  1. UPLOAD_LOCATION/library
  2. UPLOAD_LOCATION/upload
  3. UPLOAD_LOCATION/profile

Если вы решите создать резервную копию только этих папок, вам придется заново запускать задачи перекодирования и генерации миниатюр для всех активов после восстановления из резервной копии.

осторожно

Если вы переместили некоторые из этих папок на другое устройство хранения, например profile/, обязательно корректируйте путь резервной копии в соответствии с вашей настройкой

Типы активов и местоположение хранения​

Некоторые местоположения хранения зависят от Шаблона хранилища. См. ниже дополнительные детали.

заметка

Папка UPLOAD_LOCATION/library по умолчанию не используется на новых машинах с версией 1.92.0. Она используется только если системный администратор активировал движок шаблона хранения, подробнее в заметках к релизу.

1. Пользовательские папки:

  • У каждого пользователя есть уникальная строка, которая его представляет.
  • Вы можете найти свой идентификатор пользователя в Настройках аккаунта -> Аккаунт -> Идентификатор пользователя.

2. Типы активов и местоположение хранения:

  • Исходные активы:

    • Оригинальные активы, загруженные через интерфейс браузера, мобильные устройства и CLI.
    • Сохраняются в UPLOAD_LOCATION/upload/<userID>.

  • Изображения аватара:

    • Изображения профиля пользователя.
    • Сохраняются в UPLOAD_LOCATION/profile/<userID>.

  • Миниатюры изображений:

    • Превью изображения (малые миниатюры и крупные предварительные обзоры) для каждого актива и миниатюры для распознанных лиц.
    • Сохраняются в UPLOAD_LOCATION/thumbs/<userID>.

  • Перекодированные активы:

    • Видео, которые были перекодированы из оригинала для широкой совместимости. Оригинал не удаляется.
    • Сохраняются в UPLOAD_LOCATION/encoded-video/<userID>.

  • Postgres

    • База данных Immich, содержащая всю информацию для правильного функционирования системы.
      Примечание: Эта папка будет видна только пользователям, которые внесли изменения, упомянутые в v1.102.0 (определенные, необязательные изменения), или начали использовать эту версию.
    • Сохраняется в DB_DATA_LOCATION.
    опасность

    Резервная копия этой папки не является резервной копией вашей базы данных! Следуйте инструкциям, указанным здесь, чтобы узнать, как выполнить правильное резервное копирование.

опасность

Не прикасайтесь к файлам в этих папках ни при каких обстоятельствах, кроме создания резервной копии. Изменение или удаление ресурса может привести к отсутствующим или неотслеживаемым файлам. Вы можете считать это чем-то вроде обязательного интерфейса: доступ к просмотру, изменению и удалению ресурсов возможен только через мобильное приложение или браузер.

Порядок создания резервных копий​

Резервная копия Immich должна включать как базу данных, так и файлы ресурсов. При создании резервной копии возможно их рассогласование, что может привести к поврежденным ресурсам после восстановления. Лучший способ справиться с этим — остановить контейнер immich-server во время создания резервной копии. Если ничего не изменяется, то резервная копия всегда будет синхронизированной.

Если остановка контейнера невозможна, то рекомендуется сначала создать резервную копию базы данных, а затем файловой системы. В этом случае в худшем случае в файловой системе окажутся файлы, о которых база данных не знает. Если необходимо, эти файлы можно загрузить вручную после восстановления. Если резервная копия создается наоборот (сначала файловая система, затем база данных), то возможно, что восстановленная база данных будет ссылаться на файлы, которых нет в резервной копии файловой системы, что приведет к поврежденным ресурсам.