Vykolej Rozkašil
Ano, je tomu tak. Co neni ve zdroji, v zaloze ano, to --delete smaze. Tak zaloha nebude expandovat na velikosti pri kazdem presunuti prejmenovani souboru-slozek ve zdroji.
To lze resit pomoci prepinace --backup --backup-dir="backup_$(date +%Y-%m-%d)". Smazane soubory se presunou pak do backup-dir slozky, kterou pak muzes cas od casu smazat.
Kdyz budu pravidelne zalohovat, tak budu cilovou slozku udrzovat stejnou jako zdroj, takze prenesu nove soubory, soubory co ve zdroji nejsou, se v cili smazou. To tak musi byt, jinak by zustavaly soubory a slozky v cili po kazdem prejmenovavi, presunuti, vymazani nepotrebnych dat ve zdroji. Stejne tak se pochopitelne aktualizuje cil pri jakekoliv zmene souboru-slozky ve zdroji, zmenene soubory ve zdroji se aktualizuji. Jinak by obem zaloh nekontrolovane rostl. Tento typ zalohy zdroj-cil me chrani proti padu systemu-ci hdd ve zdroji. Pokud je cil v jinem geografickem miste, co nejdal nejlepe, tak me to chrani pred vykradenim (zlodej by vzal zkancelare zdroj i cil), pozarem, povodni, podobne.
Pokud zroj odejde v dobe prenosu-zalohy, odpali to prave prenaseny soubor nejmene, a take vse nove od posledni zalohy, co se nestacilo zalohovat. A navic pokud odejde cil, tak jsem zcela nechranen, nez si zaridim cil novy. V takovem pripade by snad pomohly dve zalozni mista (zdroj a dva ruzne cile nejlepe geograficky daleko, kazdy zazalohovat v jinou dobu).
Prvni dva odstavce me neochrani pred moji blbosti v pripade jednoho cile (spatne si neco smazu-zmenim), pred ramsomware, nejakym blbym behem skriptu, zaskodnictvim kolegu, preklopenim bitu a podobnych veci. V pripade dvou cilu musim vcas reagovat. Take pomuze, ze zaloha neni prez CRON, pouspim manualne, kdyz se nic nedeja a po vetsi praci vim, ze je potreba zalohovat. Ale nesmim na zalohovani zapominat. Pak se mi zaloha nespusti hned po tom, co chybou neco na disku podelam. Tam kde jsou treba zalohy casto, tam automatizace ale byt musi.
Pokud dojde softwarove (moje blblost, zaskodnik, ramsomware) ke zniceni dat ve zdroji, nepoznam to vcas, pak me ani dva ruzne zalozni cile nezachrani a pomuze jen delat si pravidelne zalohy nezavisle s ruznymi verzemi (k ruznym datum). To jde u maleho obemu dulezitych dat (diplomka, skript, clanek, kniha). Mimo jine, mam i ak nejaky, byt neprimy dukaz, kdyz me oponent krive obvini s opisovani a pod. Zaloha typu, ze si vse zazalohuju jednou za mesic, to jde u malych dat, nebot prave o obem dat vzroste velikost zaloh z kazdym behem. Kdyz zalohuju par MB kazdy den, za rok to da GB. A pak stare verze ruzne promazavat. Budu-li chtit zazalohovat 1 TB jednou za tyden, je to uz draha sranda (na pasky nejspis). Existuji ale reseni lepsi, nez vse s kazdou zalohou zapisovat, jak uz bylo zmineno. V tom se moc uz nevyznam. A u velkych objemu a castych zmen stale drahe. Velmi dobre vypada moznost, jak navrhl xhonzik.
Kdyz zalohuju s ruznymi verzemi (jednou za tyden treba) na jedno velke medium, i to se muze podelat. Pak verzovani nepomuze a pomuze jen stridat vic ruznych medii (vypalovat na opticka media). A pak bych ty media musel ruzne rozvazet, pro zabraneni zkazy v pripade pozaru. To uz je narocna zaloha.
Jak tedy jsou reseny zalohy firemni, kde je velky objem dat, musi se to zalohovat casto, ochrana proti zivelne katastrofe, a dalsi. A jeste navic to musi byt sifrovane a nesmi se nikde vyskytnout chyba. Takovy je treba SIS na Karlovce vc. ulozenych diplomovych a dalsich praci, nebo Studentske uloziste. Tam uz me nenapada, jak do bezpecne vyresit.
Jinak se najdou experti, co si nezalohuji ani tech par MB rozepsane knizky, nebo diplomky. A pak se divi cenam za zachranu dat. U maleho mnozstvi je to tak jednoduche.
18 Odpovědí
16738 Zhlédnutí