Replikacja bucketów S3: metody, przykłady i pułapki

Blog WebDisk · kategoria: Object Storage · czas czytania: ~27 minut

W skrócie:- Replikacja bucketa – druga kopia obiektów w innym miejscu – ma pięć rodzin rozwiązań: reguła w samym S3, replikacja klastra (multisite), kopiowanie narzędziami (rclone), worker zdarzeniowy i podwójny zapis w aplikacji.- Wszystkie łączy jedna właściwość: replikacja powiela także skasowanie i nadpisanie. Replika nie jest kopią zapasową – staje się nią dopiero w parze z wersjonowaniem i blokadą zapisu (S3 Object Lock).- W WebDisk Files jest Replikacja bucketów: jednorazowy import magazynu zgodnego z S3 do nowego magazynu w WebDisk, z podglądem postępu – bez opłat za transfer, w ramach puli migracji zawartej w abonamencie. >Nie pracujesz z terminalem? Pomiń bloki poleceń – opis metod, sekcja o pułapkach i część o WebDisk dają pełny obraz.

Pytanie „czy mamy drugą kopię?” pada zwykle w najgorszym możliwym momencie: gdy ktoś skasował katalog, gdy dostawca ogłosił awarię regionu albo gdy zarząd zapytał, co się stanie, jeśli jutro trzeba będzie zmienić dostawcę. Odpowiedź „przecież mamy chmurę” nie wystarcza, bo chmura to nie jest jedno miejsce – to konkretny bucket, w konkretnej lokalizacji, z konkretnym kontem, które ktoś może przejąć.

Replikacja bucketów (bucket – pojemnik na pliki w magazynie S3, odpowiednik dysku czy udziału sieciowego; w usługach WebDisk nazywamy go magazynem) jest odpowiedzią na to pytanie – ale odpowiedzią częściową i łatwą do opacznego zrozumienia. W tym artykule przechodzimy przez wszystkie realnie używane metody replikacji danych w magazynie obiektowym: od gotowej reguły włączanej jednym poleceniem, przez replikację całych klastrów, po własnego workera nasłuchującego zdarzeń. Przy każdej pokazujemy przykład, koszt wejścia i to, czego dana metoda nie robi. Na końcu opisujemy, jak replikację rozwiązaliśmy w WebDisk Files.

Po co replikować bucket? Pięć różnych powodów, pięć różnych rozwiązań

Zanim wybierzesz technikę, nazwij problem – bo „replikacja” to jedno słowo na pięć różnych zadań, a rozwiązanie dobre dla jednego bywa bezużyteczne dla drugiego.

Odporność na awarię lokalizacji (DR, disaster recovery – odtwarzanie po katastrofie). Chcesz przetrwać utratę całego regionu, centrum danych albo klastra. Potrzebna jest kopia fizycznie gdzie indziej, najlepiej w innej domenie awarii i najlepiej z własnymi poświadczeniami.
Migracja i wyjście od dostawcy. Przenosisz dane z jednego S3 do drugiego – jednorazowo, ale kompletnie i weryfikowalnie. To nie jest replikacja ciągła, tylko kontrolowany transfer z odbiorem jakości; pisaliśmy o tym szerzej przy okazji vendor lock-inu.
Bliskość geograficzna. Kopia bliżej użytkowników albo bliżej obliczeń, żeby skrócić czas odpowiedzi. Tu liczy się opóźnienie propagacji, a nie trwałość.
Rozdzielenie środowisk i ról. Kopia produkcyjnych danych na potrzeby analityki, testów albo archiwum – często z filtrem, przycięta do jednego prefiksu i pozbawiona danych wrażliwych.
Izolacja kopii od konta produkcyjnego. Kopia w miejscu, do którego nie sięgają poświadczenia produkcji – po to, by przejęcie konta nie oznaczało utraty wszystkiego. To scenariusz anty-ransomware i ma własne reguły gry.

Zapamiętaj tę listę, bo wrócimy do niej przy wyborze metody: pierwszy punkt najlepiej obsługuje replikacja jednokierunkowa z zachowaniem historii, drugi – jednorazowe, weryfikowalne kopiowanie narzędziem, trzeci – natywna replikacja dostawcy, czwarty – kopiowanie z filtrem, a piąty – kopia w osobnym koncie z blokadą zapisu.

Replikacja, synchronizacja, backup – trzy słowa, które nie są synonimami

To rozróżnienie decyduje o tym, czy Twoja druga kopia cokolwiek uratuje.

Replikacja utrzymuje kopię zgodną ze źródłem. Jej celem jest to, żeby cel wyglądał tak jak źródło – łącznie z tym, że plik został skasowany. Dobra replikacja jest szybka i wierna; to jednocześnie znaczy, że wiernie powiela katastrofę.

Synchronizacja (rclone sync, aws s3 sync --delete) to replikacja robiona okresowo, w partiach – z tą samą właściwością: usuwa w celu to, czego nie ma w źródle.

Backup to kopia z historią i z ochroną przed zmianą: wiele punktów w czasie, retencja, niemożliwość skasowania przed terminem. Backup celowo nie jest zgodny ze źródłem – jego wartość polega właśnie na tym, że pamięta stan sprzed pomyłki.

Regułę 3-2-1 i różnicę między kopią a synchronizacją rozwijaliśmy w artykule o backupie w chmurze. Tutaj wystarczy jedno zdanie, które warto powiesić nad biurkiem: replika chroni przed utratą sprzętu, backup chroni przed utratą danych. To nie są zamienniki i większość poważnych wdrożeń ma jedno i drugie.

Cztery pytania, które wybierają metodę za Ciebie

Zanim przejdziemy do technik, cztery pytania. Odpowiedzi na nie zwykle zawężają wybór do jednej, najwyżej dwóch metod.

Jaki masz dopuszczalny RPO (Recovery Point Objective)? Ile minut – albo godzin – danych możesz stracić? Sekundy oznaczają replikację zdarzeniową albo natywną; godziny – spokojnie wystarczy zaplanowane kopiowanie narzędziem.
Czy oba końce są u tego samego dostawcy? Natywna replikacja S3 zwykle działa w obrębie jednej platformy. Między różnymi dostawcami niemal zawsze zostają narzędzia albo własny worker.
Czy kopia ma pamiętać historię? Jeśli tak, potrzebujesz wersjonowania po obu stronach i metody, która wersje przenosi – albo świadomej decyzji, że kopia jest „płaska”, a historię trzyma backup.
Kto płaci za transfer i kto ma klucze? Kopia u tego samego dostawcy bywa darmowa, kopia „na zewnątrz” kosztuje ruch wychodzący. A kopia dostępna z tych samych kluczy co produkcja nie chroni przed przejęciem konta.

Metoda 1. Reguła replikacji w samym S3: magazyn pilnuje kopii sam

Najprostsza koncepcyjnie i najbardziej „chmurowa” metoda: mówisz magazynowi, że ma sam pilnować kopii. Konfiguracja żyje na buckecie źródłowym jako reguła replikacji, a całą robotę wykonuje warstwa magazynu – bez żadnej maszyny po Twojej stronie.

Trzy rzeczy trzeba mieć, żeby to w ogóle ruszyło:

wersjonowanie po obu stronach – replikacja operuje na wersjach obiektów, nie na nazwach; bez wersjonowania nie ma czego replikować (to ten sam fundament, na którym stoi Object Lock),
tożsamość z uprawnieniami do obu bucketów – w AWS jest to rola IAM, którą usługa S3 przyjmuje w Twoim imieniu,
regułę – z filtrem (cały bucket, prefiks albo tag), priorytetem i opisem celu.

Zanim zaczniesz. Przykłady używają aws CLI i rclone skonfigurowanych jak w poprzednich artykułach cyklu (aws configure + --endpoint-url Twojego dostawcy – pomijamy go niżej dla czytelności). Ostrożnie z prawdziwymi danymi: rclone sync i aws s3 sync --delete usuwają w celu to, czego nie ma w źródle, a literówka w prefiksie źródła potrafi wyczyścić kopię. Ćwicz na testowych bucketach.

Praktyczny przykład w AWS. Najpierw wersjonowanie, potem sama reguła:

# 1. wersjonowanie na źródle i na celu — warunek konieczny
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. reguła replikacji: wszystko, co wpada do „raporty/”, ląduje w drugim buckecie
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"
      }
    }]
  }'

Sprawdzenie, czy konkretny obiekt został już skopiowany, jest równie proste – status replikacji widać w jego metadanych:

aws s3api head-object --bucket firma-produkcja --key raporty/2026-08.csv
# "ReplicationStatus": "COMPLETED" ← albo PENDING / FAILED
# na kopii ten sam obiekt raportuje "REPLICA"

Zwróć uwagę na DeleteMarkerReplication. To jedno pole decyduje o charakterze całego rozwiązania: włączone – kopia jest wiernym lustrem i „zniknięcie” pliku propaguje się na drugą stronę; wyłączone – skasowany plik zostaje w kopii. Dla replikacji rozumianej jako DR wyłączenie bywa świadomym wyborem, ale trzeba wiedzieć, że robi się wtedy kopię, która z czasem się rozjeżdża ze źródłem i sama nie posprząta.

Druga rzecz, o której łatwo zapomnieć: skasowanie konkretnej wersji nigdy nie jest replikowane: jeśli w żądaniu DELETE podasz identyfikator wersji, zniknie ona wyłącznie w źródle. To celowa właściwość ochronna – i dobra wiadomość dla scenariusza „ktoś przejął konto i czyści dane”. Uwaga na jeden szczegół migracyjny: starsze konfiguracje (bez elementu Filter) domyślnie replikowały znaczniki usunięcia z akcji użytkownika, a nowsze – nie. Dopisanie filtra do starej reguły po cichu zmienia więc zachowanie przy kasowaniu.

Trzy niespodzianki, które ta metoda trzyma w zanadrzu:

Reguła działa od momentu włączenia. Obiekty, które leżały w buckecie wcześniej, nie zostaną skopiowane same – u hiperskalera trzeba dla nich uruchomić osobne zadanie masowe (w AWS: S3 Batch Replication), a poza nim po prostu skopiować je zwykłym narzędziem (metoda 3, opisana niżej). Dotyczy to także każdej przerwy w działaniu reguły – wracamy do tego w pułapce 6.
Replikacja nie tworzy łańcuchów. Kopia w buckecie B nie pojedzie do C, nawet jeśli B ma własną regułę. Łańcuchów się nie buduje – każdy cel podłącza się osobno do źródła.
Filtr po tagach łapie tylko tagi nadane przy zapisie. Otagowanie pliku po fakcie nie uruchamia replikacji, co skutecznie wysadza popularny wzorzec „najpierw wgraj, potem sklasyfikuj”. Filtr po prefiksie takiego problemu nie ma.

Jeśli replikacja ma mieć umowne ramy czasowe, u hiperskalera dokupuje się je osobno: S3 Replication Time Control zobowiązuje dostawcę do przeniesienia 99,9% nowych obiektów w ciągu 15 minut i dokłada do tego metryki oraz zdarzenia o przekroczeniu progu. Bez tej opcji AWS nie składa żadnej obietnicy: dokumentacja mówi tylko, że większość obiektów replikuje się w ciągu 15 minut, przy dużych potrafi to zająć kilka godzin, a w skrajnych przypadkach nawet kilkadziesiąt – bez SLA. W praktyce jest to zwykle kwestia sekund, ale w audycie liczy się zobowiązanie, nie praktyka.

Kiedy warto: oba końce są u tego samego dostawcy, zależy Ci na małym RPO i nie chcesz utrzymywać własnej infrastruktury kopiowania. Czego nie załatwi: przeniesienia danych do innego dostawcy, historii sprzed włączenia reguły ani ochrony przed skasowaniem – to ostatnie dokłada się osobno, wersjonowaniem i blokadą na buckecie docelowym.

Metoda 2. Replikacja na poziomie klastra: multisite, czyli własność platformy

Metoda dla tych, którzy mają dwa magazyny obiektowe – dwa klastry, dwie serwerownie – i chcą, żeby replikacja była własnością platformy, a nie każdego bucketa z osobna. W Ceph RGW nazywa się to multisite, w MinIO – replikacją instalacji.

W Ceph hierarchia wygląda tak: realm (przestrzeń nazw) zawiera zonegroup, a w niej mieszkają strefy (zone) – po jednej na lokalizację, każda oparta na własnym klastrze Ceph. Strefy wymieniają między sobą dwa niezależne strumienie: metadane (użytkownicy, buckety, polityki – zarządzane centralnie przez strefę główną) i dane (obiekty – synchronizowane przez każdą strefę z osobna). Robią to same demony RGW, bez żadnego zewnętrznego agenta.

# lokalizacja A — realm, grupa stref i strefa główna
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

# użytkownik systemowy — tym kluczem strefy uwierzytelniają się między sobą
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

# lokalizacja B — druga strefa w tej samej grupie; najpierw ściąga realm i 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

# codzienna diagnostyka: czy strefa nie zostaje w tyle
radosgw-admin sync status
# szukasz shardów „behind” (do nadgonienia) i „recovery” (błąd, zaplanowana ponowna próba)

Replikacja jest asynchroniczna, ze spójnością ostateczną – zmiany propagują się w tle, a kolejne porcje dziennika zmian są odpytywane co kilkanaście–kilkadziesiąt sekund. To znaczy dokładnie tyle, że tuż po zapisie druga lokalizacja jeszcze obiektu nie ma i że przełączenie na zapasową strefę jest decyzją operatora, a nie automatem: promuje się ją ręcznie, najlepiej po upewnieniu się, że nadgoniła zaległości.

Nowsze wydania Ceph pozwalają replikować wybrane buckety zamiast całej strefy – służy do tego granularna polityka synchronizacji zbudowana z trzech warstw: grupy (czy replikacja jest dozwolona), przepływu (w którą stronę płyną dane – wzajemnie albo jednokierunkowo) i „rury” (co konkretnie i dokąd). Zalecany wzorzec to zezwolić szeroko na poziomie grupy stref, a włączać punktowo na poziomie bucketa:

# na poziomie grupy stref: „wolno, ale nie włączam wszystkiego”
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

# na poziomie konkretnego bucketa: „ten replikuj” (bez 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 # co realnie popłynie i dokąd

Rura potrafi przy okazji filtrować (prefiks, tagi) i przekształcać cel: replikować do bucketa o innej nazwie, na innego właściciela albo do innej klasy składowania. Jest też osobny moduł, który wypycha dane jednokierunkowo do zewnętrznego S3 – czyli do zupełnie obcego dostawcy, bez stawiania drugiego klastra Ceph.

Najciekawszy dla bezpieczeństwa wariant to strefa archiwalna (archive zone): strefa, która wymusza wersjonowanie i trzyma kolejne wersje wszystkiego, co przepłynęło przez klaster, a obiekty da się z niej usunąć wyłącznie przez jej własne bramy. To jedyna odmiana replikacji na poziomie klastra, która broni się przed pomyłką operatora i przed ransomware, bo zrywa kluczowe założenie „kopia ma wyglądać jak oryginał”. Praktyczny układ wygląda tak: produkcja pracuje na zwykłych, niewersjonowanych strefach, a obok stoi archiwum, do którego nikt z produkcji nie ma jak sięgnąć.

Kiedy warto: masz (albo kupujesz) dwie lokalizacje i chcesz replikacji przezroczystej dla klientów – łącznie z kontami i politykami. Czego nie załatwi: niczego, jeśli druga lokalizacja nie istnieje. Multisite to decyzja infrastrukturalna i kosztowa, nie przełącznik w panelu; wymaga drugiego klastra, łącza, które uniesie strumień zmian, i dyscypliny przy aktualizacjach (nowe funkcje włącza się dopiero wtedy, gdy rozumieją je wszystkie strefy).

Czy Twój dostawca w ogóle to ma? Przegląd dziewięciu platform

Stan na sierpień 2026. Zanim zaplanujesz replikację na regule w buckecie, sprawdź, czy jest czym ją włączyć. To najczęstsze rozczarowanie w tym temacie: natywna replikacja jest funkcją platformy, a nie częścią standardu S3. Protokół jest wspólny, ale to, czy w ogóle istnieje reguła replikacji i co dokładnie robi, bywa różne u każdego dostawcy.

AWS S3 – pełna replikacja natywna, w tym samym regionie i między regionami, z opcjonalnym umownym czasem propagacji i osobnym zadaniem masowym do obiektów istniejących.
OVHcloud – replikacja natywna, asynchroniczna, konfigurowana standardowym put-bucket-replication; wersjonowanie trzeba włączyć samodzielnie na źródle i na celu (samo robi to tylko osobna opcja replikacji poza lokalizację, zaznaczana przy tworzeniu bucketa w regionach trójstrefowych), jest też osobny tryb wsadowy dla obiektów zapisanych wcześniej. Oba buckety muszą leżeć w tym samym projekcie.
Wasabi – replikacja natywna, sterowana wywołaniami zgodnymi z S3. Ciekawostka: nie wymaga wersjonowania, wymaga natomiast zgodnego stanu po obu stronach (wersjonowany do wersjonowanego, niewersjonowany do niewersjonowanego) i tego samego właściciela bucketów.
Backblaze B2 – replikacja natywna, ale konfigurowana własnym API i CLI, nie przez interfejs S3; do dwóch reguł na bucket, z opcją objęcia plików istniejących. Za sam ruch replikacyjny nie płacisz – płacisz za drugą kopię danych.
Google Cloud Storage – replikacja jest właściwością bucketa, nie regułą: wybierasz bucket dwuregionalny albo wieloregionalny i tyle. Nominalny cel to komplet obiektów w 12 godzin, a za dopłatą (turbo) – 15 minut.
Azure Blob – dwie rozłączne warstwy: georedundancja całego konta (GRS/GZRS) oraz replikacja obiektowa między kontenerami, wymagająca wersjonowania po obu stronach i strumienia zmian na źródle.
MinIO – ma zarówno replikację per bucket, jak i replikację całych instalacji (razem z użytkownikami i politykami), ale trzeba znać stan projektu: repozytorium wydania społecznościowego zostało w kwietniu 2026 zarchiwizowane, a w komercyjnym AIStorze replikacja należy do funkcji płatnych planów. Replikacja serwerowa łączy przy tym wyłącznie instalacje MinIO ze sobą.
Ceph RGW – multisite i granularna polityka synchronizacji, opisane wyżej; u dostawcy opartego na Ceph pytanie brzmi więc po prostu: czy macie drugą strefę.
DigitalOcean Spaces, Scaleway, Cloudflare R2 – natywnej replikacji bucket-to-bucket brak. R2 nadrabia to dwoma narzędziami migracyjnymi (hurtowym przeniesieniem i przyrostowym dociąganiem obiektów na żądanie), a u pozostałych zostaje metoda 3.

Praktyczny wniosek jest taki, że przy scenariuszu „kopia u innego dostawcy” niemal zawsze wraca się do narzędzi – bo nawet gdy obie platformy mają replikację natywną, prawie nigdy nie potrafią jej ze sobą uzgodnić.

Metoda 3. Kopiowanie narzędziami: rclone, mc, s5cmd i aws s3 sync

Najbardziej uniwersalna metoda i – wbrew pozorom – najczęściej używana w praktyce. Nie wymaga zgody ani wsparcia dostawcy po żadnej stronie: bierzesz dwa endpointy S3, dwa komplety kluczy i przepychasz dane. Działa między dowolnymi platformami, więc to ona ratuje przy migracjach i przy wyjściu od dostawcy.

Królem tej kategorii jest rclone, bo rozumie kilkadziesiąt backendów i ma dokładnie te przełączniki, które w tym zadaniu są potrzebne:

# konfiguracja dwóch zdalnych: rclone config (typ: s3, provider: AWS / Ceph / Minio / Other)

# 1. kopia przyrostowa BEZ kasowania czegokolwiek w celu — bezpieczny domyślny wybór
rclone copy zrodlo:firma-produkcja cel:firma-kopia --progress

# 2. pełne lustro: cel wygląda dokładnie jak źródło (USUWA nadmiarowe pliki!)
rclone sync zrodlo:firma-produkcja cel:firma-kopia --progress

# 3. wersja produkcyjna: równoległość pod S3, porównanie po sumach kontrolnych,
# hurtowe listowanie i limit pasma zmienny w ciągu doby (wartości w BAJTACH/s)
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. odbiór jakości — czy obie strony naprawdę mają to samo
rclone check zrodlo:firma-produkcja cel:firma-kopia --one-way --checksum

Różnica między copy i sync to nie niuans, tylko wybór strategii: copy daje kopię, która nigdy sama niczego nie usunie (rośnie, ale przeżyje skasowanie na produkcji), sync daje lustro (jest zgodne, ale powtórzy każdą katastrofę – łącznie z literówką w prefiksie źródła, która potrafi wyczyścić cel). Do celu DR zwykle chcesz copy – albo sync na buckecie z włączonym wersjonowaniem, gdzie „usunięcie” jest tylko znacznikiem.

Cztery szczegóły, które odróżniają działającą replikację od pozornie działającej:

Domyślnie rclone porównuje rozmiar i czas modyfikacji, a czas modyfikacji zapisuje na S3 we własnej metadanej. Obiekty wgrane innym narzędziem tej metadanej nie mają, więc porównanie opiera się wtedy na serwerowym LastModified, który zmienia się przy każdej kopii – i kolejny przebieg potrafi uznać wszystko za rozbieżne. Stąd --checksum w przykładzie wyżej.
--checksum na S3 porównuje MD5, którego obiekty wieloczęściowe (multipart) nie mają w ETagu. rclone radzi sobie z tym własną metadaną przy swoich uploadach, ale dla dużych plików wgranych czymś innym po prostu nie ma czego porównać. To jest ta sama pułapka, o której piszemy niżej w sekcji o weryfikacji.
Kopia z S3 do S3 domyślnie przechodzi przez Twoją maszynę. Między dwiema różnymi konfiguracjami rclone pobiera dane i wysyła je z powrotem, chyba że jawnie podasz --server-side-across-configs (a między różnymi dostawcami kopiowanie po stronie serwera nie zadziała nigdy). Przy 50 TB to różnica między transferem 50 a 100 TB – i odpowiedni rachunek za ruch wychodzący.
Uruchamiaj to z blokadą. Najczęstszy sposób, w jaki taka replikacja sama się przewraca, to nakładające się przebiegi z crona. Minimum to flock -n, ładniej – timer systemd z Type=oneshot i Persistent=true, który nie odpali drugiej instancji tej samej jednostki i odrobi przebieg po restarcie hosta.

# /etc/cron.d/replikacja — co godzinę, z blokadą przed nakładaniem się przebiegów
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

Alternatywy, które warto znać:

s5cmd – gdy liczy się surowa przepustowość przy setkach tysięcy obiektów; zrównolegla znacznie agresywniej niż aws s3 sync. Ceną jest brak limitowania pasma (potrafi zająć całe dostępne łącze) i brak porządnej weryfikacji integralności; do tego działa na jednym komplecie poświadczeń, więc transfer między dwoma różnymi dostawcami musi u niego przejść przez dysk lokalny.
aws s3 sync – jest wszędzie tam, gdzie jest AWS CLI, i wystarcza do prostych zadań. Ma jednostronny test „źródło nowsze”, a przy kopii z S3 do S3 domyślnie przenosi tagi i część właściwości obiektu (--copy-props default) – kosztem dodatkowych żądań. Od niedawna potrafi też zaskoczyć poza AWS. Nowsze wydania CLI domyślnie liczą sumy kontrolne przy każdym zapisie; starsze implementacje zgodne z S3 tego nie znają i odpowiadają błędem. To najczęstsze „nagle przestało działać” ostatnich miesięcy; leczy się przełączeniem sum kontrolnych na tryb „tylko gdy wymagane” w konfiguracji CLI.
mc mirror --watch (klient MinIO) – kusi obietnicą ciągłego nasłuchu zamiast uruchomień z crona, ale nasłuch opiera się na rozszerzeniu specyficznym dla MinIO. Na AWS S3 czy Ceph RGW skończy się to błędem albo cichym przejściem na zwykłe odpytywanie – czyli dokładnie tym, czego chciałeś uniknąć. Poza MinIO traktuj mc jak zwykłe narzędzie kopiujące – tagi obiektów przy kopii z S3 do S3 przenosi zresztą także aws s3 cp/sync; tym, który tagów nie przenosi, jest akurat rclone.

Kiedy warto: różni dostawcy po obu stronach, migracja, przycięcie kopii filtrem, pełna kontrola nad tym, co i kiedy się kopiuje. Czego nie załatwi: małego RPO – kopia jest tak świeża, jak ostatnie uruchomienie. Nie przeniesie historii: żadne z tych narzędzi nie kopiuje wersji obiektów ani znaczników usunięcia, a Object Locka i konfiguracji bucketa nie odtworzy nawet w przybliżeniu. Nie zdejmie też z Ciebie kosztu ruchu wychodzącego, który przy każdym cyklu płacisz u dostawcy źródła. Przy milionach małych obiektów sam przegląd listy potrafi kosztować więcej niż transfer; przy tej skali sensowniej wygląda metoda 4.

A jeśli w buckecie leży repozytorium backupu, a nie pliki?

Osobna, często pomijana ścieżka to replikacja repozytorium backupowego zamiast replikacji danych. Jeśli do bucketa pisze narzędzie backupowe – restic, Kopia albo Veeam – drugą kopię robi się jego własnymi środkami (kopia repository sync-to, backup copy job w Veeamie) albo – w przypadku resticowego repozytorium, które jest zbiorem niemodyfikowalnych plików – zwykłym rclone sync --checksum. Trzeba tylko wiedzieć, co się przy tym traci: bajtowa kopia repozytorium dzieli klucz szyfrujący z oryginałem i podlega tym samym operacjom czyszczenia, a restic copy przeciwnie – tworzy kopię niezależną kryptograficznie, ale musi ściągnąć i zaszyfrować od nowa całość. W przypadku Veeama sprawa jest prosta i warto to powtórzyć za producentem: cyklem życia danych w magazynie obiektowym zarządza wyłącznie Veeam, a ręczne kopiowanie czy dokładanie reguł lifecycle na jego buckecie potrafi skończyć się utratą danych.

Metoda 4. Replikacja zdarzeniowa: niech magazyn sam powie, co się zmieniło

Zamiast pytać magazyn „co się zmieniło od wczoraj?”, pozwól mu samemu to powiedzieć. Magazyny obiektowe potrafią wysłać powiadomienie o każdym zapisie i skasowaniu: do kolejki, do brokera, na endpoint HTTP. Powiadomienie odbiera własny proces i kopiuje dokładnie ten jeden obiekt, którego dotyczy.

W Ceph RGW konfiguruje się to jako „temat” i przypiętą do bucketa notyfikację. Sama notyfikacja na buckecie jest zgodna z S3, ale tworzenie tematu poniżej to już rozszerzenie RGW: atrybuty push-endpoint i persistent są własnością Ceph, a identyfikator tematu ma postać arn:aws:sns:<grupa-stref>:<najemca>:<temat>. Na AWS ten sam efekt składa się inaczej – osobno tworzysz temat, osobno dajesz S3 prawo publikowania w nim, a odbiorcę podpinasz subskrypcją:

# 1. temat: dokąd mają iść powiadomienia (tu: HTTP; równie dobrze Kafka albo AMQP).
# Wywołania sns kierujemy na endpoint bramy 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. notyfikacja na buckecie: interesują nas zapisy i skasowania
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 po drugiej stronie jest banalny w opisie i wymagający w szczegółach: odbiera zdarzenie, pobiera obiekt ze źródła, zapisuje w celu, potwierdza. Cała trudność siedzi w tym, co się dzieje, gdy coś pójdzie nie tak – potrzebne są ponowienia, kolejka nieudanych zdarzeń (dead-letter), odporność na powtórzone dostarczenie tego samego zdarzenia i świadomość, że kolejność nie jest gwarantowana. Trzeba też pamiętać, że zdarzenia opisują przyszłość: to, co leżało w buckecie przed włączeniem notyfikacji, i tak wymaga jednorazowego skopiowania narzędziem z metody 3.

Kiedy warto: duże wolumeny, dużo drobnych zapisów, RPO liczone w sekundach, potrzeba replikacji między różnymi dostawcami z zachowaniem świeżości. Czego nie załatwi: nic tu nie dzieje się samo – wszystko stoi na Twoim kodzie i Twoim utrzymaniu. To najbardziej „własne” z rozwiązań – daje najwięcej kontroli i najwięcej rzeczy, które trzeba monitorować.

Metoda 5. Podwójny zapis w aplikacji: brzmi najprościej, wychodzi najdrożej

Ostatnia rodzina to replikacja przeniesiona do aplikacji: przy każdym zapisie wysyłasz obiekt do dwóch magazynów naraz. Brzmi to najprościej ze wszystkich i bywa kuszące, gdy magazyn jest tylko dodatkiem do produktu.

W praktyce podwójny zapis przenosi na Ciebie wszystkie problemy systemów rozproszonych. Co zrobić, gdy pierwszy zapis się powiódł, a drugi nie – odrzucić operację użytkownikowi czy przyjąć i naprawić później? Jak nadrobić rozjazd po awarii drugiego magazynu? Skąd wziąć kopię plików zapisanych, zanim dopisałeś tę funkcję? Każda odpowiedź to kawałek kodu, który powiela to, co warstwa magazynu ma gotowe i przetestowane.

Kiedy warto: gdy druga kopia ma być inna niż pierwsza – na przykład zapisujesz oryginał do S3, a jego przetworzoną wersję do zupełnie innego systemu. Wtedy to nie jest replikacja, tylko logika produktu, i słusznie siedzi w aplikacji. Czego nie załatwi: spójności bez sporego wysiłku. Jeśli obie kopie mają być identyczne, prawie zawsze taniej wypada metoda 1, 3 albo 4 z tego artykułu.

Warstwa, o której się zapomina: trwałość wewnątrz klastra

Powyższe metody odpowiadają na pytanie „co, jeśli stracimy całą lokalizację?”. Jest jednak warstwa niżej, która odpowiada na pytanie znacznie częstsze: „co, jeśli padnie dysk albo serwer?”. W magazynach obiektowych rozwiązuje ją sam klaster – i to też bywa nazywane replikacją, co jest źródłem wielu nieporozumień w rozmowach z dostawcami.

Replikacja n-krotna – każdy obiekt trzymany w kilku pełnych kopiach na różnych hostach (typowo trzech). Prosta, szybka w odbudowie, kosztuje tyle miejsca, ile wynosi mnożnik.
Kodowanie nadmiarowe (erasure coding) – obiekt dzielony na fragmenty danych i fragmenty parzystości rozłożone po węzłach. Tańsze pojemnościowo przy porównywalnej odporności, droższe obliczeniowo i wolniejsze w odbudowie.

Obie techniki bronią przed awarią sprzętu w obrębie jednego klastra i żadna nie jest disaster recovery: skasowanie obiektu przez użytkownika propaguje się natychmiast do wszystkich kopii i fragmentów. Gdy dostawca mówi „replikujemy Twoje dane trzykrotnie”, zadaj mu dwa pytania: czy te trzy kopie są w różnych lokalizacjach i co się dzieje, gdy ktoś wyda DELETE.

Którą metodę wybrać? Porównanie w pigułce

Tych samych pięć metod, ułożonych według kryteriów, które realnie decydują o wyborze:

Typowe RPO (ile danych możesz stracić) – reguła w S3: sekundy–minuty · multisite: sekundy–minuty · narzędzia z crona: tyle, ile wynosi odstęp między uruchomieniami · zdarzeniowa: sekundy · podwójny zapis: zero (albo rozjazd, gdy jeden zapis padnie).
Czy działa między różnymi dostawcami – reguła w S3: zwykle nie · multisite: między klastrami tej samej platformy, choć moduł synchronizacji do chmury potrafi wypychać jednokierunkowo do obcego S3 · narzędzia: tak, zawsze · zdarzeniowa: tak · podwójny zapis: tak.
Ile własnej infrastruktury wymaga – reguła w S3: żadnej · multisite: drugi klaster · narzędzia: jedna maszyna z dostępem do obu końców · zdarzeniowa: worker, kolejka i ich monitoring · podwójny zapis: kod aplikacji.
Czy przenosi historię wersji – reguła w S3: tak (replikuje wersje) · multisite: tak · narzędzia: nie (kopiują stan bieżący) · zdarzeniowa: tylko to, co sam skopiujesz · podwójny zapis: nie.
Czy powiela skasowanie – reguła w S3: zależy od DeleteMarkerReplication · multisite: tak, poza strefą archiwalną · narzędzia: sync tak, copy nie · zdarzeniowa: zależy od Twojego workera · podwójny zapis: zależy od kodu.
Główny koszt – reguła w S3: transfer między regionami i opłaty za żądania · multisite: druga lokalizacja · narzędzia: ruch wychodzący i czas maszyny · zdarzeniowa: utrzymanie i dyżur · podwójny zapis: dług techniczny.

W skrócie, po scenariuszach: migracja albo wyjście od dostawcy – rclone (metoda 3) z check na koniec. DR w obrębie jednego dostawcy – reguła replikacji (metoda 1) na buckecie z wersjonowaniem. DR między dostawcami – rclone copy w harmonogramie albo worker zdarzeniowy, jeśli RPO ma być liczone w sekundach. Kopia odporna na ransomware – dowolna metoda, byle cel miał wersjonowanie i blokadę zapisu, a poświadczenia do niego były inne niż produkcyjne.

Sześć pułapek, na które wpada się przy pierwszym wdrożeniu

1. Replika ginie razem z oryginałem. Najważniejsza z pułapek i jedyna rzecz, którą powtarzamy w tym tekście celowo: skasowanie, nadpisanie i zaszyfrowanie przez ransomware jest zmianą jak każda inna i replikacja przeniesie ją na kopię – zwykle w kilkanaście sekund. Nie jest to teoria: w styczniu 2025 opisano publicznie kampanię, w której napastnicy z ważnymi kluczami dostępu szyfrowali zawartość bucketów mechanizmem samego S3 (kluczem klienta), zostawiając ofierze magazyn pełen nieczytelnych obiektów – bez włamania do serwera, wyłącznie zwykłymi żądaniami S3. Kopia broni więc przed awarią sprzętu i lokalizacji, nie przed człowiekiem ani napastnikiem. Lekarstwem jest wersjonowanie po stronie celu plus blokada zapisu (Object Lock, strefa archiwalna) albo tryb „tylko dopisuj” (copy zamiast sync). Sam protokół pomaga tu bardziej, niż się wydaje: usunięcie konkretnej wersji nigdy nie jest replikowane, a znacznik usunięcia w nowszych konfiguracjach – domyślnie też nie.

2. Obiekty sprzed włączenia reguły nie zostaną skopiowane. Replikacja obejmuje przyszłość. Historia wymaga jednorazowego przepchnięcia – zadaniem masowym u dostawcy albo rclone copy – i o tym najłatwiej zapomnieć, bo panel pokazuje „replikacja włączona” i wszystko wygląda dobrze.

3. Kopia to nie wszystko, co miał bucket. Standardowo przenoszą się obiekty i ich metadane. Nie przenoszą się same z siebie: polityki bucketa, konfiguracja CORS, reguły lifecycle, ustawienia szyfrowania domyślnego, konfiguracja powiadomień i – w metodach narzędziowych – historia wersji oraz znaczniki usunięcia. Nie przenoszą się razem z obiektami, więc po migracji trzeba je odtworzyć ręcznie – inaczej nowy bucket wygląda tak samo, a zachowuje się inaczej.

4. Szyfrowanie zmienia reguły gry – i to inaczej w każdej metodzie. W natywnej replikacji AWS obiekty zaszyfrowane po stronie serwera domyślnym kluczem (SSE-S3) albo kluczem klienta (SSE-C) kopiują się bez dodatkowej konfiguracji – ale obiekty z kluczem zarządzanym (SSE-KMS) domyślnie nie replikują się w ogóle: trzeba je jawnie włączyć w regule i wskazać klucz utworzony w regionie docelowym. Pułapka jest podstępna, bo zapis takiej konfiguracji z niepoprawnym kluczem kończy się odpowiedzią „OK”, a replikacja pada dopiero przy pierwszym obiekcie. W metodach narzędziowych jest dokładnie odwrotnie: to SSE-C blokuje kopiowanie po stronie serwera – magazyn bez klucza nie odszyfruje źródła ani nie zaszyfruje kopii, więc bajty muszą przejść przez proces, który klucz zna (w Ceph RGW kopiowanie po stronie serwera obiektów szyfrowanych w ogóle nie jest zaimplementowane – CopyObject odpowiada NotImplemented). Trzy warianty szyfrowania rozbieraliśmy w osobnym tekście o SSE-S3, SSE-KMS i SSE-C.

5. „Skopiowało się” to nie to samo co „zgadza się”. Duże pliki wysyłane są w częściach (multipart), a ich ETag przestaje być zwykłą sumą MD5 – porównywanie po nim daje fałszywe wyniki. Ta sama pułapka wraca od innej strony przy natywnej replikacji: jeśli obiekt na źródle jest nieszyfrowany, a bucket docelowy ma włączone szyfrowanie domyślne, replika dostanie inny ETag niż oryginał – i każdy skrypt porównujący ETagi ogłosi rozjazd, którego nie ma. Odbiór jakości robi się więc przez sumy kontrolne (rclone check --checksum) albo przez porównanie liczby obiektów i sumarycznych rozmiarów po obu stronach. Dopóki nie zrobisz tego porównania, migracja jest tylko deklaracją.

6. Cicha awaria replikacji. Replikacja psuje się dyskretnie: wygasłe poświadczenia, zmieniona polityka, pełny cel, zatrzymany worker. Bucket dalej przyjmuje zapisy, panel nie krzyczy, a kopia po prostu przestaje rosnąć. Gorzej: w natywnej replikacji obiekt, którego nie udało się skopiować, nie zostanie ponowiony sam – żeby go dogonić, trzeba go wgrać jeszcze raz albo uruchomić zadanie masowe. Tak samo działa wyłączenie reguły „na chwilę”: po ponownym włączeniu zaległości nie nadrabiają się automatycznie. Dlatego do każdej z tych metod należy dołożyć monitoring – status synchronizacji (radosgw-admin sync status), metryki opóźnienia i liczby obiektów oczekujących u dostawcy, powiadomienia o nieudanej replikacji. Albo najprostszy z możliwych czujników: alert, gdy liczba obiektów w kopii przestaje nadążać za źródłem.

Ile kosztuje druga kopia – i w jakiej jurysdykcji leży?

U hiperskalerów transfer opuszczający region jest płatny; przy replikacji ciągłej płacisz go za każdą zmianę, a przy pełnej migracji – za cały wolumen. Do tego dochodzą opłaty za same żądania, a te przy replikacji natywnej potrafią zaskoczyć: skopiowanie jednego obiektu to po stronie źródła nawet kilka odczytów i zapis. Rachunek za drugą kopię ma więc trzy pozycje, nie jedną: składowanie, żądania i transfer. Jedna dobra wiadomość regulacyjna: unijny Data Act wygasza opłaty za samą zmianę dostawcy – od stycznia 2027 nie wolno ich pobierać – ale bieżącej replikacji to nie dotyczy, bo to zwykły ruch wychodzący, a nie migracja przy wypowiedzeniu umowy. Ile to potrafi znaczyć w skali roku, liczyliśmy w tekstach o rachunku za chmurę publiczną i o różnicach między hiperskalerem a lokalnym dostawcą.

Druga strona tego samego rachunku jest prawna: replika ma lokalizację. Kopia „gdzieś w chmurze” bywa kopią poza Europejskim Obszarem Gospodarczym, co jest zdarzeniem prawnym, nie tylko operacyjnym. Uruchomienie repliki w innym kraju jest zmianą w przetwarzaniu: dotyka umowy powierzenia, rejestru czynności i oceny ryzyka, a nie tylko pliku konfiguracyjnego. Lokalizację obu końców ustala się więc przed pierwszym transferem, a nie po audycie – o tym, dlaczego pytanie „gdzie fizycznie leżą dane i ich kopie” ma także wymiar jurysdykcyjny, pisaliśmy w artykule o polskiej chmurze obliczeniowej.

Jak robimy to w WebDisk Files?

W panelu organizacji WebDisk Files – w części dostępnej dla administratora organizacji – jest funkcja o nazwie wprost: Replikacja bucketów. Odpowiada na ten scenariusz z listy na początku, o który klienci pytają najczęściej – „mamy dane u innego dostawcy i chcemy je mieć u was” – i robi to bez terminala i bez pośredniczącej maszyny po Twojej stronie, w granicach puli bezpłatnych migracji i bez pytania nas o zgodę.

Wygląda to tak:

Podajesz adres endpointu źródłowego, klucz dostępu i klucz tajny – do dowolnego, publicznie dostępnego magazynu zgodnego z S3. Z listy wybierasz typ dostawcy (AWS, Ceph/RGW, MinIO, Wasabi, DigitalOcean Spaces albo „inny, zgodny z S3”), bo różne implementacje mają swoje drobne odmienności i warto je uwzględnić z góry.
Klikasz „Pokaż buckety”. Sprawdzamy poświadczenia od razu i pokazujemy listę bucketów widocznych dla tych kluczy – dzięki temu literówka w kluczu wychodzi w pierwszej sekundzie, a nie po godzinie kopiowania. (Klucz musi mieć prawo do wylistowania bucketów – nazwy źródła nie wpisuje się z palca, wybiera się ją z listy.)
Wybierasz bucket źródłowy, nazywasz nowy magazyn po naszej stronie i wybierasz prędkość kopiowania. Podstawowa prędkość to 50 MB/s, najwyższa dziś dostępna – 250 MB/s; wybrany limit obowiązuje przez całą migrację, dzięki czemu kopiowanie nie wysyca łącza w nieprzewidywalny sposób.
Naciskasz „Synchronizuj” i patrzysz na postęp: przekopiowane bajty i procent całości, bieżąca prędkość, przewidywany czas do końca, a gdyby coś poszło nie tak – komunikat błędu przy migracji. Migrację możesz zatrzymać w dowolnej chwili – pliki już skopiowane zostają w nowym magazynie.

Pod spodem działa dokładnie to, co opisaliśmy w metodzie 3, tyle że jako usługa: dla każdej migracji uruchamiamy osobnego, jednorazowego workera z rclone. Worker pobiera swoją konfigurację tokenem ważnym tylko dla tej jednej migracji, tym samym tokenem zgłasza postęp do panelu i znika po zakończeniu pracy. Kilka decyzji projektowych, które warto znać:

Klucz tajny do źródła trzymamy zaszyfrowany w bazie (identyfikator klucza dostępu, jak w każdym S3, sekretem nie jest). Do zapisu w magazynie docelowym worker używa kluczy S3 samej organizacji – tych samych, które masz w panelu; dostaje je razem z konfiguracją, na czas jednego zadania, i nie zostają one w opisie migracji.
Adres źródła jest sprawdzany, zanim serwer się z nim połączy. Odrzucamy adresy wskazujące na sieci wewnętrzne i usługi metadanych – to standardowa ochrona przed nadużyciem formularza, który z definicji przyjmuje dowolny URL od użytkownika.
Docelowy magazyn powstaje jako zwykły magazyn, widoczny w panelu i dostępny tak samo jak pozostałe: przez przeglądarkę, klienta desktopowego i przez S3.

Najważniejsze zdanie o rozliczeniu: ta funkcja jest w cenie usługi. Za transfer nie naliczamy nic – ani za wolumen, ani za wybraną prędkość; każda organizacja ma pulę bezpłatnych migracji, a jeśli potrzebujesz kolejnych, wystarczy napisać do nas. Nieudana albo zatrzymana migracja puli nie zużywa, więc próbę można powtórzyć bez kosztu – pamiętaj tylko, że magazyn docelowy z już skopiowanymi plikami zostaje i liczy się do Twojego składowania, więc jeśli go nie chcesz, po prostu go usuń.

Trzeba też uczciwie powiedzieć, czym ta funkcja nie jest. To jednorazowa kopia, a nie replikacja ciągła: kopiuje stan bieżący bucketa źródłowego, nie pilnuje go w nieskończoność i nie przenosi historii wersji ze źródła. Jeśli potrzebujesz kopii utrzymywanej na bieżąco, w Files masz do tego wszystko, czego wymaga metoda 3: w panelu znajdziesz adres endpointu i klucze S3, więc rclone, restic, Veeam, AWS CLI czy własny skrypt zadziałają z Twoim magazynem tak samo jak z każdym innym S3 – w obie strony. To jest zresztą nasza odpowiedź na pytanie o vendor lock-in: tymi samymi narzędziami, którymi dane wchodzą, można je wyprowadzić, bez proszenia nas o eksport.

Warstwy, które w WebDisk Files uzupełniają obraz drugiej kopii:

Trwałość wewnątrz klastra – każdy obiekt jest utrzymywany w trzech kopiach na osobnych hostach naszego klastra Ceph, tego samego, na którym stoi usługa Object Storage. To warstwa z poprzedniej sekcji: broni przed awarią dysku i węzła, nie przed skasowaniem.
Wersjonowanie – zapis pod istniejącą nazwą tworzy nową wersję, a poprzednie zostają dostępne do przywrócenia. To pierwsza realna ochrona przed „ktoś nadpisał plik”.
Anty-Ransomware – magazyn klasy WORM oparty na S3 Object Lock, w którym przez wybrany okres (od 90 dni do 7 lat) żadne żądanie S3 nie usunie ani nie zmieni zapisanej wersji. To jest ta warstwa, której replikacja nigdy nie zastąpi – i odwrotnie: replikacja jest tym, czego Object Lock nie robi.
Szyfrowanie – SSE-S3 na poziomie magazynu albo SSE-C z kluczem po Twojej stronie, do wyboru zależnie od tego, kto ma trzymać klucz.

Zestaw, który w praktyce rekomendujemy klientom z realnym wymogiem ciągłości: dane robocze w Files, kopia zapasowa do osobnego magazynu z Anty-Ransomware (bo tej nikt nie skasuje) i – jeśli scenariusz DR tego wymaga – trzecia kopia u zupełnie innego dostawcy, robiona rclone copy z harmonogramu. Trzy kopie, dwa różne systemy, jedna poza naszą infrastrukturą – czyli reguła 3-2-1, tylko rozpisana na konkrety.

Częste pytania

Czy replikacja zastępuje kopię zapasową? Nie i to jest najważniejsza rzecz do zapamiętania z tego artykułu. Replikacja utrzymuje kopię zgodną ze źródłem, więc powiela też skasowanie, nadpisanie i zaszyfrowanie plików przez ransomware. Kopią zapasową staje się dopiero wtedy, gdy cel ma wersjonowanie i blokadę usuwania – albo gdy replikacja z założenia nigdy niczego nie kasuje.

Czy replikacja spowalnia zapisy do bucketa? W metodach 1–4 nie: kopiowanie jest asynchroniczne i dzieje się po potwierdzeniu zapisu. Odczuwalnie spowalnia tylko podwójny zapis w aplikacji, bo tam użytkownik czeka na oba magazyny naraz.

Jak długo trwa przeniesienie 10 TB? Arytmetyka jest bezlitosna: przy 50 MB/s to około dwóch i pół doby ciągłego transferu, przy najwyższym progu prędkości – kilkanaście godzin. W praktyce wąskim gardłem bywa nie limit pasma, tylko źródło (limity żądań u dostawcy) albo liczba obiektów: milion drobnych plików kopiuje się znacznie dłużej niż jeden plik o tej samej sumarycznej wielkości.

Czy da się replikować dane od innego dostawcy do WebDisk? Tak – to jest dokładnie zadanie funkcji „Replikacja bucketów” w panelu Files. Wystarczy endpoint oraz klucz dostępu i tajny, którymi widać listę bucketów źródłowych; resztę robimy po naszej stronie, a Ty patrzysz na pasek postępu. Kierunek odwrotny też jest otwarty: klucze S3 do swojego magazynu masz w panelu.

Czy replikacja przenosi historię wersji plików? Natywna replikacja w S3 i multisite – tak, bo operują na wersjach. Narzędzia takie jak rclone czy aws s3 sync – nie: kopiują bieżący stan obiektów. Jeśli historia ma przetrwać migrację, trzeba to zaplanować osobno; częściej rozwiązuje się to tak, że historię trzyma backup, a nie replika.

Co z plikami zaszyfrowanymi – czy w ogóle się skopiują? Zależy od tego, kto ma klucz, i od platformy. Przy szyfrowaniu po stronie serwera (SSE-S3, SSE-KMS) samo kopiowanie jest przezroczyste – z dwoma zastrzeżeniami: w natywnej replikacji AWS obiekty SSE-KMS trzeba jawnie dopuścić w regule i wskazać klucz w regionie docelowym (patrz pułapka 4), a w Ceph RGW kopiowanie po stronie serwera obiektów szyfrowanych po prostu nie jest zaimplementowane. Przy szyfrowaniu kluczem klienta (SSE-C) każda kopia musi przejść przez proces, który zna klucz – dlatego takie obiekty kopiuje się narzędziem z kluczem, a nie poleceniem „skopiuj po stronie serwera”.

Jak sprawdzić, że kopia jest kompletna? Porównaniem, nie zaufaniem. Minimum to zgodność liczby obiektów i sumarycznego rozmiaru po obu stronach; wersja poważna to rclone check --checksum (porównanie sum kontrolnych) albo, przy natywnej replikacji, sprawdzenie statusu replikacji obiektów i metryk opóźnienia. Migracja bez takiego odbioru nie jest skończona.

Ile kosztuje utrzymywanie drugiej kopii? Trzy pozycje, nie jedna: składowanie po drugiej stronie, opłaty za żądania i ruch wychodzący ze źródła – ten ostatni płacisz przy każdym cyklu, a nie raz. Przy replikacji ciągłej licz go od wolumenu zmian, przy migracji – od całości danych. Kopia u tego samego dostawcy bywa w transferze darmowa, kopia „na zewnątrz” nigdy.

Od czego zacząć, jeśli dziś nie mamy żadnej drugiej kopii? Od najtańszego kroku, który daje najwięcej: włącz wersjonowanie tam, gdzie leżą dane robocze, a kopie zapasowe kieruj do osobnego magazynu z blokadą usuwania. Dopiero potem dokładaj replikację – i wybierz ją do problemu, który realnie masz (migracja, DR, bliskość geograficzna), a nie do hasła.

Czy kopia w drugim centrum danych jest w cenie? Rozdzielmy dwie rzeczy. W cenie jest trwałość wewnątrz klastra (trzy kopie każdego obiektu na osobnych hostach) i w cenie jest migracja danych do WebDisk. Kopia poza naszą infrastrukturą to osobny scenariusz DR – możesz ją zrobić sam, kluczami S3 z panelu i dowolnym narzędziem, albo odezwać się do nas i zaprojektować to razem. Wolimy powiedzieć to wprost, niż sprzedawać słowo „replikacja” jako obietnicę, która u każdego dostawcy znaczy co innego.

Podsumowanie

Replikacja bucketów S3 to nie jedna technologia, tylko pięć rodzin rozwiązań o różnym koszcie wejścia i różnym przeznaczeniu: reguła w samym magazynie, replikacja klastra, kopiowanie narzędziami, worker zdarzeniowy i podwójny zapis w aplikacji. Wybór między nimi rozstrzygają cztery pytania – o dopuszczalną utratę danych, o to, czy oba końce są u tego samego dostawcy, o historię wersji i o to, kto płaci za transfer.

Trzy rzeczy warto zapamiętać:

replika jest wierna, a wierność bywa wadą – kasowanie i szyfrowanie propagują się razem z danymi, więc drugą kopię trzeba utwardzić wersjonowaniem i blokadą zapisu, jeśli ma przetrwać zły dzień,
migracja kończy się na weryfikacji, nie na komunikacie „gotowe” – sumy kontrolne, liczba obiektów, rozmiar; a przy okazji odtworzenie polityk, reguł lifecycle i CORS, które nie jadą razem z obiektami,
replikację wybiera się do problemu, a nie do hasła – to samo słowo oznacza zupełnie co innego przy migracji, przy DR i przy ochronie przed ransomware.

W WebDisk Files migrację z dowolnego magazynu zgodnego z S3 masz gotową w panelu – Replikacja bucketów, z podglądem postępu, możliwością zatrzymania i bez dodatkowej opłaty. Przetestuj WebDisk Files albo napisz do nas, jeśli chcesz przegadać architekturę drugiej kopii dla swoich danych: doradzimy również wtedy, gdy najlepszym rozwiązaniem okaże się kopia poza naszą infrastrukturą.

Artykuł jest częścią cyklu o bezpieczeństwie danych w usługach WebDisk – wcześniej pisaliśmy o podstawach object storage, szyfrowaniu w spoczynku (SSE-S3, SSE-KMS, SSE-C), dostępie przez STS/SSO i o niezmienialnych kopiach z Object Lock. Przykłady wykonasz na dowolnej platformie zgodnej z S3; parametr --endpoint-url w aws CLI wskazuje endpoint Twojego dostawcy.

Replikacja bucketów S3: pięć sposobów na drugą kopię danych – i to, czego żaden z nich nie załatwi