Комментарии 7
Это волшебно!
Давайте по порядку. Во-первых, оригинальная статья была написана для блога на Medium. https://nikolaymatrosov.medium.com/yandex-cloud-cron-snapshot-bdee54c87541
Во-вторых, вы правы, архивация кода и всех зависимостей не самое удобное решение, особенно, учитывая что зависимости нужно паковать для целевой платформы, которая далеко не всегда будет совпадать с платформой, на которой происходит сборка. Поэтому уже давно существует более простое решение: указать на директорию с кодом при помощи ключа --source-path и убедиться, что там есть файл с описанием зависимостей (для NodeJS это package.json). Все остальное за вас сделает yc CLI — соберет zip-архив с кодом, а потом на сервере будет выполнена загрузка указанных зависимостей.
В-третьих, пример, указанный в статье, недавно был актуализирован и переписан с использованием новой версии SDK для NodeJS. Новая версия SDK v2 не является drop-in replacement'ом и еще находится в разработке, но именно на неё я бы рекомендовал ориентироваться в текущий момент. В основном потому что там поддержаны все сервисы Облака, а так же используются свежие версии сторонних зависимостей.
Ну еще одно замечание: долгое время NodeJS SDK был не самым качественным и активно поддерживаемым, поэтому появилась альтернативная реализация, подхода описанного в статье, переписанная на Go.
... А откуда вы знаете, что у вас в бэкапе данные, которые вы бэкапили, а не погода на марсе?
Любой бэкап состоит из пяти компонентов:
Код бэкапа
Код запуска бэкапа (таймеры/крон и т.д.)
Код проверки бэкапа
Код запуска проверки бэкапа
Система мониторинга/алертинга когда предыдущие пункты сломались
Без этого бэкапа нет. Есть абстрактная идея "когда-то два года назад я что-то настраивал", но когда вместо диска улыбающаяся какашка, то абстрактной идеи для восстановления из бэкапа не достаточно, нужны остальные пункты.
Спасибо за ваш едкий комментарий - без него здесь было немного скучно :). С удовольствием отвечу на ваш выпад.
Лично я не сторонник холиваров - бинарно делить жизнь на "черное" и "белое", "бэкапы" и "не бэкапы". Мне любое понятие больше представляется эволюционным вектором 0 - 1: где в точке 0, нет не только бэкапа, но и даже никакой мысли о нем, а в точке 1 - идеальный атомарный проверенный и подписанный бэкап на каждый момент времени с алертами и страховкой от конца света. И эта статья дает возможность сделать неплохой шаг от почти 0 в сторону 1 - от ручного создания снапшотов "когда вспомню", к автоматизированному переодическому, с хранением нескольких версий.
Ну а проверку созданых образов никто не оспаривает - просто это следующий шаг к идеальному бэкапу. Автоматизация такой задачи уникальна для каждого проекта и выходит далеко за рамки данной статьи.
В данном конкретном случае вероятность найти улыбающюся какашку вместо данных несколько снижается из-за количества хранимых версий снапшотов - по моему опыту, чаще всего бывает запорот последний архив - когда сбой уже произошел, но его еще не заметили, а система сделала резервную копию уже испорченных данных.
Поэтому я крайне рекомендую хранить несколько версий снапшотов, и вышеприведенный скрипт не просто удаляет все предыдущие, а только старее чем MAX_DAYS.
Сделанный вручную бэкап лучше, чем непроверенная автоматика №2 (т.к. человек сам себе алертинг). Но без проверки бэкапа человек вполне обнаруживает на месте архива с фотками архив симлинков или превьюшек. Т.е. проверка бэкапа, хотя бы руками и периодическая, это обязательное условие уверенности, что "бэкап есть".
Автоматический backup дисков в Yandex Cloud (с удалением старых версий)