Постоянни томове и snapshot-и в Dockup

Постоянните томове и snapshot-ите решават два различни проблема. Томът запазва файловете при замяна на container и deployment. Snapshot-ът записва състоянието на тома в определен момент, за да могат операторите да го преглеждат, съхраняват или възстановяват по-късно.

Файловата система на container-а може да бъде заменена. Всичко, което трябва да оцелее при deploy — качени файлове, генерирани медийни файлове, индекси, артефакти от пакети или файлове, управлявани от приложението — трябва да се намира в изрично зададено постоянно местоположение.

Кои данни на приложението трябва да се съхраняват в постоянно хранилище?

Използвайте том, когато приложението притежава файлове, които не могат да бъдат пресъздадени евтино или безопасно от друг източник.

Данни	Том?	По-добра алтернатива, ако е налична
Качени от потребители файлове	Да	Object storage, ако архитектурата го използва
Генерирани thumbnails	Понякога	Генерирайте ги отново от оригиналите
Search index	Понякога	Изградете го отново от source database
Build artifacts	Обикновено не	Изградете ги по време на deployment
Application logs	Обикновено не	Runtime log system
PostgreSQL data directory	Не като app volume	Managed PostgreSQL
Временен cache	Не	Redis или ephemeral storage
Локална SQLite production DB	Рисковано	Managed database за concurrency и backups

Всеки том трябва да има един ясен собственик и mount path. Два несвързани процеса, които записват в една и съща директория, усложняват възстановяването и анализа на правата за достъп.

Преди да добавите storage, изчислете първоначалния размер, темпа на нарастване, изискванията за retention и целта за възстановяване. Дискът се отчита спрямо баланса по плана на минута, така че неизползваният капацитет и неконтролираният растеж на файловете имат цена.

Как създавате и проверявате Dockup volume?

Изведете списък на съществуващите volume-и за конкретната service:

dockup volume list production/web --json

Добавете volume с име, абсолютен container path и размер в гигабайти:

dockup volume add production/web \
  --name uploads \
  --path /app/uploads \
  --size 20 \
  --json

Приложението трябва да записва в /app/uploads. Записването в /uploads или друга локална директория не пренасочва автоматично данните към mount-а.

След deployment проверете дали приложението записва в зададения абсолютен mount path, а не във файловата система на container-а, която може да бъде заменена.

Проверете действителното използване на диска с върнатия ID на volume-а:

dockup volume usage <volumeId> production/web --json

Сравнете реалното използване с разпределения размер и метриките на приложението. Настройте alert преди файловата система да се запълни; пълен volume може да доведе до частични записи, неуспешни качвания или сривове на приложението.

Проверете очакванията за ownership на файловете. Runtime user-ът на container-а трябва да може да чете и записва в mount path-а, без да му предоставяте по-широки права от необходимото.

Как volume snapshot-ите защитават данните?

Snapshot-ът при поискване записва съдържанието на volume-а:

dockup volume snapshot <volumeId> production/web --json

Изведете списък на наличните snapshot-и:

dockup volume snapshots <volumeId> production/web --json

Snapshot-ите четат volume-а в read-only режим и не изискват приложението да записва в специална snapshot директория. Те са полезни преди рискова миграция на файлове, масово преработване на медийни файлове или промяна в приложението, която преобразува съхранените данни.

Snapshot-ът на volume не е автоматично консистентен спрямо приложението. Ако приложението активно записва няколко свързани файла, snapshot-ът може да ги заснеме в леко различни моменти. За managed database използвайте системата за backup на managed database, вместо да създавате snapshot на raw data directory.

Определете кога приложението трябва да бъде quiesced. Кратък maintenance или пауза на записите може да е подходяща преди създаването на важен snapshot. Запишете ID на snapshot-а, причината и очакваната точка за възстановяване.

Как трябва да се планира retention-ът на snapshot-ите?

Изберете времето за създаване и retention-а според изискванията за възстановяване, а не по навик. Създавайте snapshot при поискване преди всяка рискова миграция на файлове, cleanup или промяна на формата и записвайте върнатия ID на snapshot-а.

dockup volume snapshot <volumeId> production/web --json
dockup volume snapshots <volumeId> production/web --json

Нужда от възстановяване	Практика за snapshot-и	Ограничение
Отмяна на миграция на файлове	Създайте snapshot непосредствено преди промяната	Не включва последващите записи
Запазване на исторически състояния	Поддържайте етикетирани точки за възстановяване според policy	Retention-ът изисква активен преглед
Защита на чести записи	Добавете backup на ниво приложение, подходящ за данните	Snapshot в определен момент не е непрекъсната защита
Регулаторен архив	Използвайте специализиран archive workflow	Operational snapshot-ите може да не отговарят на policy

Проверявайте дали очакваните snapshot-и действително съществуват. Написаната retention policy не е доказателство, че е създадена използваема точка за възстановяване.

Как безопасно възстановявате volume snapshot?

Възстановяването заменя текущото съдържание на volume-а и рестартира container-а:

dockup volume restore \
  <volumeId> \
  <snapshotId> \
  production/web \
  --json

Това е disruptive операция, която променя състоянието. Преди възстановяване:

1. Потвърдете точните service, volume ID и snapshot ID.
2. Обяснете кои текущи файлове ще бъдат заменени.
3. Спрете или ограничете новите записи, когато е възможно.
4. Създайте нов snapshot на текущото състояние, ако може да е необходим.
5. Запишете съвместимостта на приложението и схемата.
6. Получете изрично production approval.
7. Планирайте проверки след възстановяването.

След възстановяването проверете състоянието на container-а и поведението на приложението:

dockup status production/web --json
dockup logs production/web --json

Тествайте представителни файлове, правата за достъп, индексите и референциите на приложението. Успешната команда за възстановяване доказва, че snapshot-ът е приложен; тя не доказва, че всеки запис на приложението сочи към валиден файл.

Моделът AI agent production guardrails трябва да третира възстановяването като операция, изискваща approval, въпреки че е recovery operation.

Как трябва да се държат volume-ите по време на deployment и rollback?

При deployment application container-ите се заменят, а монтираният volume остава. Това позволява на новия image да вижда съществуващите файлове, но създава задължение за съвместимост.

Новата версия на приложението не трябва необратимо да преобразува съхранените файлове, преди да е доказано, че release-ът работи. Ако променя файлови формати или структури на директориите, използвайте миграция, която може да бъде възобновена и, когато е възможно, е backward compatible.

Application rollback изпълнява отново по-стар deployment:

dockup deployments production/web -n 20 --json
dockup rollback <deploymentId> production/web --json

Volume-ът не се връща автоматично назад заедно с image-а. Старото приложение може да не може да прочете файлове, преобразувани от новата версия. Координирайте rollback на image-а с restore на snapshot само когато и двете са необходими и одобрени.

Това разделение е важно:

Recovery action	Променя image-а?	Променя данните във volume-а?
Deploy на нова версия	Да	Не, освен ако приложението не ги мигрира
Roll back на deployment	Да	Не
Restore на snapshot	Не	Да
Restore плюс rollback	Да	Да

Процесът за deployment без downtime защитава превключването на трафика, но не и съвместимостта на форматите на данните.

Какво представлява оперативният runbook за durable storage?

Определете owner за всеки production volume. Runbook-ът трябва да съдържа:

• Service target и volume ID.
• Mount path и очаквания runtime user.
• Разпределен размер и праг за alert.
• Описание на данните и възможност за rebuild.
• График и retention на snapshot-ите.
• Последният проверен snapshot.
• Policy за approval при restore.
• Стъпки за валидация на приложението.
• Бележки за съвместимостта между image и данни.
• Policy за нарастване и изтриване.

Проверявайте използването редовно:

dockup volume usage <volumeId> production/web --json

CPU, RAM и disk се измерват на минута. Free plan предлага началeн кредит от $10, а препоръчителният Pro plan струва $20 на месец с $20 кредит за usage.

Тест за възстановяване на snapshot

Не чакайте да възникне инцидент, за да откриете, че никой не знае кой snapshot да избере. Проведете контролиран тест върху non-production service или одобрено копие:

1. Създайте разпознаваеми тестови файлове.
2. Създайте snapshot.
3. Променете файловете.
4. Възстановете snapshot-а.
5. Проверете съдържанието и правата за достъп.
6. Наблюдавайте рестартирането на container-а.
7. Запишете времетраенето и точките на отказ.

Тестът за възстановяване превръща постоянните томове и snapshot-ите от отметка в тествана recovery capability.

За първоначален дизайн на service вижте Git repository to production. За подробности за командите използвайте Dockup CLI reference.

Определете recovery objectives за файловите данни

Recovery point objective показва колко скорошни данни може да загуби бизнесът. Recovery time objective показва колко време може да отнеме възстановяването. Ежедневен snapshot със retention от седем копия може да е достатъчен за вътрешен media cache, но не и за продукт с качване от потребители, който обещава durability почти в реално време.

Документирайте и двете стойности и тествайте действителната продължителност на възстановяването. Скоростта на създаване на snapshot-а, размерът на данните, рестартирането на container-а, валидацията на файловете и reindexing-ът на приложението — всички те допринасят към времето за възстановяване.

Контролирайте изтриването и нарастването на файловете

Постоянното хранилище може да се запълни, защото приложението никога не премахва временни или заменени файлове. Добавете retention policy на ниво приложение и разграничете logical deletion от незабавното физическо изтриване. Кратък recovery window може да оправдае отлагането на окончателното премахване.

Преди да изпълните bulk cleanup:

1. Измерете текущото използване на volume-а.
2. Създайте списък с файловете, подлежащи на изтриване.
3. Създайте snapshot.
4. Изпълнете cleanup-а на ограничени партиди.
5. Проверете референциите на приложението.
6. Потвърдете очакваното освобождаване на място.

Това придава на постоянните томове и snapshot-ите превантивна, а не само инцидентна роля.

Проверявайте inventory-то на snapshot-ите

Преглеждайте по график ID-тата на snapshot-ите, времето на създаване, retention-а и последния успешен тест за възстановяване. Конфигурирана задача без скорошен използваем snapshot не е recovery system.

Определете кой има право да възстановява

Посочете кой може да одобри production restore и кой извършва валидацията след възстановяването. Разделянето на approval от execution намалява вероятността спешността да заобиколи проверката на target-а и snapshot-а.

Започнете с deployment, който може да бъде проверен

Създайте един non-production volume, направете snapshot, променете тестов файл и завършете тест за възстановяване, преди да започнете да съхранявате незаменими production данни.

Започнете безплатно в app.dockup.ai. Free plan е $0 на месец, включва началeн кредит от $10 и поддържа един workspace, три database-а и три deployment-а.

Често задавани въпроси

Запазва ли се Dockup volume при deployment?

Да. Volume-ът остава постоянен, докато service container-ите се заменят, при условие че приложението продължава да използва конфигурирания mount path.

Подходящ backup ли е snapshot-ът на volume за PostgreSQL?

Не. Hot snapshot на data directory на database може да не е transaction-consistent. За managed database предпочитайте системата за backup на managed database.

Какво се случва при възстановяване на volume snapshot?

Текущото съдържание на volume-а се заменя с избрания snapshot и container-ът се рестартира, затова операцията трябва да бъде одобрена и проверена.

Може ли Dockup да планира snapshot-и на volume?

Да. Командата за volume schedule поддържа ежедневни snapshot-и с брой за retention, а графикът може да бъде изрично деактивиран.

Rollback-ът на приложение връща ли автоматично и неговия volume?

Не. Историята на application deployment-ите и историята на volume snapshot-ите са отделни. Координирайте и двете само когато recovery plan-ът го изисква.