Бекапимо фотки із Google Photos

March 23, 2025

Готуючись до всесвітнього дня бекапів - 31 березня, переддень жартів на 1 квітня - я знову повернувся до питання із Google Takeout

Що сталося #

Цього разу із акцентом лише на фотографії, бо куплені 200Гб стораджу забилися на 90% саме фото/відео, і надокучливе повідомлення у GMail про те що моя пошта перестане ходити потребує якогось рішення.

Що можна зробити #

Рішень взагалі два:

платити гуглу більше грошей за більше стораджу
зменшити зайнятість існуючого шляхом видалення непотребу.

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

вони займають найбільше місця
не так часто переглядаються як фото
і не так корисні
бекапляться на Synology
- треба оновити статтю про бекапи
доступні також у архівах Google Takeout

Підводні камені #

Якщо я видаляю відео із Google Photos, то значить кожен пізніший бекап (takeout) потенціально може не містити даних, які раніше у Photos були. А це ускладнює бекап - я не можу тепер просто тримати найпізнішу копію тейкауту і сподіватися, що у ній там все є, а доведеться якось це перепаковувати.

Із часів останньої взаємодії із Google Takeout - воно не стало краще - все так же не виходить автоматизувати закачку (на реддіті у когось колись якось працювало, в мене не вийшло) - знову качаю 8 файлів по 50 Гб кожен вручну браузером на ноутбук, а потім із ноутбуку rsync на сервер. Довелося кілька разів перезаливати, бо ноутбук засипав, по просинанню rsync продовжував, але в результаті md5 суми у пари файлів не співпадали.

Хоча, дещо всеж краще стало - сервер тепер (нарешті) підключений по кабелю, а не по WiFi, тому заливалося суттєво швидше.

проблема #

Отже, я маю два (в майбутньому більше) набору архівних файлів, які мені треба стулити в одну папку і не втратити нічого по дорозі - якісь фото могли бути видалені через якість, але якісь (як от відео) - через брак місця. Якісь я може захочу видалити локально, бо вони дублікати і Гугл поклав їх декілька разів у декілька папок (хоча навряд я цим займуся бо по хорошому треба видаливши замінити на relative symlink…. схоже на ще один проект…)

а чому би не гіт? #

Пізньої ночі сонний мозок видав отакий алгоритм:

створити у порожній папці гіт репозиторій та один initial commit
покласти туди першу версію фоток із Takeout-01 і закомітити
покласти (rsync) другу версію фоток із Takeout-02 і подивитися різницю:
- скільки файлів додано
- чи багато змінено
- не очікується видалення взагалі
закомітити другу версію
зацінити скільки часу і інших додаткових ресурсів цей підхід займає
провести переоцінку рішення
якщо переоцінка позитивна, продовжити із Takeout-N+1

Розпакоука #

Сервер не надто швидкий в сенсі як стораджу, так і обчислювальних потужностей: розпаковував 3.5 години

$ time for i in $(\ls *.tgz); do echo $i; tar xf $i -C extract ; done
takeout-20250313T040306Z-001.tgz
takeout-20250313T040306Z-002.tgz
takeout-20250313T040306Z-003.tgz
takeout-20250313T040306Z-004.tgz
takeout-20250313T040306Z-005.tgz
takeout-20250313T040306Z-006.tgz
takeout-20250313T040306Z-007.tgz

real    216m57.269s
user    47m39.655s
sys     113m16.870s

$ ncdu
...
Total disk usage: 316.7 GiB

git add #

додати time до команди git add . я забув, тому ми не дізнаємося точно, як довго це зайняло - занадто пізно збагнув, і перезапускати часу шкода.

Хоча може і дізнаємося, бо є шанс, що місце на розділі закінчиться раніше, аніж я дійду до змоги робити висновки.

Девʼять грьобаних годин #

$ time git add .

real    556m16.660s
user    338m58.527s
sys     77m12.387s

Двісті грьобаних мегабайт #

---------------- .git ---------------
  211.4 GiB [###############] /objects
   15.7 MiB [               ]  index
  176.0 KiB [               ] /hooks
   24.0 KiB [               ] /logs
   12.0 KiB [               ] /refs
   12.0 KiB [               ] /info
   12.0 KiB [               ]  config
   12.0 KiB [               ]  description
   12.0 KiB [               ]  HEAD
   12.0 KiB [               ]  COMMIT_EDITMSG

git тюнинг #

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

Налаштування гіта ось такі

.gitattributes #

не застосовувати дельта-компресію, не мержити, не конвертувати переноси строк для всіх файлів, які тут вказані

[attr]media -diff -merge -text -delta
*.jpg  media
*.jpeg media
*.png  media
*.gif  media
*.heic media
*.mov  media
*.mp4  media
*.webp media
*.m4v  media
*.avi  media

українські імена #

гіт чомусь показував українські імена файлів та каталогів якось на кталт \312\313\554 - що я підозрюю є юнікодом, але ж мені краще звичним читабельним способом. Фікситься отак:

git config core.quotepath false

Висновки #

Ідея в теорії цікава і технічно робоча - на практиці виявилася непрактичною.
Закопати в землю (в .git) 240Гб заради сумнівного бенефіту знати “а що ж мінялося від одної архівації до іншої” - і то коштом досить довгих гітових операцій, здається мені завеликою платою.
Буду просто “перепаковувати” зміст тейкаутових архівів, записувати змінене поверх старого і додавати нове.

Статистика #

git commit #

Ну не так і погано

real 17m56.089s
user 0m7.987s
sys 0m37.107s

git status before adding files #

$ time git status
On branch master
nothing to commit, working tree clean

real 0m22.238s
user 0m0.398s
sys 0m10.211s

add a files from newest takeout #

rsync blablabla
sent 348,875,203,737 bytes  received 3,209,024 bytes  14,322,067.89 bytes/sec
total size is 356,587,688,292  speedup is 1.02

real    405m59.681s
user    37m38.025s
sys     102m19.912s

git status after adding files #

It took 16.44 seconds to enumerate untracked files.
See 'git help status' for information on how to improve this.

no changes added to commit (use "git add" and/or "git commit -a")

real    57m33.692s
user    31m15.525s
sys     12m55.463s