Сага о семейном фотоархиве
Эпизод II. Воцарение бэкапа.
В начале года я рассказывал вам о том, что за новогодние праздники наконец-то
построил себе решение для автоматической загрузки, надёжного хранения и гибкого поиска фоток и видео в семейном архиве. Оно основано на opensource сервисе Immich, который я развернул в облаке (на VPS) ☁️
И хотя, в целом, решение рабочее (3 месяца полёт нормальный), оно в каком-то смысле убивает саму идею владения своим фотоархивом, ведь теперь основное хранилище
там, в облаке, а доступ к нему может пропасть по 1000 и 1 причине: от банальной неуплаты аренды до глобального сбоя в Интернете. Понимая это, я ещё тогда заказал себе домой сетевое хранилище (NAS) и к нему два одинаковых жестких диска по 2 ТБ, чтобы объединить их в RAID-1 массив и сохранять каждый байт информации дважды на случай отказа одного из дисков. К слову, ждать отказа не пришлось — один из дисков был куплен за полцены по распродаже на Озоне, приехал без гарантийного талона и сдох на первой же массовой записи. Мораль: скупой платит дважды 💰
По моей исходной задумке, данные фотоархива из облака (с VPS) должны быть скопированы домой (на NAS), а затем как-то
автоматически обновляться, чтобы домашняя резервная копия оставалась актуальной. Но когда стал продумывать в деталях, осознал, что не понимаю, как именно они должны "обновляться":
— забирать каждый раз весь архив целиком не вариант, он весит 500 ГБ 🏋️
— значит, нужно переносить только разницу: некий дифф того, что изменилось с последнего переноса 🤏
Здесь важно отметить, что в разницу могут входить не только
добавленные файлы, но и
удалённые, потому что я периодически наведываюсь в архив, чтобы:
—
удалить откровенно неудачные снимки
—
убрать дубликаты, пропущенные машинными обучением
—
стереть фото домов/цветов/котов, которые казались прикольными на момент снимка, а сейчас я даже не помню, где и когда (и на фига) это снято 🧐
Ок, вроде логичное требование, стоит его учесть. Но что если вдруг:
— я с бодуна наудаляю лишнего?
— или Immich сойдёт с ума (из-за бага) и грохнет часть архива?
— или вирус-шифровальщик проникнет на VPS и превратит все фото в тыкву, требуя выкуп?
Придуманное выше
автоматическое обновление во всех этих случаях слепо отразит изменения на домашнюю резервную копию, умножив масштаб проблемы вместо её предотвращения. И, понятное дело, оно не сможет отличить "хорошее" удаление файлов от "плохого" 🤷♂️
Как быть? Решением видится такой компромисс, при котором все изменения всё же будут безусловно отражаться на резервной копии, но эти изменения при случае можно будет
легко откатить. Осталось придумать, как это сделать 😏
Прямую наводку на ответ я нашёл в документации на Immich, в
статье о расширенном резервном копировании. В качестве основного инструмента там предлагается
Borg — бэкапер, написанный на Python. Borg помещает резервируемые файлы в т.н.
репозиторий — версионируемое хранилище в собственном двоичном формате.
Версионность здесь означает, что репозиторий может содержать
множество слепков (версий) исходного архива, но хранятся они не в виде полных копий, а в виде неких
диффов к предыдущим слепкам. Таким образом можно восстановить полное состояние архива на любой момент, для которого в репозитории есть слепок (версия). Дополнительно к этому нативно поддерживаются сжатие и шифрование данных в репозитории. Версии могут именоваться произвольным образом и в этом смысле похожи на коммиты в репозиториях Git, да и вся идея Borg во многом перекликается с Git'ом 🪞
Другая важная для меня фича Borg — работа с
удалёнными репозиториями по SSH. Именно под неё я наконец-то заполучил себе у провайдера "белый" IP, настроил для него проброс порта на роутере и поднял вторую копию Borg на сетевом хранилище. Правда, вскоре после этого у провайдера не неделю отвалился интернет во всем подъезде. Еси чё, это не я 🙄