Jasne ze v podnikovej sfere zalohovat treba o 106, ale nemyslis si nahodou tri pojmy "zalohovanie" a "archivacia" a "redundancia" ??? Pretoze vsetky tri pojmy splietas dokopy.
REDUNDANCIA:
hadrverova - napr. RAID5, RAID6, pripadne zrkadlenie celeho pola na iny server/lokalitu
softverova - servery v klastri (dva ci desat, nemusia byt absolutne identicke) pre load balancing, failover balancing a vseob. vysoku dostupnost
ZALOHOVANIE:
full bckup - natrepe sa to vsetko komplet nasurovo na pasky napr. raz denne/tyzdenne
inkrementalne - tiez moze byt na pasky, je medzi full bckupmi sa kontinualne zalohuju prevedene zmeny, pri vyuzivani transakcnych logov je mozne vratit sa do stuvu v ktorejkolvek sekunde (!!!), t.j. point in time restore, napr. restorujem si system/databazu do casu - vcera, 14:57 hod. Zalohovanioe je CYKLICKE! T.j. najstarsie zaznamy sa prepisuju novsimi, mozem to robit napr. 2 tyzdne, mesiac, hovori sa tomu doba retencie. Od takehoto zalohovania sa upusta, pokial mi tuto funkcionalitu vie zabezpecit sam system. T.j. ak by mal system nejaky specialny kos/zumpu s funkciou point in time restore a viem tomu nastavit retenciu napr. mesiac, stava sa pre mna VESKERE zalohovanie na pasky (full aj inkremental) zbytocne a riesit musim poriadnu redundanciu
ARCHIVACIA
jednorazovo sa to natrieska na nejake viacnasobne storage (napr. raz mesacne/ kvartalne/polrocne/rocne) a tieto archivy (mesacné, kvartálne, polrocné, rocné) sa zamknu do trezoru a tam sa to skladuje 10-15 rokov...(samozrejme aj periodicky kontroluje ci su data OK) podla frekvencie zaohovania ziva databaza obsahuje data len napr, za posledny rok a menej.... ak je to taky typ databazy, ze data tam len furt pribudaju
Pjetro de