Політика резервного копіювання AlexHost: повний технічний посібник із захисту та відновлення даних

Розуміння того, як саме ваш хостинг-провайдер здійснює резервне копіювання, є не просто бажаним — це фундаментальна вимога для будь-якого серйозного рішення щодо інфраструктури. AlexHost підтримує структуровану, багаторівневу політику резервного копіювання, яка варіюється залежно від типу послуги, з чітко визначеними обов’язками як для провайдера, так і для клієнта. Цей посібник охоплює всі аспекти цієї політики: частоту резервного копіювання, процедури відновлення, витрати та критичні прогалини, які ви повинні заповнити власною стратегією резервного копіювання.

Яка політика резервного копіювання AlexHost?

Політика резервного копіювання AlexHost — це багаторівнева система захисту даних, у якій частота та обсяг автоматичного резервного копіювання залежать від типу хостингу. Плани спільного хостингу та хостингу LiteSpeed отримують щоденне автоматичне резервне копіювання, VPS-середовища резервуються щотижня, а виділені сервери не отримують жодного резервного копіювання з боку провайдера. Відновлення доступне на запит через службу підтримки відповідно до умов, описаних нижче.

Ця політика існує для забезпечення базового рівня захисту, а не комплексного рішення для аварійного відновлення. Ця відмінність має величезне практичне значення: резервна копія, керована провайдером, — це знімок стану на певний момент часу, і її цілісність залежить від стану ваших файлів у момент створення знімка. AlexHost явно не гарантує відновлення з кожної резервної копії, що робить управління резервним копіюванням на стороні клієнта операційною необхідністю, а не необов’язковим заходом обережності.

Охоплення резервного копіювання за типом послуги

Кожен рівень хостингу в AlexHost працює за різною моделлю резервного копіювання. Таблиця нижче узагальнює ключові параметри для всіх категорій послуг.

Резервне копіювання для спільного хостингу та хостингу LiteSpeed

Для клієнтів на планах спільного веб-хостингу щоденне резервне копіювання виконується автоматично інфраструктурою AlexHost. Ці резервні копії містять точну копію файлової системи облікового запису та пов’язаних баз даних на момент створення знімка. Якщо потрібне відновлення — через випадкове видалення файлів, пошкоджену базу даних або невдале розгортання — служба підтримки може отримати та відновити дані з останньої доступної резервної копії.

Важливий технічний нюанс: щоденне резервне копіювання не означає відновлення на певний момент часу. Якщо ваша база даних пошкоджена о 23:00, а резервне копіювання виконується опівночі, пошкоджений стан буде зафіксовано. Знімок попереднього дня є останньою чистою точкою відновлення. Це 24-годинне вікно потенційної втрати даних є відомим обмеженням щоденних циклів резервного копіювання і має враховуватися при управлінні розгортаннями та змінами бази даних.

Політика резервного копіювання VPS

VPS-середовища мають принципово інший профіль ризику. Клієнти, що використовують VPS-хостинг, мають доступ на рівні root, що означає можливість встановлювати програмне забезпечення, змінювати системні файли, переналаштовувати сервіси та вносити зміни, що виходять далеко за межі типового облікового запису спільного хостингу. Тижневий цикл резервного копіювання відображає підвищену складність створення знімків повного середовища віртуальної машини, але це також означає, що до семи днів змін можуть бути невідновлюваними у найгіршому сценарії збою.

Для клієнтів VPS це створює чітку операційну вимогу: ви повинні впровадити додаткові механізми резервного копіювання на рівні застосунку або файлової системи. Поширені підходи включають:

• Автоматизовані дампи баз даних за допомогою mysqldump або pg_dump, запланованих через cron, з виведенням у віддалене сховище
• Інкрементальна синхронізація файлів за допомогою rsync через SSH до зовнішнього місця призначення
• Резервне копіювання на основі знімків за допомогою таких інструментів, як Timeshift, Bacula або Duplicati, налаштованих для щоденного або більш частого запуску
• Резервне копіювання на рівні застосунку для таких платформ, як WordPress (UpdraftPlus, BackWPup) або власних застосунків із вбудованою функцією експорту

Якщо ви керуєте середовищем панелі управління, панелі управління VPS, такі як cPanel, Plesk або DirectAdmin, усі включають власні інструменти планування резервного копіювання, які можна налаштувати незалежно від циклу знімків провайдера.

Політика резервного копіювання виділених серверів

Виділені сервери не отримують жодного резервного копіювання з боку провайдера. Це стандартна практика в галузі для bare-metal інфраструктури: клієнт має повний контроль на апаратному рівні, а операційна складність створення знімків різноманітних, налаштованих клієнтами середовищ робить автоматизацію на стороні провайдера непрактичною.

Клієнти, що використовують виділені сервери, повністю відповідають за проектування, впровадження та тестування власної архітектури резервного копіювання та аварійного відновлення. Зазвичай це передбачає:

• Зовнішні цілі зберігання — окремий сервер зберігання, пристрій NAS або хмарне об’єктне сховище (S3-сумісні кінцеві точки, Backblaze B2, Wasabi)
• Програмне забезпечення для резервного копіювання — Veeam, Amanda, Bacula, BorgBackup або Restic залежно від ОС та робочого навантаження
• Перевірка резервних копій — автоматизовані тести відновлення, що виконуються за розкладом для підтвердження цілісності резервної копії, а не лише її наявності
• Політики зберігання — схема ротації grandfather-father-son (GFS) є галузевим стандартом, що підтримує щоденні, щотижневі та щомісячні точки відновлення

Відсутність незалежної стратегії резервного копіювання на виділеному сервері є однією з найпоширеніших і найдорожчих помилок у самостійно керованій інфраструктурі.

Цілісність резервних копій та відповідальність провайдера

Політика AlexHost включає явне та важливе застереження: провайдер не несе відповідальності за стан файлів клієнта на момент резервного копіювання, ні за стан самої резервної копії. Це не незвичайне юридичне формулювання — воно відображає реальну технічну дійсність.

Резервні копії — це знімки того, що існує в певний момент. Якщо ваші файли вже пошкоджені, заражені шкідливим програмним забезпеченням або частково видалені під час виконання знімка, резервна копія фіксує цей деградований стан. Резервна копія скомпрометованої інсталяції WordPress — це стиснутий архів скомпрометованої інсталяції WordPress. Саме тому дотримання правил безпеки — оновлення програмного забезпечення, використання надійних облікових даних, розгортання SSL-сертифікатів для запобігання атакам типу «людина посередині» на ваші адміністративні інтерфейси — невіддільне від надійної стратегії резервного копіювання.

Крім того, резервне копіювання не виконується для зупинених або призупинених послуг. Якщо послуга неактивна, нові знімки не створюються. Це має практичне значення: якщо ви тимчасово призупиняєте послугу, а потім потребуєте відновлення даних, ви обмежені тією резервною копією, яка існувала на момент останньої активності послуги.

Вартість та умови відновлення резервних копій

За нормальних умов роботи відновлення резервних копій надається без додаткової плати протягом активного терміну дії послуги. Однак два конкретні сценарії передбачають обмеження щодо вартості та права на відновлення.

Відновлення після припинення дії послуги: якщо послугу було припинено або видалено через несплату, і клієнт згодом запитує відновлення останньої доступної резервної копії, AlexHost може стягнути плату в розмірі 20 EUR для покриття технічних витрат на пошук і відновлення даних. Ця плата застосовується лише тоді, коли відновлення поєднується з реактивацією послуги — це не окрема послуга з отримання даних.

Порушення Політики допустимого використання: якщо послугу було припинено через порушення Політики допустимого використання (AUP) AlexHost, відновлення з резервної копії недоступне за жодних обставин. Це жорстке обмеження політики, а не умова, що підлягає обговоренню.

Практичний висновок: розглядайте вікно доступу до резервних копій як таке, що збігається з терміном дії вашої активної підписки на послугу. Допускати прострочення оплати послуги — це не лише проблема виставлення рахунків, а й ризик доступу до даних.

Чому резервні копії провайдера не замінюють власні

Цей момент заслуговує на пряме висвітлення, оскільки його часто неправильно розуміють. Резервні копії, керовані провайдером, служать конкретній та обмеженій меті: вони захищають від збоїв на рівні інфраструктури та забезпечують можливість відновлення у разі випадкової втрати даних у межах вікна зберігання резервних копій. Вони не захищають від:

• Програм-вимагачів або шкідливого програмного забезпечення, що шифрують або знищують файли до наступного резервного копіювання
• Логічного пошкодження, що поступово вноситься протягом кількох циклів резервного копіювання, коли всі збережені знімки містять пошкоджений стан
• Вимог відповідності, що передбачають конкретні терміни зберігання, географічне розташування сховища або стандарти шифрування
• Відновлення на рівні застосунку, наприклад відновлення однієї таблиці бази даних без перезапису всього облікового запису
• Відновлення без простоїв, коли повне відновлення на стороні провайдера може тривати години, тоді як власна локальна резервна копія може бути розгорнута за хвилини

Для підприємств, що виконують виробничі робочі навантаження — інтернет-магазини, SaaS-застосунки, клієнтські портали — правило резервного копіювання 3-2-1 залишається базовим стандартом: три копії даних, на двох різних типах носіїв, з однією копією, що зберігається поза офісом.

Міркування щодо даних електронної пошти та домену

Клієнти, що використовують хостинг електронної пошти, повинні окремо перевірити, які положення про резервне копіювання застосовуються до даних поштової скриньки, оскільки сховища електронної пошти мають інші характеристики відновлення, ніж веб-файли. Так само дані реєстрації домену, керовані через реєстрацію доменів, не підлягають резервному копіюванню в традиційному розумінні — записи про право власності на домен зберігаються на рівні реєстру — але забезпечення актуальності вашої контактної інформації та налаштувань поновлення є еквівалентною формою захисту даних для вашого простору імен.

Матриця технічних рішень: стратегія резервного копіювання за типом хостингу

Використовуйте цю матрицю для визначення мінімальних додаткових дій з резервного копіювання, необхідних залежно від вашої послуги AlexHost.

Ключові висновки: операційний контрольний список

• Підтвердіть, на якому рівні послуги ви перебуваєте, та перевірте відповідну частоту резервного копіювання, перш ніж припускати наявність щоденного покриття
• Ніколи не покладайтеся виключно на резервні копії провайдера для виробничих даних — впровадьте принаймні один незалежний механізм резервного копіювання, що контролюється клієнтом
• Регулярно плануйте та тестуйте процедури відновлення; нетестована резервна копія є неперевіреною резервною копією
• Підтримуйте послуги в активному, оплаченому статусі для збереження доступу до відновлення резервних копій без стягнення плати за відновлення в розмірі 20 EUR
• Для VPS-середовищ налаштуйте резервне копіювання на рівні застосунку та файлової системи для виконання частіше, ніж тижневий цикл знімків провайдера
• Для виділених серверів розробіть повну архітектуру резервного копіювання перед розгортанням будь-якого виробничого робочого навантаження
• Переконайтеся, що ваші резервні копії зберігаються в географічно окремому місці від вашого основного хостингового середовища
• Перевіряйте, що резервні копії містять чисті, вільні від шкідливого програмного забезпечення дані, підтримуючи надійні практики безпеки у вашому хостинговому середовищі постійно

Часті запитання

Чи виконує AlexHost резервне копіювання автоматично, чи мені потрібно його увімкнути?

Резервне копіювання для спільного хостингу та хостингу LiteSpeed виконується автоматично AlexHost без будь-якого налаштування з боку клієнта. Для планів VPS щотижневі знімки також створюються автоматично. Клієнти виділених серверів повинні повністю самостійно налаштовувати та керувати власними системами резервного копіювання.

Як мені запросити відновлення резервної копії у службі підтримки AlexHost?

Надішліть запит через систему підтримки AlexHost, вказавши послугу, приблизну дату даних, які потрібно відновити, та конкретні файли або бази даних, що постраждали. Відновлення виконується технічною командою та доступне безкоштовно протягом активного терміну дії послуги.

Що станеться з моїми резервними копіями, якщо я скасую план хостингу?

Після припинення або видалення послуги через несплату доступ до резервних копій не гарантується. Якщо ви запитуєте відновлення після припинення дії послуги, AlexHost може стягнути 20 EUR за зусилля з відновлення, і це застосовується лише при реактивації послуги. Якщо припинення сталося через порушення AUP, відновлення неможливе.

Чи можу я завантажити власну резервну копію з панелі управління AlexHost?

Для облікових записів спільного хостингу, що керуються через cPanel, ви можете створити та завантажити повну резервну копію облікового запису безпосередньо з cPanel Backup Wizard у будь-який час. Клієнти VPS з доступом root можуть створювати власні знімки або файлові архіви за допомогою стандартних утиліт Linux. Це рекомендований підхід для підтримки точок відновлення, що контролюються клієнтом.

Чи є щотижневе резервне копіювання VPS повним знімком або інкрементальним резервним копіюванням?

AlexHost виконує резервне копіювання на основі знімків для VPS-середовищ. Технічна реалізація означає, що знімок фіксує стан віртуального диска на момент виконання. Клієнти, яким потрібні більш детальні точки відновлення — наприклад, щоденні або щогодинні знімки — повинні впровадити їх самостійно за допомогою інструментів, доступних у їхньому VPS-середовищі, або шляхом налаштування VPS з cPanel, що включає вбудовані можливості планування резервного копіювання.