Реплікація бакетів S3: методи, приклади та пастки

Блог WebDisk · категорія: Object Storage · час читання: ~27 хвилин

Коротко:- Реплікація бакета – друга копія об’єктів в іншому місці – має п’ять родин рішень: правило в самому S3, реплікація кластера (multisite), копіювання інструментами (rclone), подієвий worker і подвійний запис у застосунку.- Усі їх поєднує одна властивість: реплікація повторює також видалення та перезапис. Репліка не є резервною копією – нею вона стає лише в парі з версіонуванням і блокуванням запису (S3 Object Lock).- У WebDisk Files є Реплікація бакетів: одноразовий імпорт сховища, сумісного з S3, до нового сховища у WebDisk, із переглядом поступу – без плати за трансфер, у межах пулу міграцій, включеного в абонемент. >Не працюєте з терміналом? Пропустіть блоки команд – опис методів, розділ про пастки й частина про WebDisk дають повну картину.

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

Реплікація бакетів (bucket – контейнер для файлів у сховищі S3, відповідник диска чи мережевого ресурсу; у послугах WebDisk ми називаємо його сховищем) є відповіддю на це запитання – але відповіддю частковою і легкою для хибного розуміння. У цій статті ми проходимо через усі реально вживані методи реплікації даних в об’єктному сховищі: від готового правила, яке вмикається однією командою, через реплікацію цілих кластерів, до власного worker-а, що слухає події. Для кожного показуємо приклад, вартість входу і те, чого цей метод не робить. Наприкінці описуємо, як реплікацію розв’язали ми у WebDisk Files.

Навіщо реплікувати бакет? П’ять різних причин, п’ять різних рішень

Перш ніж обирати техніку, назвіть проблему – бо «реплікація» це одне слово на п’ять різних завдань, а рішення, добре для одного, буває непридатним для іншого.

Стійкість до аварії локації (DR, disaster recovery – відновлення після катастрофи). Ви хочете пережити втрату цілого регіону, центру даних або кластера. Потрібна копія фізично в іншому місці, найкраще в іншому домені відмов і найкраще з власними обліковими даними.
Міграція і вихід від постачальника. Ви переносите дані з одного S3 до іншого – одноразово, але повністю й перевірювано. Це не безперервна реплікація, а контрольований трансфер із прийманням якості; ширше ми писали про це з нагоди vendor lock-inу.
Географічна близькість. Копія ближче до користувачів або ближче до обчислень, щоб скоротити час відповіді. Тут важить затримка поширення, а не тривкість.
Розділення середовищ і ролей. Копія продакшн-даних для потреб аналітики, тестів або архіву – часто з фільтром, обрізана до одного префікса й позбавлена чутливих даних.
Ізоляція копії від продакшн-облікового запису. Копія в місці, до якого не сягають облікові дані продакшну – щоб захоплення облікового запису не означало втрати всього. Це сценарій анти-ransomware, і він має власні правила гри.

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

Реплікація, синхронізація, бекап – три слова, які не є синонімами

Це розрізнення вирішує, чи ваша друга копія бодай щось урятує.

Реплікація підтримує копію, узгоджену з джерелом. Її метою є те, щоб ціль виглядала так само, як джерело – включно з тим, що файл було видалено. Добра реплікація швидка й вірна; це водночас означає, що вона вірно повторює катастрофу.

Синхронізація (rclone sync, aws s3 sync --delete) – це реплікація, яку роблять періодично, партіями – з тією самою властивістю: видаляє в цілі те, чого немає в джерелі.

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

Правило 3-2-1 і різницю між копією та синхронізацією ми розгортали в статті про бекап у хмарі. Тут вистачить одного речення, яке варто повісити над столом: репліка захищає від втрати обладнання, бекап захищає від втрати даних. Це не замінники, і більшість серйозних впроваджень мають і одне, і друге.

Чотири запитання, які обирають метод за вас

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

Який у вас допустимий RPO (Recovery Point Objective)? Скільки хвилин – або годин – даних ви можете втратити? Секунди означають подієву або нативну реплікацію; години – спокійно вистачить запланованого копіювання інструментом.
Чи обидва кінці в того самого постачальника? Нативна реплікація S3 зазвичай працює в межах однієї платформи. Між різними постачальниками майже завжди залишаються інструменти або власний worker.
Чи має копія пам’ятати історію? Якщо так, потрібне версіонування з обох боків і метод, який переносить версії – або свідоме рішення, що копія «пласка», а історію тримає бекап.
Хто платить за трансфер і в кого ключі? Копія в того самого постачальника буває безкоштовною, копія «назовні» коштує вихідного трафіку. А копія, доступна з тих самих ключів, що й продакшн, не захищає від захоплення облікового запису.

Метод 1. Правило реплікації в самому S3: сховище стежить за копією само

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

Три речі потрібні, щоб це взагалі зрушило:

версіонування з обох боків – реплікація оперує версіями об’єктів, а не іменами; без версіонування немає чого реплікувати (це той самий фундамент, на якому стоїть Object Lock),
ідентичність із правами до обох бакетів – в AWS це роль IAM, яку служба S3 приймає від вашого імені,
правило – з фільтром (цілий бакет, префікс або тег), пріоритетом і описом цілі.

Перш ніж почати. Приклади використовують aws CLI і rclone, налаштовані як у попередніх статтях циклу (aws configure + --endpoint-url вашого постачальника – нижче ми його опускаємо для читабельності). Обережно зі справжніми даними: rclone sync і aws s3 sync --delete видаляють у цілі те, чого немає в джерелі, а друкарська помилка в префіксі джерела здатна вичистити копію. Тренуйтеся на тестових бакетах.

Практичний приклад в AWS. Спершу версіонування, потім саме правило:

# 1. версіонування на джерелі та на цілі — необхідна умова
aws s3api put-bucket-versioning --bucket firma-produkcja \
  --versioning-configuration Status=Enabled
aws s3api put-bucket-versioning --bucket firma-kopia-dr \
  --versioning-configuration Status=Enabled

# 2. правило реплікації: усе, що потрапляє до «raporty/», опиняється в другому бакеті
aws s3api put-bucket-replication --bucket firma-produkcja \
  --replication-configuration '{
    "Role": "arn:aws:iam::111122223333:role/s3-replikacja",
    "Rules": [{
      "ID": "raporty-do-dr",
      "Priority": 1,
      "Status": "Enabled",
      "Filter": { "Prefix": "raporty/" },
      "DeleteMarkerReplication": { "Status": "Disabled" },
      "Destination": {
        "Bucket": "arn:aws:s3:::firma-kopia-dr",
        "StorageClass": "STANDARD_IA"
      }
    }]
  }'

Перевірка, чи конкретний об’єкт уже скопійовано, так само проста – статус реплікації видно в його метаданих:

aws s3api head-object --bucket firma-produkcja --key raporty/2026-08.csv
# "ReplicationStatus": "COMPLETED" ← або PENDING / FAILED
# на копії той самий об’єкт звітує "REPLICA"

Зверніть увагу на DeleteMarkerReplication. Це одне поле визначає характер усього рішення: увімкнене – копія є вірним дзеркалом і «зникнення» файлу поширюється на другий бік; вимкнене – видалений файл залишається в копії. Для реплікації, яку розуміють як DR, вимкнення буває свідомим вибором, але треба знати, що тоді робиться копія, яка з часом розходиться з джерелом і сама за собою не прибере.

Друга річ, про яку легко забути: видалення конкретної версії ніколи не реплікується: якщо в запиті DELETE ви вкажете ідентифікатор версії, вона зникне виключно в джерелі. Це навмисна захисна властивість – і добра новина для сценарію «хтось захопив обліковий запис і чистить дані». Увага на одну міграційну деталь: старіші конфігурації (без елемента Filter) типово реплікували маркери видалення з дій користувача, а новіші – ні. Тож дописування фільтра до старого правила тихо змінює поведінку при видаленні.

Три несподіванки, які цей метод тримає в запасі:

Правило діє від моменту ввімкнення. Об’єкти, які лежали в бакеті раніше, самі не скопіюються – у гіперскейлера для них треба запустити окреме масове завдання (в AWS: S3 Batch Replication), а поза ним просто скопіювати їх звичайним інструментом (метод 3, описаний нижче). Це стосується також кожної перерви в роботі правила – повертаємося до цього в пастці 6.
Реплікація не створює ланцюгів. Копія в бакеті B не поїде до C, навіть якщо B має власне правило. Ланцюгів не будують – кожну ціль підключають до джерела окремо.
Фільтр за тегами ловить лише теги, надані під час запису. Тегування файлу постфактум не запускає реплікації, що дієво підриває популярний шаблон «спершу завантаж, потім класифікуй». Фільтр за префіксом такої проблеми не має.

Якщо реплікація має мати договірні часові рамки, у гіперскейлера їх докуповують окремо: S3 Replication Time Control зобов’язує постачальника перенести 99,9% нових об’єктів протягом 15 хвилин і додає до цього метрики та події про перевищення порогу. Без цієї опції AWS не дає жодної обіцянки: документація каже лише, що більшість об’єктів реплікується протягом 15 хвилин, при великих це може зайняти кілька годин, а в крайніх випадках навіть кілька десятків – без SLA. На практиці це зазвичай питання секунд, але в аудиті важить зобов’язання, а не практика.

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

Метод 2. Реплікація на рівні кластера: multisite, тобто властивість платформи

Метод для тих, хто має два об’єктні сховища – два кластери, дві серверні – і хоче, щоб реплікація була властивістю платформи, а не кожного бакета окремо. У Ceph RGW це називається multisite, у MinIO – реплікацією інсталяції.

У Ceph ієрархія виглядає так: realm (простір імен) містить zonegroup, а в ній живуть зони (zone) – по одній на локацію, кожна на основі власного кластера Ceph. Зони обмінюються між собою двома незалежними потоками: метаданими (користувачі, бакети, політики – керовані централізовано головною зоною) і даними (об’єкти – синхронізовані кожною зоною окремо). Роблять це самі демони RGW, без жодного зовнішнього агента.

# локація A — realm, група зон і головна зона
radosgw-admin realm create --rgw-realm=firma --default
radosgw-admin zonegroup create --rgw-zonegroup=eu --endpoints=https://s3-a.firma.pl --master --default
radosgw-admin zone create --rgw-zonegroup=eu --rgw-zone=eu-a --endpoints=https://s3-a.firma.pl --master --default

# системний користувач — цим ключем зони автентифікуються між собою
radosgw-admin user create --uid=sync --display-name="Sync User" --system \
  --access-key=<klucz-systemowy> --secret=<sekret>
radosgw-admin zone modify --rgw-zone=eu-a --access-key=<klucz-systemowy> --secret=<sekret>
radosgw-admin period update --commit

# локація B — друга зона в тій самій групі; спершу стягує realm і period
radosgw-admin realm pull --url=https://s3-a.firma.pl \
  --access-key=<klucz-systemowy> --secret=<sekret> --default
radosgw-admin period pull --url=https://s3-a.firma.pl \
  --access-key=<klucz-systemowy> --secret=<sekret>
radosgw-admin zone create --rgw-zonegroup=eu --rgw-zone=eu-b --endpoints=https://s3-b.firma.pl \
  --access-key=<klucz-systemowy> --secret=<sekret>
radosgw-admin period update --commit

# щоденна діагностика: чи зона не відстає
radosgw-admin sync status
# шукаєте шарди «behind» (треба надолужити) і «recovery» (помилка, запланована повторна спроба)

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

Новіші випуски Ceph дозволяють реплікувати вибрані бакети замість цілої зони – цьому служить гранулярна політика синхронізації, побудована з трьох шарів: групи (чи реплікація дозволена), потоку (у який бік течуть дані – взаємно чи односпрямовано) і «труби» (що конкретно і куди). Рекомендований шаблон – дозволити широко на рівні групи зон, а вмикати точково на рівні бакета:

# на рівні групи зон: «можна, але я не вмикаю всього»
radosgw-admin sync group create --group-id=grupa-dr --status=allowed
radosgw-admin sync group flow create --group-id=grupa-dr --flow-id=a-do-b \
  --flow-type=directional --source-zone=eu-a --dest-zone=eu-b
radosgw-admin sync group pipe create --group-id=grupa-dr --pipe-id=wszystko \
  --source-zones='*' --dest-zones='*'
radosgw-admin period update --commit

# на рівні конкретного бакета: «цей реплікуй» (без period update)
radosgw-admin sync group create --bucket=firma-backup \
  --group-id=backup-default --status=enabled
radosgw-admin sync group pipe create --bucket=firma-backup \
  --group-id=backup-default --pipe-id=pipe1 \
  --source-zones='*' --dest-zones=eu-b

radosgw-admin sync info --bucket=firma-backup # що реально попливе і куди

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

Найцікавіший з погляду безпеки варіант – це архівна зона (archive zone): зона, яка примусово вмикає версіонування і тримає чергові версії всього, що пройшло через кластер, а об’єкти з неї можна видалити виключно через її власні шлюзи. Це єдиний різновид реплікації на рівні кластера, який захищається від помилки оператора і від ransomware, бо зриває ключове припущення «копія має виглядати як оригінал». Практична схема виглядає так: продакшн працює на звичайних, неверсіонованих зонах, а поруч стоїть архів, до якого ніхто з продакшну не має як дотягнутися.

Коли варто: ви маєте (або купуєте) дві локації і хочете реплікації, прозорої для клієнтів – включно з обліковими записами й політиками. Чого не вирішить: нічого, якщо другої локації не існує. Multisite – це інфраструктурне й фінансове рішення, а не перемикач у панелі; воно вимагає другого кластера, каналу, що витримає потік змін, і дисципліни при оновленнях (нові функції вмикають аж тоді, коли їх розуміють усі зони).

Чи ваш постачальник це взагалі має? Огляд дев’яти платформ

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

AWS S3 – повна нативна реплікація, у тому самому регіоні та між регіонами, з опційним договірним часом поширення й окремим масовим завданням для наявних об’єктів.
OVHcloud – реплікація нативна, асинхронна, налаштовувана стандартним put-bucket-replication; версіонування треба ввімкнути самостійно на джерелі та на цілі (автоматично це робить лише окрема опція реплікації поза локацію, яку позначають при створенні бакета в тризонових регіонах), є також окремий пакетний режим для об’єктів, записаних раніше. Обидва бакети мусять лежати в тому самому проєкті.
Wasabi – реплікація нативна, керована викликами, сумісними з S3. Цікавинка: не вимагає версіонування, вимагає натомість узгодженого стану з обох боків (версіонований до версіонованого, неверсіонований до неверсіонованого) і того самого власника бакетів.
Backblaze B2 – реплікація нативна, але налаштовувана власним API та CLI, а не через інтерфейс S3; до двох правил на бакет, з опцією охоплення наявних файлів. За сам реплікаційний трафік ви не платите – платите за другу копію даних.
Google Cloud Storage – реплікація є властивістю бакета, а не правилом: ви обираєте дворегіональний або мультирегіональний бакет – і все. Номінальна ціль – комплект об’єктів за 12 годин, а за доплату (turbo) – 15 хвилин.
Azure Blob – два роз’єднані шари: георедундантність цілого облікового запису (GRS/GZRS) та об’єктна реплікація між контейнерами, що вимагає версіонування з обох боків і потоку змін на джерелі.
MinIO – має і реплікацію на рівні бакета, і реплікацію цілих інсталяцій (разом із користувачами й політиками), але треба знати стан проєкту: репозиторій спільнотного випуску у квітні 2026 було заархівовано, а в комерційному AIStor реплікація належить до функцій платних планів. Серверна реплікація при цьому з’єднує виключно інсталяції MinIO між собою.
Ceph RGW – multisite і гранулярна політика синхронізації, описані вище; тож у постачальника на основі Ceph питання звучить просто: чи маєте ви другу зону.
DigitalOcean Spaces, Scaleway, Cloudflare R2 – нативної реплікації bucket-to-bucket немає. R2 надолужує це двома міграційними інструментами (гуртовим перенесенням і інкрементним дотягуванням об’єктів на вимогу), а в решти залишається метод 3.

Практичний висновок такий, що за сценарію «копія в іншого постачальника» майже завжди повертаються до інструментів – бо навіть коли обидві платформи мають нативну реплікацію, вони майже ніколи не вміють узгодити її між собою.

Метод 3. Копіювання інструментами: rclone, mc, s5cmd і aws s3 sync

Найуніверсальніший метод і – всупереч видимості – найчастіше вживаний на практиці. Не вимагає згоди ані підтримки постачальника з жодного боку: берете два endpointи S3, два комплекти ключів і переганяєте дані. Працює між будь-якими платформами, тож саме він рятує при міграціях і при виході від постачальника.

Королем цієї категорії є rclone, бо розуміє кілька десятків бекендів і має саме ті перемикачі, які в цьому завданні потрібні:

# налаштування двох remote: rclone config (тип: s3, provider: AWS / Ceph / Minio / Other)

# 1. інкрементна копія БЕЗ видалення будь-чого в цілі — безпечний типовий вибір
rclone copy zrodlo:firma-produkcja cel:firma-kopia --progress

# 2. повне дзеркало: ціль виглядає точно як джерело (ВИДАЛЯЄ зайві файли!)
rclone sync zrodlo:firma-produkcja cel:firma-kopia --progress

# 3. продакшн-версія: паралельність під S3, порівняння за контрольними сумами,
# гуртове лістування і ліміт смуги, змінний протягом доби (значення в БАЙТАХ/с)
rclone sync zrodlo:firma-produkcja cel:firma-kopia \
  --checksum --transfers 32 --checkers 64 --fast-list \
  --bwlimit "08:00,20M 18:00,off" \
  --log-file /var/log/rclone-dr.log --log-level INFO

# 4. приймання якості — чи обидві сторони справді мають те саме
rclone check zrodlo:firma-produkcja cel:firma-kopia --one-way --checksum

Різниця між copy і sync – це не нюанс, а вибір стратегії: copy дає копію, яка ніколи сама нічого не видалить (росте, але переживе видалення на продакшні), sync дає дзеркало (воно узгоджене, але повторить кожну катастрофу – включно з друкарською помилкою в префіксі джерела, яка здатна вичистити ціль). Для мети DR зазвичай ви хочете copy – або sync на бакеті з увімкненим версіонуванням, де «видалення» є лише маркером.

Чотири деталі, які відрізняють працюючу реплікацію від такої, що працює лише на вигляд:

Типово rclone порівнює розмір і час модифікації, а час модифікації записує на S3 у власних метаданих. Об’єкти, залиті іншим інструментом, цих метаданих не мають, тож порівняння спирається тоді на серверний LastModified, який змінюється при кожному копіюванні – і черговий прогін може визнати все розбіжним. Звідси --checksum у прикладі вище.
--checksum на S3 порівнює MD5, якого багаточастинні (multipart) об’єкти не мають в ETag. rclone дає собі з цим раду власними метаданими при своїх завантаженнях, але для великих файлів, залитих чимось іншим, просто немає чого порівнювати. Це та сама пастка, про яку ми пишемо нижче в розділі про перевірку.
Копіювання з S3 до S3 типово проходить через вашу машину. Між двома різними конфігураціями rclone завантажує дані й надсилає їх назад, хіба що ви явно вкажете --server-side-across-configs (а між різними постачальниками копіювання на боці сервера не спрацює ніколи). При 50 ТБ це різниця між трансфером 50 і 100 ТБ – і відповідний рахунок за вихідний трафік.
Запускайте це з блокуванням. Найчастіший спосіб, у який така реплікація сама себе перекидає, – це прогони з cron, що накладаються. Мінімум – це flock -n, гарніше – таймер systemd з Type=oneshot і Persistent=true, який не запустить другого екземпляра того самого юніта й відпрацює прогін після перезапуску хоста.

# /etc/cron.d/replikacja — щогодини, із блокуванням від накладання прогонів
17 * * * * root /usr/bin/flock -n /var/lock/replikacja.lock \
/usr/bin/rclone copy zrodlo:firma-produkcja cel:firma-kopia \
--checksum --fast-list --log-file /var/log/rclone-dr.log

Альтернативи, які варто знати:

s5cmd – коли важить сира пропускна здатність при сотнях тисяч об’єктів; розпаралелює значно агресивніше, ніж aws s3 sync. Ціною є відсутність обмеження смуги (може зайняти весь доступний канал) і відсутність порядної перевірки цілісності; до того ж він працює з одним комплектом облікових даних, тож трансфер між двома різними постачальниками мусить у нього пройти через локальний диск.
aws s3 sync – є всюди, де є AWS CLI, і вистачає для простих завдань. Має односторонній тест «джерело новіше», а при копіюванні з S3 до S3 типово переносить теги й частину властивостей об’єкта (--copy-props default) – коштом додаткових запитів. Віднедавна вміє також здивувати поза AWS. Новіші випуски CLI типово рахують контрольні суми при кожному записі; старіші реалізації, сумісні з S3, цього не знають і відповідають помилкою. Це найчастіше «раптом перестало працювати» останніх місяців; лікується перемиканням контрольних сум у режим «лише коли вимагається» в конфігурації CLI.
mc mirror --watch (клієнт MinIO) – спокушає обіцянкою безперервного прослуховування замість запусків із cron, але прослуховування спирається на розширення, специфічне для MinIO. На AWS S3 чи Ceph RGW це закінчиться помилкою або тихим переходом на звичайне опитування – тобто саме тим, чого ви хотіли уникнути. Поза MinIO ставтеся до mc як до звичайного інструмента копіювання – теги об’єктів при копіюванні з S3 до S3 переносить, зрештою, також aws s3 cp/sync; тим, який тегів не переносить, є якраз rclone.

Коли варто: різні постачальники з обох боків, міграція, обрізання копії фільтром, повний контроль над тим, що і коли копіюється. Чого не вирішить: малого RPO – копія настільки свіжа, як останній запуск. Не перенесе історії: жоден із цих інструментів не копіює версій об’єктів ані маркерів видалення, а Object Lock і конфігурації бакета не відтворить навіть приблизно. Не зніме з вас також вартості вихідного трафіку, який при кожному циклі ви платите постачальнику джерела. При мільйонах дрібних об’єктів сам перегляд списку може коштувати більше, ніж трансфер; за такого масштабу розумніше виглядає метод 4.

А якщо в бакеті лежить репозиторій бекапу, а не файли?

Окремий, часто оминаний шлях – це реплікація репозиторію резервного копіювання замість реплікації даних. Якщо до бакета пише інструмент резервного копіювання – restic, Kopia або Veeam – другу копію роблять його власними засобами (kopia repository sync-to, backup copy job у Veeam) або – у випадку resticового репозиторію, який є набором незмінюваних файлів – звичайним rclone sync --checksum. Треба лише знати, що при цьому втрачається: побайтова копія репозиторію ділить ключ шифрування з оригіналом і підлягає тим самим операціям прибирання, а restic copy навпаки – створює копію, незалежну криптографічно, але мусить стягнути й зашифрувати наново все. У випадку Veeam справа проста, і варто повторити це за виробником: життєвим циклом даних в об’єктному сховищі керує виключно Veeam, а ручне копіювання чи докладання правил lifecycle на його бакеті може закінчитися втратою даних.

Метод 4. Подієва реплікація: нехай сховище саме скаже, що змінилося

Замість питати сховище «що змінилося від учора?», дозвольте йому сказати це самому. Об’єктні сховища вміють надіслати сповіщення про кожен запис і видалення: до черги, до брокера, на HTTP-endpoint. Сповіщення приймає власний процес і копіює саме той один об’єкт, якого воно стосується.

У Ceph RGW це налаштовується як «тема» і прикріплена до бакета нотифікація. Сама нотифікація на бакеті сумісна з S3, але створення теми нижче – це вже розширення RGW: атрибути push-endpoint і persistent є власністю Ceph, а ідентифікатор теми має вигляд arn:aws:sns:<grupa-stref>:<najemca>:<temat>. На AWS той самий ефект складається інакше – окремо створюєте тему, окремо даєте S3 право публікувати в ній, а отримувача підключаєте підпискою:

# 1. тема: куди мають іти сповіщення (тут: HTTP; так само добре Kafka або AMQP).
# Виклики sns спрямовуємо на endpoint шлюзу RGW: aws --endpoint-url https://s3-a.firma.pl ...
aws sns create-topic --name replikacja \
  --attributes '{"push-endpoint":"http://worker.wewn:9000/zdarzenia","persistent":"true"}'

# 2. нотифікація на бакеті: нас цікавлять записи та видалення
aws s3api put-bucket-notification-configuration --bucket firma-produkcja \
  --notification-configuration '{
    "TopicConfigurations": [{
      "Id": "do-repliki",
      "TopicArn": "arn:aws:sns:eu:firma:replikacja",
      "Events": ["s3:ObjectCreated:*", "s3:ObjectRemoved:*"]
    }]
  }'

Worker з другого боку банальний в описі й вимогливий у деталях: приймає подію, завантажує об’єкт із джерела, записує в ціль, підтверджує. Уся складність сидить у тому, що діється, коли щось піде не так – потрібні повторні спроби, черга невдалих подій (dead-letter), стійкість до повторного доставлення тієї самої події і усвідомлення, що порядок не гарантований. Треба також пам’ятати, що події описують майбутнє: те, що лежало в бакеті до ввімкнення нотифікацій, усе одно потребує одноразового копіювання інструментом із методу 3.

Коли варто: великі обсяги, багато дрібних записів, RPO, що рахується в секундах, потреба реплікації між різними постачальниками зі збереженням свіжості. Чого не вирішить: тут нічого не діється саме – усе стоїть на вашому коді й вашому утриманні. Це найбільш «власне» з рішень – дає найбільше контролю і найбільше речей, які треба моніторити.

Метод 5. Подвійний запис у застосунку: звучить найпростіше, виходить найдорожче

Остання родина – це реплікація, перенесена до застосунку: при кожному записі ви надсилаєте об’єкт до двох сховищ одразу. Звучить це найпростіше з усіх і буває спокусливим, коли сховище є лише додатком до продукту.

На практиці подвійний запис переносить на вас усі проблеми розподілених систем. Що робити, коли перший запис удався, а другий ні – відхилити операцію користувачеві чи прийняти й полагодити пізніше? Як надолужити розходження після аварії другого сховища? Звідки взяти копію файлів, записаних до того, як ви дописали цю функцію? Кожна відповідь – це шматок коду, який дублює те, що шар сховища має готове й перевірене.

Коли варто: коли друга копія має бути іншою, ніж перша – наприклад, ви записуєте оригінал до S3, а його оброблену версію – до цілком іншої системи. Тоді це не реплікація, а логіка продукту, і вона слушно сидить у застосунку. Чого не вирішить: узгодженості без чималих зусиль. Якщо обидві копії мають бути ідентичними, майже завжди дешевшим виявляється метод 1, 3 або 4 з цієї статті.

Шар, про який забувають: тривкість усередині кластера

Наведені методи відповідають на запитання «а що, як ми втратимо цілу локацію?». Є, однак, шар нижче, який відповідає на значно частіше запитання: «а що, як відмовить диск або сервер?». В об’єктних сховищах його розв’язує сам кластер – і це теж називають реплікацією, що є джерелом багатьох непорозумінь у розмовах із постачальниками.

n-кратна реплікація – кожен об’єкт тримається в кількох повних копіях на різних хостах (типово трьох). Проста, швидка у відбудові, коштує стільки місця, скільки становить множник.
Надлишкове кодування (erasure coding) – об’єкт ділиться на фрагменти даних і фрагменти парності, розкладені по вузлах. Дешевше за ємністю при порівнянній стійкості, дорожче обчислювально й повільніше у відбудові.

Обидві техніки захищають від аварії обладнання в межах одного кластера і жодна не є disaster recovery: видалення об’єкта користувачем поширюється негайно на всі копії та фрагменти. Коли постачальник каже «ми реплікуємо ваші дані трикратно», поставте йому два запитання: чи ці три копії в різних локаціях і що діється, коли хтось видасть DELETE.

Який метод обрати? Порівняння стисло

Ті самі п’ять методів, укладені за критеріями, які реально вирішують вибір:

Типове RPO (скільки даних можете втратити) – правило в S3: секунди–хвилини · multisite: секунди–хвилини · інструменти з cron: стільки, скільки становить проміжок між запусками · подієва: секунди · подвійний запис: нуль (або розходження, коли один запис відмовить).
Чи працює між різними постачальниками – правило в S3: зазвичай ні · multisite: між кластерами тієї самої платформи, хоча модуль синхронізації до хмари вміє виштовхувати односпрямовано до чужого S3 · інструменти: так, завжди · подієва: так · подвійний запис: так.
Скільки власної інфраструктури вимагає – правило в S3: жодної · multisite: другий кластер · інструменти: одна машина з доступом до обох кінців · подієва: worker, черга та їхній моніторинг · подвійний запис: код застосунку.
Чи переносить історію версій – правило в S3: так (реплікує версії) · multisite: так · інструменти: ні (копіюють поточний стан) · подієва: лише те, що самі скопіюєте · подвійний запис: ні.
Чи повторює видалення – правило в S3: залежить від DeleteMarkerReplication · multisite: так, поза архівною зоною · інструменти: sync так, copy ні · подієва: залежить від вашого worker-а · подвійний запис: залежить від коду.
Головна вартість – правило в S3: трансфер між регіонами й плата за запити · multisite: друга локація · інструменти: вихідний трафік і час машини · подієва: утримання й чергування · подвійний запис: технічний борг.

Стисло, за сценаріями: міграція або вихід від постачальника – rclone (метод 3) з check наприкінці. DR у межах одного постачальника – правило реплікації (метод 1) на бакеті з версіонуванням. DR між постачальниками – rclone copy за розкладом або подієвий worker, якщо RPO має рахуватися в секундах. Копія, стійка до ransomware – будь-який метод, аби ціль мала версіонування й блокування запису, а облікові дані до неї були інші, ніж продакшн.

Шість пасток, у які потрапляють при першому впровадженні

1. Репліка гине разом з оригіналом. Найважливіша з пасток і єдина річ, яку ми в цьому тексті повторюємо навмисно: видалення, перезапис і шифрування через ransomware є зміною, як кожна інша, і реплікація перенесе її на копію – зазвичай за кільканадцять секунд. Це не теорія: у січні 2025 публічно описали кампанію, у якій нападники з дійсними ключами доступу шифрували вміст бакетів механізмом самого S3 (ключем клієнта), залишаючи жертві сховище, повне нечитабельних об’єктів – без зламу сервера, виключно звичайними запитами S3. Отже, копія захищає від аварії обладнання й локації, а не від людини чи нападника. Ліками є версіонування з боку цілі плюс блокування запису (Object Lock, архівна зона) або режим «лише дописуй» (copy замість sync). Сам протокол тут допомагає більше, ніж здається: видалення конкретної версії ніколи не реплікується, а маркер видалення в новіших конфігураціях – типово теж ні.

2. Об’єкти, записані до ввімкнення правила, не будуть скопійовані. Реплікація охоплює майбутнє. Історія вимагає одноразового переганяння – масовим завданням у постачальника або rclone copy – і про це найлегше забути, бо панель показує «реплікацію ввімкнено» і все виглядає добре.

3. Копія – це не все, що мав бакет. Стандартно переносяться об’єкти та їхні метадані. Не переносяться самі собою: політики бакета, конфігурація CORS, правила lifecycle, налаштування типового шифрування, конфігурація сповіщень і – в інструментальних методах – історія версій та маркери видалення. Вони не їдуть разом з об’єктами, тож після міграції їх треба відтворити вручну – інакше новий бакет виглядає так само, а поводиться інакше.

4. Шифрування змінює правила гри – і то по-різному в кожному методі. У нативній реплікації AWS об’єкти, зашифровані на боці сервера типовим ключем (SSE-S3) або ключем клієнта (SSE-C), копіюються без додаткової конфігурації – але об’єкти з керованим ключем (SSE-KMS) типово не реплікуються взагалі: їх треба явно ввімкнути в правилі та вказати ключ, створений у регіоні призначення. Пастка підступна, бо запис такої конфігурації з некоректним ключем закінчується відповіддю «OK», а реплікація падає аж на першому об’єкті. В інструментальних методах усе рівно навпаки: це SSE-C блокує копіювання на боці сервера – сховище без ключа не розшифрує джерела ані не зашифрує копії, тож байти мусять пройти через процес, який знає ключ (у Ceph RGW копіювання на боці сервера зашифрованих об’єктів узагалі не реалізовано – CopyObject відповідає NotImplemented). Три варіанти шифрування ми розбирали в окремому тексті про SSE-S3, SSE-KMS і SSE-C.

5. «Скопіювалося» – це не те саме, що «збігається». Великі файли надсилаються частинами (multipart), а їхній ETag перестає бути звичайною сумою MD5 – порівняння за ним дає хибні результати. Та сама пастка вертається з іншого боку при нативній реплікації: якщо об’єкт у джерелі незашифрований, а бакет-ціль має ввімкнене типове шифрування, репліка дістане інший ETag, ніж оригінал – і кожен скрипт, що порівнює ETag-и, оголосить розходження, якого немає. Тому приймання якості роблять через контрольні суми (rclone check --checksum) або через порівняння кількості об’єктів і сумарних розмірів з обох боків. Доки ви цього порівняння не зробите, міграція є лише декларацією.

6. Тиха аварія реплікації. Реплікація псується непомітно: протерміновані облікові дані, змінена політика, повна ціль, зупинений worker. Бакет далі приймає записи, панель не кричить, а копія просто перестає рости. Гірше: у нативній реплікації об’єкт, якого не вдалося скопіювати, не буде повторено автоматично – щоб його наздогнати, треба залити його ще раз або запустити масове завдання. Так само діє вимкнення правила «на хвилинку»: після повторного ввімкнення заборгованість не надолужується автоматично. Тому до кожного з цих методів треба докласти моніторинг – статус синхронізації (radosgw-admin sync status), метрики затримки й кількості об’єктів у черзі в постачальника, сповіщення про невдалу реплікацію. Або найпростіший із можливих датчиків: алерт, коли кількість об’єктів у копії перестає встигати за джерелом.

Скільки коштує друга копія – і в якій юрисдикції вона лежить?

У гіперскейлерів трафік, що покидає регіон, є платним; при безперервній реплікації ви платите його за кожну зміну, а при повній міграції – за весь обсяг. До цього додаються плати за самі запити, а вони при нативній реплікації здатні здивувати: копіювання одного об’єкта – це з боку джерела навіть кілька читань і запис. Отже, рахунок за другу копію має три позиції, а не одну: зберігання, запити і трансфер. Одна добра регуляторна новина: європейський Data Act поетапно скасовує плату за саму зміну постачальника – від січня 2027 її не можна стягувати – але поточної реплікації це не стосується, бо це звичайний вихідний трафік, а не міграція при розірванні договору. Скільки це може означати в масштабі року, ми рахували в текстах про рахунок за публічну хмару і про різниці між гіперскейлером і локальним постачальником.

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

Як ми робимо це у WebDisk Files?

У панелі організації WebDisk Files – у частині, доступній адміністраторові організації – є функція з прямою назвою: Реплікація бакетів. Вона відповідає на той сценарій зі списку на початку, про який клієнти питають найчастіше – «маємо дані в іншого постачальника і хочемо мати їх у вас» – і робить це без термінала й без проміжної машини з вашого боку, у межах пулу безкоштовних міграцій і без запитування нас про згоду.

Виглядає це так:

Ви подаєте адресу endpointа джерела, ключ доступу і таємний ключ – до будь-якого, публічно доступного сховища, сумісного з S3. Зі списку обираєте тип постачальника (AWS, Ceph/RGW, MinIO, Wasabi, DigitalOcean Spaces або «інший, сумісний з S3»), бо різні реалізації мають свої дрібні відмінності і варто врахувати їх заздалегідь.
Натискаєте «Показати бакети». Ми перевіряємо облікові дані одразу й показуємо список бакетів, видимих для цих ключів – завдяки цьому друкарська помилка в ключі виходить у першу секунду, а не після години копіювання. (Ключ мусить мати право на лістування бакетів – назви джерела не вписують вручну, її обирають зі списку.)
Обираєте бакет-джерело, називаєте нове сховище з нашого боку і обираєте швидкість копіювання. Базова швидкість – це 50 MB/s, найвища доступна сьогодні – 250 MB/s; вибраний ліміт діє протягом усієї міграції, завдяки чому копіювання не насичує канал у непередбачуваний спосіб.
Натискаєте «Синхронізувати» і дивитеся на поступ: скопійовані байти й відсоток усього обсягу, поточна швидкість, передбачуваний час до кінця, а якби щось пішло не так – повідомлення про помилку при міграції. Міграцію можна зупинити будь-якої миті – файли, уже скопійовані, залишаються в новому сховищі.

Під сподом працює точно те, що ми описали в методі 3, тільки як послуга: для кожної міграції ми запускаємо окремий, одноразовий worker з rclone. Worker завантажує свою конфігурацію токеном, дійсним лише для цієї однієї міграції, тим самим токеном звітує про поступ до панелі й зникає після завершення роботи. Кілька проєктних рішень, які варто знати:

Таємний ключ до джерела ми тримаємо зашифрованим у базі (ідентифікатор ключа доступу, як у кожному S3, секретом не є). Для запису в сховище-ціль worker використовує ключі S3 самої організації – ті самі, які ви маєте в панелі; він дістає їх разом із конфігурацією, на час одного завдання, і вони не залишаються в описі міграції.
Адресу джерела перевіряють, перш ніж сервер із нею з’єднається. Ми відкидаємо адреси, що вказують на внутрішні мережі та служби метаданих – це стандартний захист від зловживання формою, яка за визначенням приймає будь-який URL від користувача.
Сховище-ціль постає як звичайне сховище, видиме в панелі й доступне так само, як решта: через браузер, десктопний клієнт і через S3.

Найважливіше речення про розрахунок: ця функція входить у ціну послуги. За трансфер ми не нараховуємо нічого – ані за обсяг, ані за вибрану швидкість; кожна організація має пул безкоштовних міграцій, а якщо вам потрібні наступні, достатньо написати нам. Невдала або зупинена міграція пулу не витрачає, тож спробу можна повторити без витрат – пам’ятайте лише, що сховище-ціль із уже скопійованими файлами залишається і зараховується до вашого зберігання, тож якщо воно вам не потрібне, просто видаліть його.

Треба також чесно сказати, чим ця функція не є. Це одноразова копія, а не безперервна реплікація: вона копіює поточний стан бакета-джерела, не стежить за ним нескінченно і не переносить історії версій із джерела. Якщо вам потрібна копія, яку підтримують в актуальному стані, у Files ви маєте до цього все, чого вимагає метод 3: у панелі знайдете адресу endpointа й ключі S3, тож rclone, restic, Veeam, AWS CLI чи власний скрипт спрацюють із вашим сховищем так само, як із кожним іншим S3 – в обидва боки. Це, зрештою, наша відповідь на запитання про vendor lock-in: тими самими інструментами, якими дані входять, їх можна вивести, не просячи нас про експорт.

Шари, які у WebDisk Files доповнюють картину другої копії:

Тривкість усередині кластера – кожен об’єкт утримується в трьох копіях на окремих хостах нашого кластера Ceph, того самого, на якому стоїть послуга Object Storage. Це шар із попереднього розділу: захищає від аварії диска й вузла, а не від видалення.
Версіонування – запис під наявним іменем створює нову версію, а попередні залишаються доступними для відновлення. Це перший реальний захист від «хтось перезаписав файл».
Anty-Ransomware – сховище класу WORM на основі S3 Object Lock, у якому протягом обраного періоду (від 90 днів до 7 років) жоден запит S3 не видалить і не змінить записаної версії. Це той шар, якого реплікація ніколи не замінить – і навпаки: реплікація є тим, чого не робить Object Lock.
Шифрування – SSE-S3 на рівні сховища або SSE-C з ключем на вашому боці, на вибір залежно від того, хто має тримати ключ.

Набір, який ми на практиці рекомендуємо клієнтам із реальною вимогою безперервності: робочі дані у Files, резервна копія до окремого сховища з Anty-Ransomware (бо цієї ніхто не видалить) і – якщо сценарій DR цього вимагає – третя копія в цілком іншого постачальника, яку роблять rclone copy за розкладом. Три копії, дві різні системи, одна поза нашою інфраструктурою – тобто правило 3-2-1, тільки розписане на конкретику.

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

Чи реплікація замінює резервну копію? Ні, і це найважливіша річ, яку варто запам’ятати з цієї статті. Реплікація підтримує копію, узгоджену з джерелом, тож повторює також видалення, перезапис і шифрування файлів через ransomware. Резервною копією вона стає аж тоді, коли ціль має версіонування й блокування видалення – або коли реплікація за задумом ніколи нічого не видаляє.

Чи реплікація сповільнює записи до бакета? У методах 1–4 ні: копіювання асинхронне й діється після підтвердження запису. Відчутно сповільнює лише подвійний запис у застосунку, бо там користувач чекає на обидва сховища одразу.

Скільки триває перенесення 10 ТБ? Арифметика безжальна: при 50 MB/s це близько двох з половиною діб безперервного трансферу, при найвищому порозі швидкості – кільканадцять годин. На практиці вузьким місцем буває не ліміт смуги, а джерело (ліміти запитів у постачальника) або кількість об’єктів: мільйон дрібних файлів копіюється значно довше, ніж один файл тієї самої сумарної величини.

Чи можна реплікувати дані від іншого постачальника до WebDisk? Так – це саме завдання функції «Реплікація бакетів» у панелі Files. Достатньо endpointа та ключа доступу і таємного, якими видно список бакетів-джерел; решту робимо ми з нашого боку, а ви дивитеся на смугу поступу. Зворотний напрямок теж відкритий: ключі S3 до свого сховища ви маєте в панелі.

Чи реплікація переносить історію версій файлів? Нативна реплікація в S3 і multisite – так, бо оперують версіями. Інструменти на кшталт rclone чи aws s3 sync – ні: копіюють поточний стан об’єктів. Якщо історія має пережити міграцію, це треба спланувати окремо; частіше це розв’язують так, що історію тримає бекап, а не репліка.

А що із зашифрованими файлами – чи вони взагалі скопіюються? Залежить від того, хто має ключ, і від платформи. При шифруванні на боці сервера (SSE-S3, SSE-KMS) саме копіювання прозоре – з двома застереженнями: у нативній реплікації AWS об’єкти SSE-KMS треба явно допустити в правилі та вказати ключ у регіоні призначення (див. пастку 4), а в Ceph RGW копіювання на боці сервера зашифрованих об’єктів просто не реалізовано. При шифруванні ключем клієнта (SSE-C) кожна копія мусить пройти через процес, який знає ключ – тому такі об’єкти копіюють інструментом із ключем, а не командою «скопіюй на боці сервера».

Як перевірити, що копія повна? Порівнянням, а не довірою. Мінімум – це збіг кількості об’єктів і сумарного розміру з обох боків; серйозна версія – це rclone check --checksum (порівняння контрольних сум) або, при нативній реплікації, перевірка статусу реплікації об’єктів і метрик затримки. Міграція без такого приймання не є завершеною.

Скільки коштує утримання другої копії? Три позиції, а не одна: зберігання з другого боку, плата за запити і вихідний трафік із джерела – останній ви платите при кожному циклі, а не раз. При безперервній реплікації рахуйте його від обсягу змін, при міграції – від усього обсягу даних. Копія в того самого постачальника буває в трансфері безкоштовною, копія «назовні» – ніколи.

З чого почати, якщо сьогодні ми не маємо жодної другої копії? З найдешевшого кроку, який дає найбільше: увімкніть версіонування там, де лежать робочі дані, а резервні копії скеровуйте до окремого сховища з блокуванням видалення. Аж потім докладайте реплікацію – і оберіть її до проблеми, яку реально маєте (міграція, DR, географічна близькість), а не до гасла.

Чи копія в другому центрі даних входить у ціну? Розділімо дві речі. У ціну входить тривкість усередині кластера (три копії кожного об’єкта на окремих хостах) і в ціну входить міграція даних до WebDisk. Копія поза нашою інфраструктурою – це окремий сценарій DR: ви можете зробити її самі, ключами S3 з панелі й будь-яким інструментом, або озватися до нас і спроєктувати це разом. Ми воліємо сказати це прямо, ніж продавати слово «реплікація» як обіцянку, яка в кожного постачальника означає щось інше.

Підсумок

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

Три речі варто запам’ятати:

репліка вірна, а вірність буває вадою – видалення й шифрування поширюються разом із даними, тож другу копію треба загартувати версіонуванням і блокуванням запису, якщо вона має пережити поганий день,
міграція закінчується на перевірці, а не на повідомленні «готово» – контрольні суми, кількість об’єктів, розмір; а принагідно відтворення політик, правил lifecycle і CORS, які не їдуть разом з об’єктами,
реплікацію обирають до проблеми, а не до гасла – те саме слово означає цілком інше при міграції, при DR і при захисті від ransomware.

У WebDisk Files міграцію з будь-якого сховища, сумісного з S3, ви маєте готовою в панелі – Реплікація бакетів, із переглядом поступу, можливістю зупинення і без додаткової плати. Протестуйте WebDisk Files або напишіть нам, якщо хочете обговорити архітектуру другої копії для своїх даних: ми порадимо також тоді, коли найкращим рішенням виявиться копія поза нашою інфраструктурою.

Стаття є частиною циклу про безпеку даних у послугах WebDisk – раніше ми писали про основи object storage, шифрування в спокої (SSE-S3, SSE-KMS, SSE-C), доступ через STS/SSO і про незмінні копії з Object Lock. Приклади ви виконаєте на будь-якій платформі, сумісній з S3; параметр --endpoint-url у aws CLI вказує на endpoint вашого постачальника.

Реплікація бакетів S3: п’ять способів мати другу копію – і чого жоден з них не вирішує