Постійні томи та snapshot-и в Dockup
Постійні томи та snapshot-и в Dockup: вибір шляхів монтування, перевірка використання, створення й планування snapshot-ів, безпечне відновлення та захист даних.
Постійні томи та snapshot-и розв’язують дві різні проблеми. Том зберігає файли під час заміни контейнера й deployment. Snapshot фіксує стан тому в певний момент, щоб оператори могли пізніше перевірити, зберегти або відновити цей стан.
Файлова система контейнера є замінною. Усе, що має пережити deployment — завантаження, згенеровані медіафайли, індекси, артефакти пакетів або файли, якими керує застосунок, — потребує явно визначеного постійного розташування.
Які дані застосунку мають зберігатися в постійному сховищі?
Використовуйте том, коли застосунок володіє файлами, які неможливо дешево або безпечно відтворити з іншого джерела.
| Дані | Том? | Краща альтернатива, якщо доступна |
|---|---|---|
| Завантаження користувачів | Так | Object storage, якщо його передбачає архітектура |
| Згенеровані мініатюри | Можливо | Повторно створювати з оригіналів |
| Пошуковий індекс | Можливо | Повторно побудувати з вихідної бази даних |
| Артефакти збірки | Зазвичай ні | Повторно збирати під час deployment |
| Логи застосунку | Зазвичай ні | Система логування runtime |
| Каталог даних PostgreSQL | Не як том застосунку | Керований PostgreSQL |
| Тимчасовий кеш | Ні | Redis або ephemeral storage |
| Локальна production DB на SQLite | Ризиковано | Керована база даних для concurrency і резервних копій |
Том має мати одного чітко визначеного власника та шлях монтування. Запис до одного каталогу двома непов’язаними процесами ускладнює відновлення й аналіз permissions.
Перш ніж додавати сховище, оцініть початковий розмір, темп зростання, вимоги до зберігання та цільові показники відновлення. Диск враховується щохвилини в межах балансу плану, тому невикористана ємність і неконтрольоване зростання файлів мають свою вартість.
Як створити та перевірити том Dockup?
Перегляньте наявні томи для потрібного service:
dockup volume list production/web --json
Додайте том, указавши назву, абсолютний шлях у контейнері та розмір у гігабайтах:
dockup volume add production/web \
--name uploads \
--path /app/uploads \
--size 20 \
--json
Застосунок має записувати дані в /app/uploads. Запис у /uploads або інший локальний каталог не перенаправляє дані автоматично в mount.
Після deployment переконайтеся, що застосунок записує дані саме в оголошений абсолютний шлях монтування, а не в замінну файлову систему контейнера.
Перевірте фактичне використання диска за допомогою отриманого ID тому:
dockup volume usage <volumeId> production/web --json
Порівняйте фактичне використання з виділеним розміром і метриками застосунку. Налаштуйте сповіщення до того, як файлова система заповниться: переповнений том може спричинити частковий запис, помилки завантаження або падіння застосунку.
Перевірте очікувані ownership і permissions файлів. Користувач runtime контейнера має мати змогу читати та записувати дані в шлях монтування без надання ширших дозволів, ніж потрібно.
Як snapshot-и томів захищають дані?
Snapshot, створений за запитом, фіксує вміст тому:
dockup volume snapshot <volumeId> production/web --json
Перегляньте доступні snapshot-и:
dockup volume snapshots <volumeId> production/web --json
Snapshot-и зчитують том у режимі read-only і не вимагають від застосунку записувати дані в спеціальний каталог snapshot-а. Вони корисні перед ризикованою міграцією файлів, масовим перезаписом медіафайлів або зміною застосунку, яка трансформує збережені дані.
Snapshot тому не є автоматично узгодженим із застосунком. Якщо застосунок активно записує кілька пов’язаних файлів, snapshot може зафіксувати їх у дещо різні моменти. Для керованої бази даних використовуйте систему резервного копіювання керованої бази даних, а не створюйте snapshot її raw data directory.
Визначте, коли застосунок потрібно перевести в quiesced state. Перед створенням важливого snapshot-а може бути доречною коротка пауза обслуговування або запису. Занотуйте ID snapshot-а, причину та очікувану точку відновлення.
Як планувати retention snapshot-ів?
Визначайте час створення та retention snapshot-ів на основі вимог до відновлення, а не за звичкою. Створюйте snapshot за запитом перед кожною ризикованою міграцією файлів, очищенням або зміною формату та записуйте отриманий ID snapshot-а.
dockup volume snapshot <volumeId> production/web --json
dockup volume snapshots <volumeId> production/web --json
| Потреба у відновленні | Практика роботи зі snapshot-ами | Обмеження |
|---|---|---|
| Скасувати міграцію файлів | Створити snapshot безпосередньо перед зміною | Не містить подальших записів |
| Зберігати історичні точки | Зберігати позначені точки відновлення відповідно до policy | Retention потребує регулярного перегляду |
| Захистити часті записи | Додати backup на рівні застосунку, відповідний до даних | Snapshot у певний момент не є безперервним захистом |
| Архів для регуляторних вимог | Використовувати окремий archive workflow | Операційні snapshot-и можуть не відповідати policy |
Перевіряйте, чи справді очікувані snapshot-и існують. Записана policy retention не доводить, що було створено придатну для використання точку відновлення.
Як безпечно відновити snapshot тому?
Відновлення замінює поточний вміст тому та перезапускає контейнер:
dockup volume restore \
<volumeId> \
<snapshotId> \
production/web \
--json
Це disruptive-операція, яка змінює стан. Перед відновленням:
- Підтвердьте потрібний service, ID тому та ID snapshot-а.
- Поясніть, які поточні файли буде замінено.
- За можливості зупиніть або обмежте нові записи.
- Створіть свіжий snapshot поточного стану, якщо він може знадобитися.
- Зафіксуйте сумісність застосунку та схеми.
- Отримайте явне погодження на production.
- Заплануйте перевірку після відновлення.
Після відновлення перевірте стан контейнера та поведінку застосунку:
dockup status production/web --json
dockup logs production/web --json
Перевірте репрезентативні файли, permissions, індекси та посилання з боку застосунку. Успішне виконання команди restore доводить, що snapshot було застосовано, але не доводить, що кожен запис застосунку посилається на коректний файл.
Модель із production guardrails для AI-агентів має розглядати restore як операцію, що потребує погодження, навіть якщо це операція відновлення.
Як томи мають поводитися під час deployment і rollback?
Під час deployment контейнери застосунку замінюються, а змонтований том залишається. Це дає змогу новому image бачити наявні файли, але створює вимогу щодо сумісності.
Нова версія застосунку не повинна незворотно трансформувати збережені файли, перш ніж її release буде перевірено. Якщо вона змінює формати файлів або структуру каталогів, використовуйте міграцію, яку можна продовжити після переривання та яка, де можливо, підтримує backward compatibility.
Rollback застосунку повторно запускає попередній deployment:
dockup deployments production/web -n 20 --json
dockup rollback <deploymentId> production/web --json
Том не відкочується автоматично разом з image. Старий застосунок може не вміти читати файли, трансформовані новою версією. Узгоджуйте rollback image із restore snapshot-а лише тоді, коли обидві операції потрібні та погоджені.
Це розділення важливе:
| Операція відновлення | Змінює image? | Змінює дані тому? |
|---|---|---|
| Deployment нової версії | Так | Ні, якщо застосунок не виконує міграцію |
| Rollback deployment | Так | Ні |
| Restore snapshot-а | Ні | Так |
| Restore плюс rollback | Так | Так |
Процес deployment без простою захищає перемикання трафіку, але не сумісність форматів даних.
Що має містити операційний runbook для постійного сховища?
Призначте власника для кожного production тому. Runbook має містити:
- Цільовий service та ID тому.
- Шлях монтування та очікуваного користувача runtime.
- Виділений розмір і поріг сповіщення.
- Опис даних і можливість їх відновлення через rebuild.
- Розклад snapshot-ів і retention.
- Останній перевірений snapshot.
- Policy погодження restore.
- Кроки валідації застосунку.
- Примітки щодо сумісності image і даних.
- Policy зростання та видалення.
Регулярно перевіряйте використання:
dockup volume usage <volumeId> production/web --json
CPU, RAM і диск вимірюються щохвилини. Free plan надає стартовий кредит $10, а рекомендований Pro plan коштує $20 на місяць і включає $20 кредиту на використання.
Перевірка відновлення snapshot-а
Не чекайте інциденту, щоб з’ясувати, що ніхто не знає, який snapshot вибрати. Проведіть контрольну перевірку на non-production service або погодженій копії:
- Створіть файли, які легко ідентифікувати.
- Створіть snapshot.
- Змініть файли.
- Відновіть snapshot.
- Перевірте вміст і permissions.
- Простежте за перезапуском контейнера.
- Запишіть тривалість і точки відмови.
Перевірка відновлення перетворює постійні томи та snapshot-и з формального пункту в перевірену можливість відновлення.
Для початкового проєктування service дивіться матеріал Від Git-репозиторію до production. Деталі команд наведено в довіднику Dockup CLI.
Визначте цілі відновлення для файлових даних
Recovery point objective відповідає на питання, скільки нещодавніх даних бізнес може втратити. Recovery time objective відповідає на питання, скільки часу може тривати відновлення. Щоденний snapshot із retention семи копій може бути достатнім для внутрішнього медіакешу, але не для продукту із завантаженням користувацьких файлів, який обіцяє durability, близьку до реального часу.
Задокументуйте обидва значення та перевірте фактичну тривалість відновлення. Швидкість створення snapshot-а, розмір даних, перезапуск контейнера, валідація файлів і повторна індексація застосунку — усе це впливає на час відновлення.
Контролюйте видалення та зростання файлів
Постійне сховище може заповнитися, якщо застосунок ніколи не видаляє тимчасові або замінені файли. Додайте policy retention на рівні застосунку та розрізняйте logical deletion і негайне physical deletion. Короткий період відновлення може виправдати відкладене остаточне видалення.
Перед масовим очищенням:
- Виміряйте поточне використання тому.
- Сформуйте список кандидатів на видалення.
- Створіть snapshot.
- Виконуйте очищення обмеженими batch-ами.
- Перевірте посилання з боку застосунку.
- Підтвердьте очікуване звільнення місця.
Це надає постійним томам і snapshot-ам превентивну роль, а не лише роль під час інциденту.
Перевіряйте inventory snapshot-ів
Регулярно перевіряйте ID snapshot-ів, час створення, retention та останній успішний тест відновлення. Налаштована job без нещодавнього придатного snapshot-а — це не система відновлення.
Призначте повноваження на restore
Визначте, хто може погоджувати restore у production і хто виконує валідацію після відновлення. Розділення погодження та виконання зменшує ймовірність того, що поспіх призведе до пропуску перевірки цільового service і snapshot-а.
Почніть із deployment, який можна перевірити
Створіть один non-production том, зробіть snapshot, змініть тестовий файл і завершіть перевірку відновлення, перш ніж зберігати незамінні production-дані.
Почати безкоштовно на app.dockup.ai. Free plan коштує $0 на місяць, включає стартовий кредит $10 і підтримує один workspace, три бази даних та три deployment-и.
FAQ
Чи зберігається том Dockup після deployment?
Так. Том залишається постійним, коли контейнери service замінюються, за умови, що застосунок і надалі використовує налаштований шлях монтування.
Чи є snapshot тому правильним backup для PostgreSQL?
Ні. Hot snapshot каталогу даних бази даних може бути не узгодженим із транзакціями. Для керованих баз даних надавайте перевагу системі резервного копіювання керованої бази даних.
Що відбувається під час відновлення snapshot-а тому?
Поточний вміст тому замінюється вибраним snapshot-ом, а контейнер перезапускається, тому операцію потрібно погодити та перевірити.
Чи може Dockup планувати snapshot-и томів?
Так. Команда планування тому підтримує щоденні snapshot-и з кількістю копій для retention, а розклад можна явно вимкнути.
Чи відкочується том разом із rollback застосунку?
Ні. Історія deployment застосунку та історія snapshot-ів тому є окремими. Узгоджуйте їх лише тоді, коли цього потребує план відновлення.