Cotton считает артефакты бэкапа БД частью операционной модели продукта. Дамп PostgreSQL можно разбить на чанки, сохранить через хранилище Cotton, найти по метаданным последнего бэкапа, проверить и использовать для восстановления на старте, когда база пустая.
Cotton может периодически создавать дампы PostgreSQL и складывать получившиеся артефакты бэкапа через свой конвейер хранения. Байты бэкапа не превращаются в загадочную папку сбоку от модели продукта.
Поиск бэкапа опирается на метаданные, а не на угадывание по имени файла. Cotton может держать манифест и записи-указатели на последний бэкап, чтобы восстановление на старте нашло нужный артефакт.
Админы могут запустить задачу бэкапа по требованию через серверный API, когда нужна немедленная контрольная точка перед рискованным шагом обслуживания или обновлением.
Когда явно включён режим восстановления пустой базы, Cotton на старте проверяет, пуста ли база, находит манифест последнего бэкапа, собирает дамп из сохранённых чанков, проверяет целостность по хешу и размеру и восстанавливается автоматически.
Путь восстановления не должен вслепую залить любые байты, какие есть. Cotton проверяет размер и хеш бэкапа перед восстановлением, чтобы повреждение стало сигналом к восстановлению, а не тихим частичным импортом.
После авто-восстановления Cotton проверяет наличие нужных расширений PostgreSQL и шлёт админу уведомление с высоким приоритетом и метаданными бэкапа. Оператор должен знать, что восстановление произошло и какой артефакт использован.
Путь бэкапа конкретный: дамп PostgreSQL, чанковый артефакт хранилища, указатель на последний бэкап, манифест бэкапа, проверка по хешу и размеру, восстановление пустой базы на старте, проверка расширений и уведомление админу с высоким приоритетом.
Cotton проще эксплуатировать, когда восстановление — не сноска в README. Бэкапы БД видны как часть операционной модели и привязаны к той же дисциплине хранения, которая защищает обычный контент.
Восстановление БД из своего хранилища полезно, но не заменяет проверенные бэкапы вне сервера. Полная потеря хоста, сломанное хранилище, неправильное хранение ключей, ошибки оператора, ransomware и аварийное восстановление всё равно требуют внешнего плана бэкапа. Бэкап, который ни разу не восстанавливали, — это не бэкап, а гороскоп.
Рассказ Cotton про бэкапы операционный, а не театральный. Он даёт приложению слой восстановления на уровне продукта, но не притворяется, что заменяет скучную дисциплину внешних бэкапов, которая всё равно нужна серьёзным операторам.
Cotton создаёт дамп PostgreSQL через серверную задачу бэкапа.
Дамп становится чанковыми артефактами бэкапа внутри хранилища Cotton.
Указатель на последний бэкап и метаданные манифеста определяют кандидата на восстановление.
Восстановление сверяет хеш и размер, прежде чем доверять собранному дампу.
Пустую базу можно восстановить на старте, когда это явно настроено.
Админы получают высокоприоритетные метаданные восстановления после авто-восстановления.
Путь восстановления при старте должен жить за COTTON_RESTORE_DATABASE_IF_EMPTY=true и проверкой пустой базы. Обычный рестарт не должен перезаписывать существующую базу только потому, что бэкап есть.
Нет. Задуманный путь — явно настроенное восстановление пустой базы. Существующие базы нельзя перезаписать просто потому, что приложение перезапустилось и бэкап существует.
Нет. Это полезный слой восстановления на уровне продукта, но серьёзным развёртываниям всё равно нужны проверенные бэкапы вне сервера на случай полной потери машины, потери хранилища, потери ключей или ошибок оператора.
Так артефакты бэкапа остаются в той же защищённой модели хранилища: чанки, метаданные манифеста, поиск последнего указателя и проверка целостности — вместо отдельного, ни с чем не связанного файла дампа.
Уведомление с высоким приоритетом и метаданными, которых достаточно, чтобы понять: авто-восстановление произошло и какой артефакт бэкапа использован.