Gyors backup: hol, hogyan?

Fórumok

Jelenleg a restic programmal a Backblaze-en tárolok kb. 1TB backupot. Működik ugyan, de sok kis fájl esetén elég lassú, ezért szeretnék egy gyorsabb megoldást.

Úgy látom, az 1TB még kevesebb annál, hogy megérje rá külön backup szervert üzemeltetni.

Elsőre a sávszélesség miatt hazai backup szervereket kerestem. Ezekből egyedül az SFTP-n keresztül elérhetőek tűnnek használhatónak, mert ezt a protokollt támogatja a restic. SFTP-vel azonban nem tudom megállapítani, hogy mennyi szabad helyem van még. Nem ragaszkodom a restic-hez, de mindenképp valamilyen olyan megoldást keresek, ami tud titkosítva tárolni, növekményes, felcsatolható, és persze gyors, hisz ez az elsődleges célom.

Akik ilyen távoli, idegen backup tárhelyet használtok, hol tároljátok és milyen programmal éritek el?

Hozzászólások

Szerkesztve: 2020. 03. 06., p - 11:10

A felcsatolható alatt azt érted, hogy a mentés közvetlenül olvasható legyen és ne kelljen kliens a visszaállításhoz?

Én duplicity-t és duplicati-t is használok B2-vel és nincs gondom vele, de ez a csatolós dolognak nem felel meg.

Ez elég jól megmondja mire számíthatsz: https://www.backblaze.com/speedtest/

Egy, Egyből Kettő, Kettő meg Egy. Ez minden mérték alapja, minden élet csirája, számok, nevek építőköve.

Titkosított, növekményes, felcsatolható és gyors, mivel az első hármat a restic is tudja.

De lehet, hogy a sebességhez elég egy közeli backup szerver, gyors kapcsolattal.

A kérdés talán inkább a backup szerverre/protokollra vonatkozik, mint a szoftverre, bár ez utóbbiban is kompromisszumkész vagyok.

A kérdésből és a hsz-ekből nekem az jön le, hogy van az eredeti példányod helyben, és a távoli backup felhőben. Közte meg semmi. Ez így alapjában nem a legjobb (finoman szólva). Mert mi van, ha elveszik az eredeti, és a felhős meg épp elérhetetlen/megszűnik/elveszik/stb.? Ezer oka lehet, hogy a felhős példány nem elerhető, vagy nem olyan gyorsan, ahogy épp szükséges lenne.

Én mindenképp tennék egy köztes, helyi mentést, és ha valami kell, akkor abból állítanám mindig vissza. A 3-2-1 mentési elv gyors, olcsó, könnyen kezelhető. A távoli (cloud vagy offsite, esetleg szalagos) mentést csak akkor veszem elő, ha az eredeti és a helyi backupő egyaránt megsemmisül (betörés, tűzeset, stb.).

Backup szerver meg nem feltétlen kell, akár egy olcsó, használt NAS is megfelel a célra (a semminél mindenképp jobb a is). Egy régebbi Synology, kétlemezes (tükörben) például. És az ráadásul tud B2 szinkronizálást is, szóval csak a NAS-ra kell menteni, helyben, gyorsan (ha nagyon eszerű felállást szeretnél), és a többi megy magától. Sőt, a Synology saját backup megoldását is használhatod akár.

Szerintem elég bátor dolog abban bízni, hogy az egyetlen mentésem egy távoli, felhős szolgáltató gépén biztosan mindig elérhető lesz...

Én magam (még itthon is) Bacula-t használok, az ment helyi NAS-ra minden gépről (és szerverről, VM-ről, stb.) mindent ami kell. Akár állomány szinten visszaállítható, gyorsan. A NAS-ról (valójában kettő különbözőről) pedig megy B2-be másolat. Az átlagos megőrzési időm 3 hónap, csökkenő felbontással az idő növekedésének arányában.

Semmilyen... Nagyon hosszú story volt, a lényeg, hogy a protocol 2 felejtős, még erősen béta, az 1-essel meg semmi baj nincs, a UPC-s gerinc szar, ami random eldob csomagokat vagy RESET-el kapcsolatot.

Nagyon remélem, hogy a vodafone a felvásárlás után gatyába rázza a UPC minden szarját.

"Sose a gép a hülye."

Burp elég frankó. Első restore-nál voltam bajban, hogy milyen kulcsot hova másoljak a frissen telepített munkaállomásra, de valahogy megoldódott. Azóta inkább lementem a telepítés után készült kulcsokat.

 

Viszont a gui-ról nem tudtam, ezt elkönyvjelzőzöm magamnak, hogy aztán soha többet ne találjak ide vissza.

burp-ui nagyon jó ha vissza kell valamit szedni, akár egy fájlt is.
CLI-vel semmi gond, de azért n-edik könyvárból, X, majd másik könyvtárból Y fájlt visszaállítani időigényes.
UI-nak saját kulcsa van, egy login után pikk-pakk lehet bármilyen fájlt visszaállítani.

Burp  másik előnye számunkra hogy felügyelhető, egy sima script-el Nagios-ba beköthető, így Nagios tud szólni ha valamelyik kliensről nincsen backup!

Ráadásul kliens oldalon kb. mintha ott sem lenne! mennyi a telepítője 20-30Mb? Igazából egy időzített feladat WIN alatt, tehát óránként egyszer fut kb. 5 sec-ig ha nem ment.

A növekményessel az a baj, hogy egyre távolabb kerülve a full backup-tól már nagyon nyűgös a visszaállítás, így időnként kell full backup is. Akkor legyen már „csökevényes” :), azaz dekrementális, ha úgy tetszik, azaz amit az rdiff-backup csinál.

Úgy működik, hogy rsync-kel csak diff-et backup-ol, de ami változott, azaz amit az rsync felülír, annak a régi példányát összetömörítve elteszi felülírás előtt. Ezzel azt éri el, hogy mindig a full backup a legfrissebb, az a teljes, a dekrementális patch-ekhez pedig csak akkor kell nyúlni, ha korábbi változatra van szükség. Ráadásul a régi visszamenőleges, dekrementális patch-ek büntetlenül törölhetők, egy idő után egyre kisebb relevanciával bírnak. A működésből fakadóan sohasem kell full backup-ot csinálni, mert az mindig rendelkezésre áll, s az épp a legfrissebb mentés.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

a borg backupot ajánlom

dedup, növekményes, titkosított, felcsatolható

sajnos backbaze-re nem tudom mennyire megy fel

Bareost hasznalok S3-ba mentek.

3 havonta full, havonta differential, naponta incremental 30 napos megorzessel. 
 

Backblaze nekem dragabbra jott volna ki, mert a full es a diff mentesek Glacier Deep Archiveba mennek, az incrementalok pedig Infrequently Accessed tierbe. Igy azert joval masabb a kep mint ahogy Backblaze a price-comparisonben allitja, mert naluk nincs tiering.

Visszaallitani nagyon ritkan kell, akkor is csak nehany fajlt a sok TB-bol. Ha minden elveszik akkor meg nem erdekes mennyibe kerul mindent letolteni, az adat sokkal tobbet er annal.