Куди подіти 100+ ГБ фото зі смартфона: власна галерея Immich

Коли галерея смартфона виростає до 100–200 ГБ, проблема вже не зводиться до кнопки «звільнити місце». Частина фото може бути в Google Photos або iCloud, частина — у DCIM, месенджерах, на старому ноутбуці чи NAS. Якщо просто скопіювати все на новий сервер і одразу очистити телефон, легко отримати дублікати або, гірше, втратити єдиний оригінал.

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

Перш ніж переносити 100 ГБ: з’ясуйте, де насправді лежать оригінали

Перед перенесенням великої фототеки потрібно спочатку визначити, де лежать оригінали й чи є хоча б одна незалежна копія. На Android варто перевірити не лише DCIM/Camera, а й Pictures, Screenshots, каталоги Telegram, WhatsApp та інших застосунків. На iPhone окремо треба врахувати режим оптимізації сховища iCloud: не всі файли, які видно у «Фото», обов’язково зберігаються на пристрої в повному розмірі.

Корисно скласти просту карту даних: «є лише на телефоні», «вже скопійовано на ПК/NAS», «зберігається у хмарі», «можна не переносити». Цей крок здається бюрократією, поки не з’ясовується, що частина відео вже продубльована, а деякі старі фото існують лише в одному місці.

На Linux-сервері обсяг майбутнього сховища зручно звірити командою df -h, а на диску з уже зібраним архівом — du -sh /path/to/photos. Порівнювати варто не лише гігабайти, а й приблизну кількість файлів. 100 ГБ зайнятого місця на смартфоні не дорівнюють автоматично 100 ГБ чистої фототеки: там можуть бути кеші, локальні копії з месенджерів та дублікати.

Найнебезпечніший момент міграції — не копіювання, а видалення старої копії до перевірки нової.

Де запускати Immich: домашній ПК, NAS чи VPS

Починати вибір сервера для Immich варто не з кількості ядер, а з обсягу фототеки, доступності сервера та темпу приросту даних. Для 100+ ГБ медіа диск часто важливіший за «запас процесора»: бібліотека росте, Immich створює службові дані й мініатюри, а під час первинної індексації потрібен запас оперативної пам’яті.

Для Immich потрібен сервер із Docker, достатнім обсягом оперативної пам’яті та дискового простору. Це може бути домашній міні-ПК, NAS або VPS із готовим Docker-середовищем. Вибір залежить насамперед від того, де фізично зберігатимуться оригінали, чи потрібен доступ поза домом і скільки нових фото та відео додається щомісяця.

Перед розгортанням перевірте free -h, df -h, docker --version і docker compose version. Якщо на диску рівно 120 ГБ вільного місця, а архів уже займає 110 ГБ, такого запасу недостатньо для робочої системи. Залишайте простір під нові файли, мініатюри, базу та операції оновлення.

Найважливіше до встановлення: правильно розмістити фото та базу даних

Перед масовим імпортом Immich потрібно перевірити UPLOAD_LOCATION і DB_DATA_LOCATION. Помилка майже непомітна на десяти тестових фотографіях, але стає критичною, коли 100 ГБ починають записуватися на невеликий системний SSD.

У типовій конфігурації UPLOAD_LOCATION задає місце для бібліотеки та пов’язаних файлів Immich, а DB_DATA_LOCATION — місце даних PostgreSQL. Їх не варто сприймати як один і той самий каталог. Медіатека може лежати на великому диску, а база — на локальному SSD. Для PostgreSQL мережеві файлові системи не підходять; каталог БД краще тримати на локальному сумісному сховищі.

Перед запуском перевірте диски командами lsblk і df -h, а потім звірте фактичні значення у .env. Після змін корисна команда docker compose config: вона показує підсумкову конфігурацію Compose і допомагає помітити неправильний шлях ще до імпорту.

Практична схема для домашнього сервера часто проста: невеликий SSD для системи та PostgreSQL, окремий місткий диск для фототеки. На NAS або сервері з кількома дисками логіка та сама: спочатку визначаємо, куди реально змонтований volume, і лише потім «заливаємо» архів.

Розгортання Immich: мінімум команд перед першим входом

Для робочого встановлення Immich основним сценарієм є Docker Compose. Тут немає сенсу переказувати весь курс Docker: перед великим переносом достатньо правильно підготувати docker-compose.yml і .env, запустити контейнери та переконатися, що вони стабільно працюють.

docker compose up -d
docker compose ps
docker compose logs --tail=100

Якщо контейнер перезапускається або сервер не відкривається, дивіться журнали до початку імпорту. За потреби можна стежити за логом сервера в реальному часі:

docker compose logs -f immich-server

У сучасній конфігурації Immich використовується команда docker compose; старий синтаксис docker-compose не варто брати за основу з давніх інструкцій. Після першого входу створіть адміністратора і зробіть коротку контрольну перевірку: завантажте 5–10 фото та одне відносно велике відео. Перевірте відкриття оригіналів, мініатюр і метаданих. Лише після цього починайте великий імпорт.

Як перенести десятки тисяч фото й не отримати бібліотеку з дублікатами

Спосіб міграції треба вибирати за місцем, де вже лежать оригінали. Якщо 100+ ГБ знаходяться переважно на телефоні, логічний шлях — мобільне резервне завантаження. Якщо архів уже роками впорядкований на NAS або диску сервера, копіювати ті самі 100 ГБ ще раз часто немає сенсу: їх можна підключити як External Library.

Оригінали переважно на смартфоні

Не запускайте першу синхронізацію «на ніч і подивимося». Спочатку виберіть потрібні альбоми, завантажте невелику групу, перевірте дати, геодані, відео та кілька старих фото. Якщо все виглядає правильно, можна продовжувати повний backup. Такий контроль особливо корисний, коли в галереї змішані Camera, Screenshots, Downloads і каталоги месенджерів.

Архів уже лежить на NAS або сервері

External Library дозволяє Immich індексувати файли поза власним каталогом завантажень. Для першого підключення цінного архіву розумно змонтувати його лише для читання, наприклад із суфіксом :ro. Immich бачитиме файли, але не зможе видаляти чи змінювати оригінали на диску. Для першого сканування старого архіву це хороший запобіжник.

Після додавання шляху в Administration ? External Libraries запустіть сканування та перевірте Administration ? Jobs. Під час великого імпорту мають відпрацьовувати завдання, пов’язані з бібліотекою, створенням мініатюр та вилученням метаданих. Для вже впорядкованого архіву це значно акуратніше, ніж робити 100 ГБ зайвого I/O лише для того, щоб Immich побачив файли.

Частина фото вже потрапила в Immich

Найскладніший випадок — коли один і той самий архів частково завантажували з телефона, частково копіювали вручну, а потім підключили зовнішню бібліотеку. Мобільний backup обчислює checksum файлу й не завантажує повторно asset, який сервер уже розпізнав. Але для External Library перевірка дублікатів не є глобальною між усіма бібліотеками: однаковий файл із різних джерел може з’явитися у стрічці двічі. Тому перед підключенням наступної папки перевіряйте кілька дат, кількість файлів і джерела імпорту.

Як зробити так, щоб нові фото зі смартфона копіювалися автоматично

Автоматичне копіювання зі смартфона потрібно перевіряти контрольним фото, а не лише написом «Backup увімкнено». На iPhone перевірте Background App Refresh, а на Android — чи не присипляє Immich системна оптимізація батареї. Якщо синхронізація нормально стартує лише після ручного відкриття застосунку, починати діагностику варто саме звідси.

У мобільному Immich виберіть каталоги, які справді потрібно зберігати. Camera зазвичай очевидний кандидат, а Screenshots, Downloads, меми та медіа з месенджерів варто підключати лише свідомо. Інакше власна фотогалерея швидко перетвориться на склад кожної картинки, яку колись відкрив телефон.

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

Міграцію роблять один раз. А завантаження нових фото має працювати постійно — інакше через кілька місяців пам’ять телефона знову закінчиться.

Immich працює вдома, але не зі смартфона через мобільний Інтернет

Якщо Immich відкривається у домашній мережі, але недоступний через LTE/5G, проблема зазвичай не в самій фототеці, а в схемі зовнішнього доступу. Для сервера, який має бути доступний з Інтернету, потрібні HTTPS і коректно налаштований reverse proxy або приватний доступ через VPN.

Для Nginx важливо дозволити достатній розмір запиту та не обривати тривале передавання. Типовий симптом: невелике фото завантажується, а велике відео падає з помилкою. Тоді насамперед перевіряйте client_max_body_size, тайм-аути проксі та журнали, а не починайте змінювати налаштування самої фототеки.

HTTP 413 прямо підказує перевірити обмеження розміру запиту. Якщо великі відео щоразу обриваються приблизно через однаковий проміжок часу, варто дивитися timeout і proxy logs. Коди 499 або 502 також допомагають відокремити проблему проксі чи мережі від проблеми Immich.

Домашній сервер не обов’язково публікувати у відкритий Інтернет. Якщо доступ потрібен лише власнику та кільком пристроям, VPN-схема може бути практичнішою. Головне — перевіряти віддалений доступ окремо від локального: Wi-Fi в тій самій мережі нічого не каже про те, чи працюватиме backup у дорозі.

Immich не замінює резервну копію: що потрібно зберігати окремо

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

Для відновлення важливі дві складові: самі медіафайли та база PostgreSQL, де зберігаються дані про бібліотеку. Вбудовані резервні копії бази не замінюють резервування фотографій і відео. Автоматичний dump PostgreSQL у UPLOAD_LOCATION/backups теж потрібно копіювати на інший носій: копія на тому самому сервері не захистить від втрати його дисків. Мінімально безпечна схема — окрема копія медіатеки плюс копія БД на незалежному сховищі.

Для автоматизації можна використовувати Borg, Restic або інший інструмент, якому ви довіряєте. Сенс не в конкретній програмі, а в незалежності копії та можливості відновлення. RAID теж не закриває це питання: одна система з кількома дисками все одно не захищає від випадкового видалення, помилки адміністратора або втрати самого сервера.

Перевірка проста: якщо цей сервер сьогодні зникне, звідки відновлювати фото та базу Immich? Якщо відповіді немає, резервної копії фактично немає. Перенести фото з телефона на сервер — це міграція. Мати ще одну незалежну копію — це backup.

Коли вже можна видаляти 100 ГБ зі смартфона: контрольний чек-лист

Очищати смартфон варто лише після перевірки всієї схеми, а не одразу після появи мініатюр у Immich. Перед видаленням великого архіву пройдіться по короткому чек-листу.

• У Immich видно старі й нові фотографії з різних років.
• Відкриваються оригінали, а не лише мініатюри.
• Перевірено кілька великих відео.
• Кількість і приблизний обсяг файлів виглядають правдоподібно.
• Нове фото зі смартфона автоматично потрапляє на сервер.
• Віддалений доступ перевірено через мобільний Інтернет, якщо він потрібен.
• Є незалежна резервна копія медіафайлів.
• Є резервна копія PostgreSQL.
• Зрозуміло, на якому фізичному диску лежить UPLOAD_LOCATION.
• На сервері залишається нормальний запас вільного місця.

Free Up Space: автоматичне очищення після перевірки backup

Коли копіювання перевірене, у мобільному Immich можна скористатися Free Up Space. Функція знаходить локальні фото й відео, які вже успішно збережені на сервері, і дає переглянути список перед видаленням. Це зручніше за ручне полювання на тисячі старих файлів, але запускати очищення варто лише після перевірки сервера та незалежної резервної копії.

На iPhone з iCloud Photos є принциповий нюанс: iCloud працює як двостороння синхронізація, тому видалення локального фото через Free Up Space також може видалити його з iCloud та інших пристроїв Apple. Якщо iCloud використовується як друга копія, безпечніше не змішувати ці сценарії без перевірки. На Android окремо перегляньте альбоми месенджерів: після видалення локальних файлів WhatsApp медіа в історії чатів може стати недоступним або розмитим, тому такі каталоги краще виключати з очищення, якщо вони потрібні всередині самого месенджера.

Для швидкої діагностики корисно тримати під рукою ще одну таблицю:

Навіть після цього не обов’язково видаляти 100 ГБ одним рухом. Почніть із невеликої групи вже перевірених фото, переконайтеся, що вони лишилися доступними в Immich і в резервній копії, а потім переходьте до решти. Спочатку перевірка, потім видалення — у цьому сценарії обережність дешевша за будь-яке відновлення даних.