Hogyan másoljak backblaze b2-ből (S3) S3-ba?

Fórumok

A cím leírja a lényeget. Van 3 T adatom (restic mentések) B2-ben, és ezt át akarom másolni saját S3 storage-ba.

Ki mit használ?

Ebbe épp belefutottam, errefelé indulnék: https://www.backblaze.com/blog/big-performance-improvements-in-rclone-1…

De ha nem muszáj, nem találnám fel megint a kereket.

Hozzászólások

Szerintem ne keress tovább, ez a cucc való erre. Ekkora mennyiségnél még nem tudom hogy érdemes-e (de már lehet...) optimalizálni hogy naponta mennyit viszel át, hogy olcsóbb legyen.

 

Gábriel Ákos

Ha aktívan működő mentés (nem archívum), akkor mi lenne, ha csak simán elkezdenél a saját S3-ba menteni, és mikor már minden elérhető a megfelelő intervallumra az új helyen, akkor megszűntetnéd a BB tartalmat/fiókot. Persze addig fizetni kell a BB tárhelyet, de 3T csak 18 USD havonta, nem olyan őrületes költség, és megspórolod a napogik tartó folyamatos másolást, meg az új hely esetleges túlterhelését a BB másolás+rá menő új mentések idején.

ő nem a pornógyűjteményre asszociált, hanem olyan backupra, ami x időre visszamenőleg tárolja rendszeresen a változtatásokat és így idővel elavulttá válik a régi tartalom / kipörög a rotatationnal egyébként is a régi. Utóbbinál idővel elavulttá válik a régi tárhyen az adat és simán törölhető, ha az új már tartalmazza a későbbi x időre visszamenőleg, ami kell.

Hát, azt csak Te tudod, hogy a menési forrásból tudsz gyorsabban írni a saját S3-ra, vagy a mentési forrás vagy az S3 felé a kapcsolat olyan lassú, hogy annál még a B2 letöltés is gyorsabb.

Ugyanis B2 elé hiába teszel egy 2 Gbps internetet a saját S3-hoz, B2-ből nem fog 2 Gbps-sel letöltődni a cuccod. Ahogy jellemzően a feltöltési sávszélességet sem sikerült még soha kihajtanom Magyarországról B2 felé.

Persze ha B2-ből Amazon S3-ba töltesz át, az lehet, hogy gyors, nem tudom milyen kapcsolatuk van, de biztos nagy sebességű, akár közveten is lehet. De saját S3-at írtál, azért gondolom, hogy valami "kommersz" kapcsolaton keresztül tudod a B2-ből tölteni.

"Hát, azt csak Te tudod, hogy a menési forrásból tudsz gyorsabban írni a saját S3-ra"

Így van. Nem világos mi számít kommersznek, nálam több hétig ment a feltöltés, sebességlimittel, hogy azért tudjak dolgozni + néha éjszakára, vagy amikor nem itthon voltam, hagytam, hogy koppra hajtsa a vonalat.

A korábbi hozzászólásokból kiderül, hogy Backblaze -> Crunchbits

Még egyszer, nem ok nélkül nem akarom feltölteni megint, nem ok nélkül kérdeztem az S3 -> S3 másolást.

Valahogy elkerülte a figyelmem, mi lesz a célhely, elnézést. Csak a "saját" maradt meg, ezért gondoltam valamiért, hogy on-prem saját.

Kommersz alatt itt a nem-dedikált, lakossági és üzleti asszimetrikus internet előfizetéseket értettem.
A saját Digi előfizetésemmel számolva (1000/300 Mbit, a 300 felfelé mindig megvan), 50% terheléssel számolva (150 Mbps) a 3 TB szűk két nap alatt menne fel. De sajnos nem ez a valóság. Itthonról egy kis NAS-ról, hetente egyszer megy a B2-be néhány qemu mentés, 23 GB terjedelemben, és ez 3 órát szokott igénybe venni. Ergo ~ 15 Mbps sebességgel tudok feltölteni... Tehát lassú a B2 itthonról, független a rendelkezésre álló sávszélességtől.

Megnéztem a VPS ajánlatokat, valóban extra olcsó. Igazából nem is értem, hogyan és miért éri meg ennyire nyomott áron kínálni.

Mondjuk én nem látok akkora üzletet abban, hogy havi 12 USD-ért magamnak telepítsek és üzemeltessek egy S3 tárolót a havi 24 USD-s menedzselt B2-höz képest (a 12 USD-s 4 TB-os VPS teljes kapacitásával számolva, 3 TB-nál csak 6 USD a nyereség).

Minden esetre ha megvalósul a projekt, érdekelnének a számok, milyen tempóval sikerült az áttöltés.

Egyelőre (rclone 1.60, nem is 1.64):

Transferred:        6.904 GiB / 2.443 TiB, 0%, 53.756 MiB/s, ETA 13h12m3s
Transferred:         1541 / 152307, 1%
Elapsed time:      4m40.4s
Transferring:
 * data/03/03afd23ba2f9c1…a1482f162ce6ea7b14beee:100% /16.563Mi, 0/s, -
 * data/03/03b08b3979556b…b4314e970eee9c24f37cc0: 73% /17.574Mi, 0/s, -
 * data/03/03b0e1ffbed163…6b35dc86d40d568b37f4b2: 22% /17.692Mi, 0/s, -
 * data/03/03b1330a23308c…ce31859e8077be091b6838: transferring

Ha sűrűn kéne ezt futtatni, akkor ügyeskednék a párhuzamosítással, bőven van pici fájl is a nagyok mellett (tipikusan raw + xmp).

Mondjuk úgy, hogy két menetben syncelni, a kicsiket így, a nagyokat úgy. De... kb. egyszer kell lefuttatni, szóval ígyjárás, lesz ami lesz.

 

Kicsit mondjuk aggaszt, hogy a limiteknél még mindig 100G van feltüntetve, elvileg annak bő 7T-nak kéne lennie.

El is kaszáltam, mert jött az értesítés, hogy mindjárt karcolom a napi limitet.

 

Update:

Friss rclone, nem láttam észrevehető változást. Felemeltem nyolcra a párhuzamos letöltések maximumát, és:

rclone v1.64.0
- os/version: debian 12.1 (64 bit)
- os/kernel: 6.1.0-12-amd64 (x86_64)
- os/type: linux
- os/arch: amd64
- go/version: go1.21.1
- go/linking: static
- go/tags: none


Transferred:       18.373 GiB / 2.306 TiB, 1%, 81.364 MiB/s, ETA 8h11m22s
Checks:              9634 / 9634, 100%
Transferred:         1109 / 142673, 1%
Elapsed time:       4m3.4s
Transferring:
 * data/18/18cd66907d14e1…9612e77f40d005e4cf5903: 17% /17.550Mi, 0/s, -
 * data/18/18cdb16e7ed296…658988c5d2802e75c4e101: 94% /18.072Mi, 0/s, -
 * data/18/18ced34367b428…a8641ca592f90daf42dee1: 27% /17.993Mi, 0/s, -
 * data/18/18cf837eaf46dd…a20bbdea814669bfe4c254:  1% /17.481Mi, 0/s, -
 * data/18/18cfe602d102b2…37d6952a7a5aadd990a9d2:  2% /17.719Mi, 0/s, -
 * data/18/18d0147e35cbe0…868ad2459f00477e8c664f: transferring
 * data/18/18d0568b144fac…c9f801008f509a0103cf86: transferring
 * data/18/18d0c71793f6f8…9887c24cb5fe0d782ae017: transferring^C


~# vmstat 20
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 5  0  32716 142144 188940 2981708    0    0     1   167  108  126  1  0 99  0  0
10  1  32716 142144 188940 2981708    0    1    25 84153 18884 22108 32 27 27 14  0
 3  0  32716 142144 188940 2981708    0    0   246 89610 19828 24296 34 28 24 14  0
 7  0  32716 142144 188940 2981708    0    0    27 80272 17914 20890 32 26 28 13  0
 6  0  32716 142144 188940 2981708    0    0    13 78357 18655 20778 32 26 29 14  0
 8  0  32716 142144 188940 2981708    0    0    34 92072 19285 23589 35 27 24 13  0
 4  0  32716 142144 188940 2981708    0    1    12 92775 19923 25604 33 28 27 12  0
 3  0  32716 142144 188940 2981708    1    1     2 84014 17924 20767 33 27 26 14  0
 7  0  32716 142144 188940 2981708    0    1    63 90302 20342 26005 34 26 27 12  0

De visszaveszem négyre, nem hajt a tatár.

A support mintha nagyon nem akarná érteni a problémámat, hogy mennyit is kell majd fizetnem, ha letöltöm az egészet. Na mindegy, max. 30 dodó lesz, a - gondolom - legrosszabb esetben is.

 

A végeredmény:

Transferred:        2.270 TiB / 2.270 TiB, 100%, 24.462 MiB/s, ETA 0s
Checks:             11861 / 11861, 100%
Transferred:       140446 / 140446, 100%
Elapsed time:  20h22m19.0s/

 

Jól jött a topic, rájöttem, hogy nekem a backup backupjának a Backblaze-hez képest a Glacier Deep Archive jobb választás!

Ez a gyors "kiolvasztás" ahogy látom. Viszont ha nem ugyanabba az s3 régióba, hanem másikba vagy lokális rendszerre kell visszatölteni, akkor még ott az adatforgalom is.

Persze ez lehet bőven olcsó, ha az adat fontos. Meg a mennyiség sem mindegy.
Ahol komolyabban vett disaster recovery plan van, ott gondolom kiszámolják és időnként frissítik is ezeket az infókat és költségeket.

A backup backupjánál szerintem sokan elfelejtik, hogy amikor ahhoz kell nyúlni, akkor pont minden elveszett mindenhonnan. És ez egy elég stresszes helyzet anélkül is, hogy várni kellene a Glacier-re akár 48 órát, hogy elérhetővé váljon a backup backupja...

Valamint pont ugyan így nem gondolják sokan azt, hogy a backup backupja mennyire megbízható kell legyen, mert ugye az már a sokadik példány, jó az egy sima HDD-n a fiókban. Közben meg az utolsó mentsvár lehet, és ha pont megmakkant akkor van a baj.

Ráadásul Glacier-be nem lehet simán betenni semmit. A sokkal drágább hot tárolóra lehet betenni, és onnan átmozgetni Glacier-be (majd a hot tárolót kiüríteni). Kivenni ugyan így lehet, Glacier-ből hot-ba, és onnan tölthető le. A hot tároló minden esetben fizetendő az átmeneti időre, nem a Glacier szolgáltatás tartozéka.

Én jó megoldásnak tartom a B2-t backup backupja alá, mert mindig elérhető, nem kell várni rá. Valamint a legutóbbi díjszabás változásnál gyakorlatilag ingyenessé vált a backup jellegű letöltés (a tárolt adat háromszorosának megfelelő letöltésig nem kell fizetni). Ergo ha már nagy a baj, legalább nem kerül pénzbe az utolsó példány visszaszerzése. Ha valaki rászánja a dupla pénzt, akkor georedundánsan is tárolhatja B2-ben a backup backupját, így az ottani hibák ellen is véd, meg egy esetlegesen elérhetetlenné váló datacenter esemény ellen is véd.

S3-ba állítunk vissza Glacierből, általában S3 batch job.
Glacier-nél van gyors visszaállítás (expedited: 5 perc).
Glacier Deep Archive-nál nincs gyors visszaállítás, itt a max várakozási idő 24-48 óra.

Táblázat itt elérhető:
https://docs.aws.amazon.com/amazonglacier/latest/dev/downloading-an-arc…

Nem mondanám, hogy olyan könnyű megtervezni és kiszámolni egy ilyen multi-tier Amazon tárolást ahol a leírást véggi futottam...

Annyit látok, hogy az Expedited 5 perces visszaállítás az 250 MB-nál kisebb archívumok esetén használható, ennél nagyobb adatmennyiségnél a Standard (ami max 5 óra) idővel lehet számolni. És ez nem a Deep Archive, az 9-12 óra a leggyorsabb üzemmódban.

Ezen felül elő kell legyen fizetve az S3 tároló, amire a Glacier-ből érkezik az adat, szóval ennek a költségét is számolni kell kapásból.

Jelen feladatnál szerintem nem lenne érdemben kevesebb a költség a mostani havi 18 USD-nél, legalábbis annyira nem, hogy megérje ezzel foglalkozni ilyen kicsitben (pontosabban nekem nem érné meg vele szenvedni).