Як розрахувати обсяг незмінного сховища, час передавання та вартість вихідного трафіку для віддаленої копії

У бюджетних запитах на віддалене резервне копіювання зазвичай трапляється одна з двох помилок: сховище розраховують як «одну копію дисків» або забувають про плату за вихідний трафік із хмари. Обидві помилки дають про себе знати через кілька місяців — коли точки відновлення заповнять бакет або надійде перший рахунок.

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

П'ять параметрів, які вам знадобляться

1. Використаний обсяг (D) — дані, які фактично зберігаються на захищених дисках, а не їхній виділений розмір. Диск на 4 ТБ, заповнений на 40%, дає 1,6 ТБ.
2. Коефіцієнт скорочення даних (r) — результат стиснення та дедуплікації в програмі резервного копіювання; для змішаного парку серверів типово 1,3–2×.
3. Щоденні зміни (Δ) — нові та змінені блоки за добу після скорочення. Визначте їх за розмірами інкрементів у ваших поточних резервних копіях.
4. Політика зберігання — скільки щоденних, тижневих і місячних точок відновлення ви зберігаєте.
5. Зростання — очікуване збільшення обсягу даних за строк дії договору, зазвичай 10–20% на рік.

Формула обсягу сховища для схеми GFS

Коли резервне копіювання в об'єктне сховище працює за схемою «вічного інкременту» (incremental forever), кожна точка відновлення зберігає лише ті блоки, що змінилися й не є спільними з новішими точками. Звідси проста оцінка:

Обсяг ≈ F + Nd × Δ + Nw × Δw + Nm × Δm + накладні витрати

F   = D / r        повна копія
Nd  = щоденні точки                Δ  = щоденні зміни
Nw  = тижневі точки понад щоденні  Δw ≈ 2,5 × Δ
Nm  = місячні точки понад тижневі  Δm ≈ 6 × Δ
накладні витрати ≈ 10% на Object Lock і метадані

Тижневий і місячний коефіцієнти враховують, що багато щоденних змін перезаписують ті самі блоки; щойно накопичиться місяць історії, замініть їх фактичними значеннями. Приклад розрахунку: 20 ТБ використаних даних, скорочення 1,5× і 200 ГБ щоденних змін.

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

Object Lock і накладні витрати на незмінність

Object Lock у режимі compliance зберігає кожен об'єкт до завершення строку блокування — навіть якщо програмі резервного копіювання він уже не потрібен. Тому засоби резервного копіювання продовжують блокування з кроком у кілька днів (Veeam, наприклад, зазвичай додає до десяти днів), а прострочені точки видаляються лише після зняття блокування. Закладайте 10–15% понад розрахунок за політикою зберігання і ніколи не плануйте 100% заповнення незмінного сховища: заповнений бакет неможливо очистити достроково.

Початкове завантаження: пропускна здатність і тривалість

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

Дні = Обсяг даних (ТБ) × 8 000 000 / (Швидкість каналу (Мбіт/с) × 0,8 × 86 400)

Щоденні інкрементні копії значно менші: щоб передати 500 ГБ за восьмигодинне вікно, потрібно близько 140 Мбіт/с, а якщо розподілити передавання на 24 години — менш ніж 50 Мбіт/с.

Вартість вихідного трафіку з хмари

Плату за кожен гігабайт даних, що залишають публічну хмару, стягує хмарний провайдер, а не провайдер резервного копіювання, тож у бюджетному запиті це має бути окремий рядок. Прейскурантні ціни Azure на вихідний інтернет-трафік з Європи (з маршрутизацією через мережу Microsoft):

У нашому прикладі початкове завантаження повної копії обсягом 13,3 ТБ коштує близько 1 137 $, а 6 ТБ щомісячних змін — близько 513 $ на місяць, або 6 160 $ на рік. Зменшити рахунок допомагають три важелі: стиснення й дедуплікація перед передаванням, дешевший варіант «routing preference: internet» (0,08 $ і 0,065 $ за ГБ у перших двох тарифних діапазонах), а також спонсорські програми чи програми хмарних кредитів, які, можливо, уже покривають підписку.

Розрахунок ресурсів для відновлення

Для тестів відновлення потрібні обчислювальні ресурси й дисковий простір поруч зі сховищем резервних копій. Розраховуйте пул під найбільшу систему, яку потрібно відновити за один раз, а не під середню:

• Диски: використаний обсяг даних найбільшої системи плюс 20% робочого простору.
• Обчислювальні ресурси: достатньо vCPU і RAM, щоб одночасно запустити всі її сервери, — наприклад, дві ВМ, кожна з 8 vCPU і 32 ГБ.
• Час: тестування всіх систем зазвичай займає від двох до чотирьох тижнів роботи пулу на рік.

Чек-лист для розрахунку

• Вимірюйте використаний обсяг даних на кожному сервері та розмір баз даних, а не виділені диски.
• Вивантажте розміри інкрементних копій за 30 днів із поточної системи резервного копіювання, щоб отримати реальний обсяг щоденних змін.
• Погодьте глибину зберігання для кожної категорії систем ще до запиту цін.
• Додайте 10–15% на незмінність і 10–20% на зростання.
• Розраховуйте канал для початкового завантаження на 14 днів або менше, а щоденне вікно — під піковий обсяг змін.
• Внесіть вихідний трафік із хмари до бюджетного запиту окремим рядком.

Не хочете рахувати самостійно? Надішліть нам вихідні дані — ми розрахуємо суверенний відновлювальний резерв і запропонуємо архітектуру з кошторисом.