Что такое снапшот здесь
Копия диска инстанса на конкретный момент времени, снятая на уровне хранилища и записанная в другое хранилище, чем то, на котором работает инстанс. Слоты продаются пакетами; один слот содержит один снапшот и переиспользуется при перезаписи. Снятие снапшота не приостанавливает инстанс, а затраты на copy-on-write в последующие минуты достаточно малы, чтобы редко отражаться на графике задержек.
Это не резервная копия. Снапшот находится на той же площадке, что и инстанс, что защищает вас от ваших собственных rm, но не от площадки. Резервное копирование вне узла — отдельная опция, шифруемая на вашей стороне, записываемая в другой город.
Снятие снапшота
curl -s -X POST https://paragonvps.com/api/v1/instances/<instance-id>/snapshots -H "Authorization: Bearer $Paragon_TOKEN" -H "Content-Type: application/json" -d '{"label":"pre-upgrade"}'curl -s https://paragonvps.com/api/v1/instances/<instance-id>/snapshots -H "Authorization: Bearer $Paragon_TOKEN" | jq -r '.[] | .id + " " + .label + " " + .created'Crash-consistent и когда этого недостаточно
Снапшот работающего инстанса — это ровно то, как выглядел бы диск после отключения питания. PostgreSQL, MariaDB и все журналируемые файловые системы в наших образах восстанавливаются из этого состояния при запуске, потому что восстановление из него — их предназначение. Риск не столько в базе данных, сколько в вашем собственном приложении, которое находится на полпути к записи двух файлов, которые должны согласовываться друг с другом.
Там, где нужна чистая линия, сбросьте и заморозьте том данных на ту секунду, которая нужна:
sync
fsfreeze -f /srv/data
# take the snapshot here
fsfreeze -u /srv/dataЗаморозьте том данных. Никогда не замораживайте /. Замороженная корневая файловая система не даст процессу, который должен её разморозить, сделать вообще что-либо, и единственный выход — жёсткая перезагрузка.
Для базы данных более аккуратный вариант — снять снапшот и дать движку восстановиться, затем проверить, что это произошло:
sudo -u postgres pg_isready
journalctl -u postgresql -n 50Восстановление
Восстановление останавливает инстанс, заменяет диск снапшотом и запускает его снова. Секунды, а не минуты. Адреса не меняются, заданный вами reverse DNS остаётся, а всё, что записано после снапшота, исчезает.
Это включает и то, что побудило вас восстановиться. Если есть хоть какая-то вероятность, что вы захотите прочитать логи из сломанного состояния, сначала снимите снапшот этого состояния, а затем восстанавливайте поверх.
curl -s -X POST https://paragonvps.com/api/v1/snapshots/<snapshot-id>/restore -H "Authorization: Bearer $Paragon_TOKEN"Планирование
Планирование для каждого инстанса появилось в ревизии платформы 5.4. Ежедневно в фиксированный час со скользящим окном — частый выбор: самый старый снапшот удаляется, когда слоты заполнены.
curl -s -X PUT https://paragonvps.com/api/v1/instances/<instance-id>/snapshot-schedule -H "Authorization: Bearer $Paragon_TOKEN" -H "Content-Type: application/json" -d '{"cron":"20 3 * * *","keep":7}'Выбирайте час, который тих для вашей нагрузки, а не для нашей. Стоимость хранения снапшота пропорциональна тому, что меняется после его снятия, поэтому расписание, срабатывающее во время вашей ночной пакетной задачи, хранит гораздо больше данных, чем то, которое срабатывает часом позже.
Отмена инстанса удаляет его снапшоты
Немедленно, без льготного периода, потому что они хранятся вместе с инстансом. Всё, что вы хотите сохранить после отмены, должно находиться в резервной копии вне узла или вообще не у нас.