A PBS 4 egyik új funkciója (még tech preview!) az S3 kompatibilis tárolók natív támogatása. Én BackBlaze-t használom már másfajta mentésre, ezért azzal próbáltam ki.
A beállítás igen egyszerűnek tűnt, de elsőre mégsem jött össze. Másodikra viszont igen némi olvasgatás után. Más is belefuthat, mert nem minden S3 elérést adó szolgáltató, vagy onprem szerver kompatibilis 100%-ban az S3 specifikációval.
A beállítás:
Először a „Configuartion → S3 Endpoints → Add” helyen kell a következőket beállítani:
Endpoint name: ez mindegy mi
Endpoint: s3.us-west-002.backblazeb2.com (vagy az a régió ahol a bucket van)
Port: (nem kell)
Path Style: [x] (a B2 csak ezzel a beállítással megy)
Region: us-west-002 (nem értem ez minek kell, mert az endpoint is tartalmazza, de kell)
Access Key: (B2 keyID)
Secret Key: (B2 applicationKey)
Fingerpint: (nem kell)
És a trükk → Advanced beállítások
Provider Quirks: Skip If-None-Match header
Ha ez nincs beállítva nem fog működni. Ez az oka a Proxmox support oldalról:
The Backblaze B2 implementation of the S3 api seems to not support the If-None-Match http header, therefore the requests failing with above error.
Már jelezték a BackBlaze-nek.
Ezután kell létrehozni egy új Datastore-t
Name: bármi, de fontos lesz később
Datastore Type: S3
Local cache: /valami/mappa (részletezem később mi ez)
S3 Endpoint ID: amit létrehoztál ezelőtt
GC Schelude: amit akarsz
Prune Schedule: amit akarsz
Device: nem kell
Bucket: kiolvassa az ID-alapján, legördülő menüben kell kiválasztani
És kész is, lehet használni.
Local cache! Meg kell adni egy helyi mappát, mert a mentés oda készül és azt szinkronizálja az S3 helyre, hogy csökkentse a költségeket, minden onnan megy ami lehet. Tehát a mentésnek kell hely! Ez gyakorlatilag két mentés, a sebességét a helyi BPS adja. Egy resore nem is használja az S3-at.
Nekem jó lenne olyan opció is, ahol ez nincs, csak S3, de egyelőre ilyet nem találtam.
Így gyakorlatilag ezzel egyszerre van helyi és offsite mentés is. A felülten egyelőre nincs állapot indikátor, hogy az S3 szinkron hogy áll, gondolom előbb utóbb lesz valami erre.
Ha beüt a disaster, akkor fogsz egy másik PBS-t és végigcsinálod az fentiket, csak a datastore hozzáadásnál az Advanced alatt beállítod ezt:
Reuse existing database.
Ekkor ha talál olyan nevű mappát amit ez előző Datastore-nál beállítottál használni fogja. Fontos, hogy akkor olvassa fel, ha név egyezik a előzővel, mert ez a mentés mappájának a neve.
Kipróbáltam és gond nélkül ment.
Ez egy egész hasznos újítás, amit ha a Remotes pull replikációval használsz egészen komoly biztonság érhető el. Nálam ez lesz a működés (már ahol kifizeti az ügyfél):
Proxmox VM → PBS backup ← External PBS pull replication → S3 (B2)
Ezzel egy kibertámadás is igen jó eséllyel túlélhető, mivel ha esetleg hozzáférnek a helyi BPS-hez azon nem látszik a pull, és ha valahogy mégis hozzáférnek, ott a B2 mentés. Ez összesen 3 példány a mentésből.
Persze kivétel, ha rendszergazda gépét törik fel és hozzáférnek minden beállításhoz. Sajnos láttam már ilyet.
Szóval vagy legyen két géped és ez egyiken csak a cloud dolgokat állítgatod, a másikon meg csak a cég belső dolgait, vagy ha több rendszergazda van csinálják külön.
Ez csak addig paranoia amíg nem üt be szar.
- 633 megtekintés
Hozzászólások
- A hozzászóláshoz be kell jelentkezni
Nem pontosan értem a kérdést.
Ha az obejct-lock-ra vonatkozik, akkor az azt csinálja, hogy egy objektum (fájl) a létrehozás után nem módosítható és törölhető a megadott ideig, még az admin-nak sem. Ez a bucket nem módosítható tulajdonsága, csak a létrehozáskor beállítható, a bucketet még törölni sem lehet, admin joggal sem, amíg a retention time tart. Ez nyilván csak olyan alkalmazásnak jó ami ettől nem nem áll fejre. A mentés tipikusan ilyen, ha beállítasz pl 15 nap legrövidebb megőrzést és a bucket-en meg 14-et akkor nem lesz gond és ha kompromittálódik esetleg az admin gépe, akkor sem lehet kárt okozni.
Gondolom ezt összehozták valami Veeam api-ra és maga Veeam is tudja állítani, de az csak tipp, nem használok Veeam-et.
The solution, which earned a Veeam Ready-Object with Immutability qualification, means a good, clean backup is just clicks away when reliable recovery is needed.
It is the only public cloud storage alternative to Amazon S3 to earn Veeam’s qualifications for both compatibility and immutability. And it offers this at a fraction of the cost.
A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.
- A hozzászóláshoz be kell jelentkezni
ha beállítasz pl 15 nap legrövidebb megőrzést és a bucket-en meg 14-et akkor nem lesz gond és ha kompromittálódik esetleg az admin gépe, akkor sem lehet kárt okozni.
Erre gondoltam.
Nem ismerem/használom a BackBlaze-t, de biztosan nem Veeam specifikus a funkció: ha Veeammel megy, mással is megoldható és akkor kevésbé para, hogy kikerül az admin fiók stb.
- A hozzászóláshoz be kell jelentkezni
A BackBlaze kizárólag tárhelyet ad ami vagy saját protokoll (egy csomó mentés ismeri) vagy S3 kompatibilis. Legalább is majdnem kompatibilis, mint most kiderült :) de a Proxmox-ék nagyon gyorsan reagáltak.
Ha használsz S3-at hasonlítsd össze az árakat: https://www.backblaze.com/cloud-storage/pricing
Ez van, meg a computer backup, ami 9$ / hó és korlátlan minden, a tárhely és az adatforgalom is.
A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.
- A hozzászóláshoz be kell jelentkezni
Ilyen szinten ismerem, köszi.
- A hozzászóláshoz be kell jelentkezni
A Wasabi a BackBlaze konkurenciája. Közel ugyan az:
Wasabi: 6.99$ TB/month + minimális tárhely idő 90 nap (ha előbb törölsz, akkor is 90 nap díját számlázzák)
BabcBlaze: 6$ TB/month + $0.01 / GB letöltés, havi átlagos tárolt adat × 3 felett, addig ingyen (na ezzel elég varázslatos számolni...)
Én pofára (kezelő felület) választottam :) de néha ránézek a Wasabi-ra. Offsite backupnak sokkal olcsóbbak mint a nagyok.
A B2 admin felülete faék egyszerű.
A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.
- A hozzászóláshoz be kell jelentkezni
Bocs ezt lemaradt, az obejct lock természetesen nem Veeam specifikus. Az annyiban tud többet, hogy maga állítgatja a retention policy szerint.
A PBS ezt nem tudja, ott csak kézzel bucket szinten tudod állítani. Mivel ez objektum tulajdonság, gyakorlatilag minden fájlnak lehet object lock időt megadni, de ezt nem tudod kihasználni.
Ha például a legrövidebb megőrzési időd a mentésnél 7 nap, akkor erre állítod az obejct lock-ot a bucket-en és így működő képes a PBS, de nem tud az object lock-ról. A régebbiek mentések törölhetőek, mert mindenre 7 nap van. Ez így a gyakorlatban működő képes.
A Veeam ezt maga kezeli és minden mentésnek beállítja a saját megőrzési ideje alapján az object lock-ot. Ha 7 nap akkor annyit, ha 30 akkor meg annyit. Ez profibb megoldás.
A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.
- A hozzászóláshoz be kell jelentkezni
Annyival egészíteném ki, hogy a backup programból állítható object lock csak kényelmi funkció, de a teljes funkcionalitás elérhető e nélkül is egyszerűen.
Backblaze esetében minden bucket-re (amire engedélyezve van az object lock) lehet default retention-t állítani, így minden feltöltött állomány a feltöltéstől számítva annyi ideig zárolva lesz, nem kell kézzel utána semmit állítani a mentések után. A PBS nem módosítja a chunk állományokat (hiszen a nevük maga a checksum értékük, így a módosított tartalom már egy új állomány lesz), emiatt a retention kizárólag a garbage collect futtatásra van hatással (nem tudja törölni azokat a chunk-okat, amik meg vannak jelölve törölhetőnek a prune által, de még nem telt le a retention).
Szóval a bucket-en default retention-nek be kell állítani a kívánt prune értéket, és teljesen jól kell működjön a PBS anélkül, hogy erről tudna. Ha különböző mentésekhez különböző prune tartozik, akkor annyi külön bucket-et kell csinálni más-más default retention-nel.
- A hozzászóláshoz be kell jelentkezni
Jelen funkcióba szvsz ez nem több, mint ahogy eddig megcsinalta az ember, csak magának, hogy a helyi pbs datastore-t felsynceli random helyre. De saját script esetén legalább tudom, hogy hol tart a dolog ugye.
Szvsz ez a funkció amúgy jó, csak nem úgy kellett volna berakniuk, mintha egy rendes datastore lenne, hanem a sync featureok közé.
- A hozzászóláshoz be kell jelentkezni
A tuti az lenne, ha ki tudnám választani mit akarok. Most teljesen jó, egy backup+offsite megoldásnak, de van pár ok, amikor meg a csakS3 jobb lenne.
A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.
- A hozzászóláshoz be kell jelentkezni
Egy felvetésre reagálnék csak a cikkben.
Azért kell a régiót külön megadni, mert nem minden provider URL tartalmaz múlhatatlanul régiót is. Mi Ceph/RadosGW alapű S3 storage-t használunk teljesen más szituációban, de ott is meg kell adni a régiót, mert az URL-ünk ügy néz ki, hogy %(bucket).s3.company.com. amiben nem lehet bekarikázni a régió azonosítót, viszont az S3 API bizonyos szituációkban ezt mindenképpen igényli (nem biztos, hogy a megvalósítás validálja/használja is, de API referencia szerint kötelező paraméter). Nálunk ezt fixen us-east -re kellett állítani, hogy minden faján működjön, pedig hát a nevezett számítógépek sosem hagyták el kies hazánk határait.
Azaz szolgáltató/megvalósítás-függő is lehet, és nem is biztos, hogy egybeesik a szolgáltató régió azonosítóival (esetedben egybeesett). Ezért külön paraméter ez.
- A hozzászóláshoz be kell jelentkezni
Köszi.
Én B2 felől "jövök" még van nem S3 kompatibilis bucket-em is. Nem vagyok S3 guru, Így már világosabb :) Gondolom a Path Style is azért kell, mer a B2 nem szakadt bele, hogy 100% legyen a kompatibilitás.
A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.
- A hozzászóláshoz be kell jelentkezni