Ilyen az, amikor informatikusok biztonsági mentést csinálnak maguknak (x)

Hirdetés

Amikor igazán fontosak a megőrzendő adatok, és nem csak egy audit követelményrendszernek akarunk megfelelni; hanem valóban nyugodtan akarunk aludni, akkor oda egy elit biztonsági mentés kell. 

( kruska v | 2024. 10. 14., h – 07:35 )

Itt is szívesen válaszolok az esetleges kérdésekre.

( gabrielakos v | 2024. 10. 14., h – 08:33 )

Mi s szoftver neve ami a státuszoldalt adja?

Gábriel Ákos

( denton | 2024. 10. 15., k – 09:29 )

Szerkesztve: 2024. 10. 15., k – 09:30

Eléggé durva, hogy pár erőforrás miatt órákig tölt az oldal, pl ezt az istenért nem akarja rendesen betölteni:

https://elit.hu/images/ELIT.backup.workflow.png

https://elit.hu/cdn-cgi/scripts/5c5dd728/cloudflare-static/email-decode…

https://elit.hu/cdn-cgi/speculation

 

Ha akarnék is ilyen megoldást, pár perc szenvedés után bezárom az oldalt és megyek tovább.

OP nyíilván nem fogja erre beírni, hogy #worksforme, mert nem lenne szép és hiteles.

Én kipróbáltam vagy különböző 10 helyről, különböző internet kapcsolatokon, különböző szolgáltató, különböző tűzfal, különböző végpontvédelem, különböző hálózat, de sehonnan sem tapasztalatam torpanást.

 

Szerintem szuper ez a statikus oldal megoldás, nem láttam ilyent az utóbbi években weblapnak mert a Wordpress, Joomla, Drupal ural mindent, mert "egyszerű".

Szerintem szuper ez a statikus oldal megoldás, nem láttam ilyent az utóbbi években weblapnak mert a Wordpress, Joomla, Drupal ural mindent, mert "egyszerű".

Sot, az meg inkabb dicseretes, hogy a kezdooldalon nem a langyos levegot es eleterzest akarjak nekem eladni, hanem leirjak par pontban, hogy mit tudnak. Igy 3 masodperc alatt eldonthetem, hogy erdekel-e.

Legjobb, amikor allashirdetes visz valami obskurus helyre. 2 ora mire kibogaraszom, hogy ok most valami rendes ceg vagy egy nagyon-nagyon novekedo katicabogarmento egyesulet.

"hogy a kezdooldalon nem a langyos levegot es eleterzest akarjak nekem eladni, hanem leirjak par pontban, hogy mit tudnak."

This, hogy én mennyire rühellem, mikor a minden fosom le van írva, hogy ilyen izé, meg olyan anyám, te meg nézel, hogy jó jó, értem én, hogy nekem majd jó lesz, mert megoldja a nem tudom mit, de legalább nagyjából lehetne, hogy hogyan?

( kruska v | 2024. 10. 18., p – 17:45 )

Készítettünk egy kis dokumentációt a nyilvános oldalra is, főleg a restic használatáról, lehetőségeiről. 

Akár még a szolgáltatástól függetlenül is érdekes lehet, bár inkább csak gondolatébresztő, nem kimerítő leírás.

https://elit.hu/help/backup

( ggallo | 2024. 10. 20., v – 10:37 )

Nekem lenne egy (technikai) kérdésem:

Nem használtam eddig restic-et, így nem ismerem. Próbáltam rákeresni, de konkrét választ eddig nem találtam.

Ha append-only módon megy a mentés a biztonság okán, akkor hogyan tudom korlátozni a helyfoglalását? Hogyan működik az (az append-only mód biztonságát megtartva), hogy bizonyos dátumnál régebbieket kezdje eldobálni? Nyilván senki sem szeretné a végtelenbe növelni a mentés méretét, és szükség sincs ősrégi adatokra. A restic oldala alapján úgy tűnik, ilyen karbantartást csak a szerveren lehet futtatni a repón, merthogy a kliens felől csak append-only mentést fogad el, semmi mást (pláne nem törési utasítást).

Értem, hogy az inkrementális mentés és a deduplikálás miatt egy idő után nagyon kicsi a növekmény (plusz tárhely igény), de akkor is foglalkoztat, hogy erre van-e megoldás, vagy a repó csak a szerver oldalon "tisztítható", a kliens felől ez nem befolyásolható? Ha olyan hely mentése folyik ahol aránylag sok a változás (jön új cucc, de kukába kerül sok régi), akkor a különbözet mindig lehet sok, így a növekmény is a tároló oldalon.

Vagy a gyakorlati tapasztalatok alapján ezzel nem is érdemes foglalkozni, olyan elenyésző a haszna?

Létezik a retention policy szerinti takarítás restic-nél, például:

restic forget --keep-daily 30 --keep-weekly 4 --keep-monthly 3 --keep-yearly 1 --prune

De ez nálunk nem működik, mert fel kellene adnunk az append-only üzemmódot (legalább ideiglenesen), és mi ezt szerver oldalról (a kulcs hiányában) sem tudjuk elvégezni. Úgy viszont sérülne a security, ha a mentendő oldal meg tudja piszkálni a mentéseket, innentől kezdve nem lehetne bízni a mentésekben.

Külső szolgáltatóként pedig pull üzemmódra nem válthatunk, mert ott meg a bizalmi kérdés jönne elő. Inkább ezt elengedtük, és ami hátránynak tűnik, azt előnyre próbáljuk váltani.

Mi egyébként is azt láttuk, hogy átlagos felhasználásnál egyszerűen nem is éri meg a törléssel ilyen módon foglalkozni. Alig nyerünk helyet. Sok VPS-t, fileszervert, adatbázisszervert, sőt SAP szervert is mentünk ilyen módon - ahol pedig terabájtokkal gurigáznak -, és néhány különleges esetet kivéve még ott sem érdemes purgálni.

Ha indokolt, akkor új repo-t szoktunk kezdeni, a régit archiváljuk vagy a lejárati idő után elfelejtjük.