Backup, който наистина използвате
Повечето компании откриват, че backup-ът им не работи, едва когато настъпи бедствие. Затова препоръчваме backup-ът да се третира като процес, а не като отметка: автоматични копия, съхранявани далеч от продукционния сървър, и редовно тествани възстановявания. На cPanel дневният backup се изпълнява автоматично и го възстановявате от панела; на VPS и dedicated сървъри екипът по DevOps може да настрои планирани тестове за възстановяване от включените ви часове.
Какъв backup включва всеки план
cPanel хостингът има автоматичен дневен backup, който възстановявате от панела. VPS има снапшоти — пълни копия на състоянието на сървъра — без гарантирана честота. Dedicated сървърите не включват backup по подразбиране: NVMe дисковете са по двойки, а RAID се настройва при инсталацията, но RAID не е backup. Външният backup, PITR за базите данни и тестовете за възстановяване се настройват от нашия екип от включените часове DevOps (5–10 ч/месец при dedicated сървърите).
| План | Backup | Възстановяване | Местоположение |
|---|---|---|---|
| cPanel хостинг | Автоматичен дневен backup | От клиентския панел | ЕС (Франкфурт) |
| VPS | Снапшоти, без гарантирана честота | От снапшот | ЕС (Франкфурт) |
| VPS — външен backup | При поискване, от часовете DevOps | Според конфигурираната стратегия | По договаряне с екипа |
| Dedicated сървър | Не е включен по подразбиране — настройва се при поискване | Според стратегията (3-2-1, PITR) | ЕС (Франкфурт) + външно хранилище при поискване |
RPO и RTO — числата, които трябва да зададете сами
Вместо „backup възможно най-скоро“ си струва да фиксирате две конкретни стойности. RPO (Recovery Point Objective) показва колко данни можете да си позволите да загубите. RTO (Recovery Time Objective) показва колко време може да отнеме възстановяването. Екипът изгражда стратегията около тези стойности.
Максималната загуба на данни, която можете да приемете. Дневният backup означава загуба до един ден; с WAL стрийминг базата данни слиза под една минута — настройва се при поискване.
Времето за възстановяване зависи от обема данни и избраната стратегия. Не гарантираме RTO — единственото надеждно число е измереното при тест за възстановяване.
Сценарии на бедствие — и как да се защитите
Бедствията са редки, но с голямо въздействие. Ето най-честите сценарии и защитата, която препоръчваме за всеки от тях. На VPS и dedicated сървъри екипът настройва тези мерки от включените часове DevOps.
Хардуерна повреда (диск, RAM)
Най-честата причина за загуба на данни. Dedicated сървърите имат NVMe дискове по двойки с RAID, настроен при инсталацията, плюс ECC RAM при нивата EPYC и Xeon. RAID поддържа сървъра в работа при отказ на диск, но не замества backup — външно копие все пак е необходимо.
Защита: RAID + външен backupRansomware или компрометиран акаунт
Нападателят криптира файловете на сървъра — и всяко копие, до което сървърът има достъп. Затова поне едно копие трябва да се намира извън сървъра, където продукционният акаунт не може да го променя (неизменяемо или офлайн). Настройваме го при поискване, от часовете DevOps.
Защита: изолирано копиеСлучайно изтриване на данни
„DROP TABLE users“, изпълнено върху продукцията. Най-честата човешка грешка. Ако базата данни има настроено възстановяване до момент във времето (PITR), връщате се до точно преди грешката; дневният backup ви връща само до последното копие.
Защита: PITR при поискванеПълен срив на дата центъра
Пожар, наводнение, продължителен срив при оператора. Защитата е копие на друго място, например във втори дата център. Репликацията и failover не са включени по подразбиране; екипът ги настройва при поискване, от часовете DevOps.
Защита: копие на друго мястоГрешка в приложението поврежда данни
Нов deploy въвежда грешка, която поврежда записи в базата. С отделен backup на базата данни възстановявате само нея (не целия сървър) — файловете на приложението остават, данните се връщат назад.
Защита: отделен backup на базата данниМиграция към друг сървър
Прерастете текущия план. VPS се премества на по-високо ниво с повече vCPU, RAM и диск; при преместване на друг сървър планираме миграцията предварително, за да поддържаме прекъсването кратко.
Съвет: планирайте миграцията навремеBackup на бази данни — стратегии за всеки engine
Пълният backup на VPS не винаги е достатъчен. Базите данни имат собствени механизми за възстановяване до момент във времето (PITR) — те позволяват връщане до точно избрания момент, а не само до последния снапшот. Настройваме ги при поискване, от включените часове DevOps.
Какво е включено — и какво се настройва при поискване
Няма отделно продаван „премиум backup“: какво е включено, е посочено във всеки план, а всичко отвъд това екипът изгражда от часовете DevOps във вашия абонамент. Часовете над квотата се таксуват отделно, на час.
- cPanel: автоматичен дневен backup, възстановяване от панела — включено
- VPS: снапшоти, без гарантирана честота — включено
- Dedicated сървъри: NVMe дискове по двойки, RAID, настроен при инсталацията — backup не е включен по подразбиране
- Външен backup по правилото 3-2-1 — при поискване, от часовете DevOps (5–10 ч/месец при dedicated сървърите)
- PITR за бази данни (WAL, binlog, oplog) — при поискване, от часовете DevOps
- Тестове за възстановяване и период на съхранение — договарят се с екипа и се настройват от часовете DevOps
Възстановяване на backup — в 4 стъпки
Отворете панела
Влезте в клиентския панел. На cPanel дневният backup се възстановява оттам; на VPS избирате снапшот.
Изберете момент във времето
Изберете копието от точно преди проблема. Последното не винаги е правилното, ако грешката е налице от известно време.
Натиснете „Възстанови“
Възстановяването презаписва текущото състояние. Ако не сте сигурни, помолете екипа първо да възстанови в отделна среда, за да можете да сравните.
Проверете резултата
Проверете дали приложението работи и данните са на мястото си. Колко време отнема възстановяването, зависи от обема на данните.
Често задавани въпроси
Налага ли се спиране на сървъра при снапшот?
Обикновено не: снапшотът на VPS се прави при работещ сървър. При база данни обаче снапшотът на работещ сървър не винаги е консистентен, затова препоръчваме отделен backup на базата данни (dump или WAL/binlog), който екипът настройва при поискване.
Колко време отнема възстановяването на много голям снапшот (напр. 500 GB)?
Зависи от обема данни, диска и мястото, където е съхранено копието — възстановяването от външно копие отнема повече от локално. Не обещаваме фиксирано време: реалистичното число идва от тест за възстановяване, който можем да проведем заедно с вас.
Криптирани ли са backup-ите?
Криптирането на външните backup-и е част от стратегията, която настройваме при поискване — например копия, които напускат сървъра само в криптиран вид, с ключове, съхранявани отделно от продукцията. Съобщете изискванията си на екипа, когато заявявате настройката.
Ами ако искам съхранение за повече от 30 дни?
Периодът на съхранение на външните backup-и се задава, когато екипът конфигурира стратегията, според вашите нужди и правните ви задължения за архивиране. Хранилището за по-дълго съхранение се договаря с екипа; плановете ще намерите на страницата с цените.
Мога ли да изтегля снапшот локално?
На VPS и dedicated сървъри имате root достъп и копирате данните си с предпочитаните от вас инструменти (rsync, tar). Екипът може също да настрои автоматизирани копия във външно хранилище от часовете DevOps, като AWS S3, Google Cloud Storage или Azure Blob.
Данните ви са твърде ценни, за да ги оставяте на късмета
cPanel включва дневен backup, а VPS включва снапшоти. При dedicated сървърите екипът изгражда стратегията за backup от включените часове DevOps. Вижте цените за подробности.
Вижте плановете →