Fórum Root.cz
Hlavní témata => Hardware => Téma založeno: ZAJDAN 07. 09. 2017, 19:31:25
-
Ahoj...připadá to pouze mě, že používat dnes zalohování na TAPE device je neohrabané?
-
Zalezi co od zalohy ocekavas. Na neco jo, na neco ne... Asi je kazdemu jasne ze je rozdil mezi zalohovanim fotek a transakcniho logu z na WORM pasky...
-
Ahoj...připadá to pouze mě, že používat dnes zalohování na TAPE device je neohrabané?
Neohrabané to bylo vždycky. Ale i teď jsou stále aplikace, kde je to jediné rozumně použitelné řešení.
-
je to jediné rozumně použitelné řešení.
Rozumné a celkem i laciné řešení.
https://www.mironet.cz/hp-ultrium-625-tb-lto6-data-tape+dp227704 (https://www.mironet.cz/hp-ultrium-625-tb-lto6-data-tape+dp227704)
6.25 TB a pro firmu je cena 688Kč.
To by mě zajímalo, na co levnějšího by se mělo zálohovat :P
6TB disk vyjde na 5800 a mám jeden, za stejnou cenu mám deset pásek.
Samozřejmě, je potřeba započítat cenu mechaniky, ale pokud bych vzal 10 disků 6TB, jsem na 58 000.
Při potřebě mít jednu měsíční zálohu po dobu dvou let = 24 pásek + 5-8 pásek na točení, abych měl zálohu každý den, je to prostě i laciné.
Mimo to, nechat stát disk dva roky není právě nejlepší nápad, dnešní disky plněné heliem a částečným přepisem stop (aby se na disk vešlo víc stop, tak se část stopy vždy přepíše) ... tyhle nové disky jsou dost citlivé na seřízení. Nejsem si jistý, jestli by se disku chtělo ještě po dvou-třech letech ležení v trezoru makat bez poruchy.
Kdežto ty pásky můžu používat klidně šest let.
-
nic levnejsiho neexistuje. bohuzel to ale neni pro kazdeho. pocatecni naklady jsou dost velke. rozumny sw, ktery umi pracovat v knihovnami taky neni zadarmo. pokud ale pocitate objem zaloh v PB, tak je potreba vzit v uvahu i cenu elektriny.
-
nic levnejsiho neexistuje. bohuzel to ale neni pro kazdeho. pocatecni naklady jsou dost velke. rozumny sw, ktery umi pracovat v knihovnami taky neni zadarmo. pokud ale pocitate objem zaloh v PB, tak je potreba vzit v uvahu i cenu elektriny.
Linux si s páskou velmi dobře poradí, minimálně LTO2,3,4,5.
mt proti st0 nebo nst0 a žádný velký software není potřeba.
Bacula s páskou tuším taky umí (nebo ne?).
A viděl jsem i docela dobrý softík za bratru 5k, který měl evidenci toho, co je na které pásce...jméno mi vypadlo, nekoupil jsem ho.
A Microsoftí zálohovací křáp ....pěkně děkuju...FUJ!
Já mám pásky rád :-D
-
Kdyby někdo hodně brečel, že by si to chtěl vyzkoušet, můžu do netu vystrčit pokusnou mašinu s LTO2 mechanikou a páskou, mám tu i LTO4, ale tu mám rád :-D
-
Záleží, kolik toho potřebujete zálohovat. Páska má nízkou cenu za bajt, ale obrovské počáteční náklady. Je to podobné, jako když se zeptáte, jestli se dnes vyplatí vlaky. Pokud přepravujete tisíce tun, tak se vlaku nic nevyrovná. Pro přepravu deseti tun je o hodně levnější odvézt to náklaďákem. S páskou je to podobné, pokud budete zálohovat desítky petabajtů, nemá konkurenci, pokud desítky terabajtů, tak se vám investice do mechaniky nikdy nevrátí.
-
Kombinace free VTL a jedné mechaniky je myslím doposud ekonomicky nepřekonatelné řešení i pro větší objemy dat v řádu desítek TB, VTL používám qualstor a naprostá spokojenost. Při ceně LTO 6 kazety 500kč není co řešit. Další krutý trik je LTOFS...
-
pokud desítky terabajtů, tak se vám investice do mechaniky nikdy nevrátí
Asi ti rozumím, ale nepíšeš to formálně správně.
Jde o četnost.
Na pásku můžeš narvat všechna firemní data každý den.
Točit 14 pásek a můžeš se vrátit 14 dní zpět i když chytneš ten nejhnusnější virus šifrující disky.
Nebo mít připisování a jednou za týden přehodit pásku, tj. týdenní páska je inkrementální.
Každé pondělí prostě do mechaniky vložíš novou pásku a jsi v pohodě.
Pokud data hrneš na přimapované disky, může se nakrásno stát, že budou taky zašifrované.
Když lze zanedbat pořizovací náklady (třicet tisíc je cena jednoho notebooku), získáš celkem solidní zařízení.
Naprosto zásadní je mít software, který tě NESERE, jinak se z pásky stává peklo.
Je lepší takový sráč vyhodit a nepoužívat, než se drbat s kokotským softwarem.
Ale s páskou si můžeš život udělat o hodně pohodlnější.
Jasně, dneska jsou shadowcopy a podobné vyfikundičky, taky jsem z pásky hlodal data asi dvakrát, protože shadowcopy je daleko rychlejší a když nejde shadowcopy, je snazší sosnout data z disku, než laborovat s páskama, ale víš, že ty zálohy máš a když ti začne hořet půda pod nohama, prostě vytáheš pásku a data máš.
-
Kombinace free VTL ...LTOFS...
Ty znáš nějaký takový dobrý software pro Virtual Tape Library?
LTOFS neznám, tato pokud můžeš přidat něco relevantního, budu ti VELMI vděčný!
-
...
Pokud data hrneš na přimapované disky, může se nakrásno stát, že budou taky zašifrované.
...
Uplne stejne budes mit zasifrovany pasky ... na discich si udelas snap a potrebujes ve skutecnosti kapacitu nikoli 14x, ale tak mozna a kdovi jestli 2x. V 99% pripadu nebudes delat obnovu cely zalohy, ale obnovu jednotlivych souboru, coz pri pasce znamena mit dalsi uloziste kam se nejdriv rozbali data z pasky ... a pak z nich vytahnes jeden soubor, coz muze byt klidne i na desitky hodin. Na discich si primontujes snap a soubor skopirujes, otazka 2 minut.
-
...
Pokud data hrneš na přimapované disky, může se nakrásno stát, že budou taky zašifrované.
...
Uplne stejne budes mit zasifrovany pasky
Samozrejme to je mozne, ale dnesni viry snad neumi sifrovat na zarizeni, ktera nejsou pripojena jako dalsi FS, ale ovladaji se jinak, ne? Ukolem tech viru je byt co nejdele neviditelny, takze pro cteni (backup SW) vraci desifrovana data, ktera ten SW protlaci na pasku...
-
Bacula s páskou tuším taky umí (nebo ne?).
U Baculy/Bareosu je páska primární datový model - ke všemu se chová víceméně jako k pásce. I když zálohuješ na disk, ukládá tam Bacula data do souborů, které zapisuje/čte sekvenčně jako pásku.
Bacula umí s páskama hodně dobře - dává na začátek label, takže automaticky pozná, jestli je vložená správná páska, využívanou pásku odmítne přepsat, pokud se při zálohování dojde na konec pásky, umí poslat operátorovi mail, že má vložit novou pásku atd. atd. Pokud je to dobře promyšlené ohledně retencí atd., musí se s tím pracovat hodně dobře (osobně to ale vyzkoušeno nemám - plánoval jsem, ale nakonec nezrealizoval).
-
Ahoj...připadá to pouze mě, že používat dnes zalohování na TAPE device je neohrabané?
Záleží na tom, co od toho očekáváte, a jakou máte infrastrukturu. V mnoha případech jsou pásky nenahraditelné.
1. Pokud máte jen jeden site, tak úder blesku může zničit veškeré disky nebo RDX kartuše, pásky v knihovně ne.
2. Jednoduše lze odnášet a rotovat sady pásek (podobně ale i RDX kartuší).
3. Cena za 1 TB je u pásek nejnižší, ale víc zase stojí knihovna. Od určité kapacity se vyplatí pásky.
4. Pásky jsou škálovatelné do celkové velikosti úložiště, kterou na NAS nikdy rozumně nevytvoříte.
5. Pásky jsou ale pomalé.
Mnoho firem řeší např. problematiku archivace dat kvůli liberaci pro případ průšvihu v nastupujícím GDPR. Firmy, kterým stačlo do nedávna pár TB dat, chtějí mít např. archiv po dnech i půl roku. Pak už jste s NAS nahraný.
Nejčastěji se setkávám s backup D2D2T - tedy backup disk-to-disk-to-tape. Nejdřív je VM rychle odzálohována na NAS, poté "v poklid" do knihovny pásek.
Pak existují admini, kteří zatím pásky nepoznali, a vyhýbají se jim, a ti jsou se s vámi schopni do krve hádat, že nejsou potřeba - to je podobné, jako automatickou převodovku u auta odsuzuje jen ten, který nikdy s žádnou nejezdil.
-
... Pak už jste s NAS nahraný....
A to jako proc? Cca 20TB dat, zaloha (nikolil archiv) co 15 minut ... 1/2 roku zpatky. Narust a zmeny delaj cca 20% rocne, ty snapy zabiraj cca + 50% velikosti dat. Velikosti jednotlivych snapu sou v jednotkach MB max.
Pasky sou tak maximalne dobry na to, kdyz je nekdo nosi nekam do trezoru, coz nikdo delat dlouhodbe nebude tak jako tak. Pri vetsich objemech by musel premistovat hromady pasek, coz nepripada v uvahu uz vubec.
Sou admini ktery pasky videli, pouzivali a radi tuhle zastaralou a nepouzitelnou technologgii hodili do popelnic.
-
pokud vim, tak se prichazi legislativa, ktera prikazuje hernam mit nad kazdym forbesem hd kameru s historii asi pul roku.
myslim, ze pasky prijdou v tomto segmentu hodne rychle do mody.
-
Na pásky jsem zálohoval mezi lety 1997 až 2005. Přímo disk->tape
Pak jsem je na nějakou dobu opustil a přešel na NAS. Takže: disk->NAS
Nakonec jsem se k nim ale opět vrátil a tak NAS zálohuju na pásky. Tedy: disk->NAS->tape
-
... Pak už jste s NAS nahraný....
A to jako proc? Cca 20TB dat, zaloha (nikolil archiv) co 15 minut ... 1/2 roku zpatky. Narust a zmeny delaj cca 20% rocne, ty snapy zabiraj cca + 50% velikosti dat. Velikosti jednotlivych snapu sou v jednotkach MB max.
Pasky sou tak maximalne dobry na to, kdyz je nekdo nosi nekam do trezoru, coz nikdo delat dlouhodbe nebude tak jako tak. Pri vetsich objemech by musel premistovat hromady pasek, coz nepripada v uvahu uz vubec.
Sou admini ktery pasky videli, pouzivali a radi tuhle zastaralou a nepouzitelnou technologgii hodili do popelnic.
20 TB je prd, 20 TB bych zálohoval na disky nebo RDX a kašlal bych na pásky. Bavím se opravdu o větších datech.
-
Při ceně LTO 6 kazety 500kč není co řešit.
Kde sa da kupit LTO6 za 500kc? Je mi jasne, ze na Heureke sa to nekupuje, ale ona ukazuje cenu 750kc.
-
Ono co tu ještě snad nikdo nezmínil, tak je spolehlivost pásek. Při vhodném skladování jsou na tom momentálně snad nejlépe (minimálně z finančně dostupných technologií). Pokud zálohujete logy z DB a další data v celkových řádech PB a potřebujete mít určitou historii, v podstatě neexistuje jiná použitelná technologie.
-
máte prosim nekdo tip aplikace s GUI nejlepe pro Debian
-
máte prosim nekdo tip aplikace s GUI nejlepe pro Debian
GUI na linuxu existuje, např. pro Baculu nebo Bareos. Celkově ale tyto systémy nesnesou srovnání s moderními systémy běžícími pod Windows. Náročnost nasazení a údržby Baculy/Bareosu je násobně vyšší, než např. u Veritas/ARCserver/Veeam/Acronis a pod. Jestli hledáte klikačku a jednoduché řešení, dívejte se spíš po těchto řešeních.
-
GUI na linuxu existuje, např. pro Baculu nebo Bareos. Celkově ale tyto systémy nesnesou srovnání s moderními systémy běžícími pod Windows. Náročnost nasazení a údržby Baculy/Bareosu je násobně vyšší, než např. u Veritas/ARCserver/Veeam/Acronis a pod. Jestli hledáte klikačku a jednoduché řešení, dívejte se spíš po těchto řešeních.
ok prdim na GUI...zkusil jsem to pres terminal...zajima me zda pujde poslat zaloha na pasku pres ssh...coz predpokladam by nemel byt problem
-
zajima me zda pujde poslat zaloha na pasku pres ssh...coz predpokladam by nemel byt problem
Nerozumím dotazu. Bareos/Bacula si řeší přenosy vlastním agentem (daemonem).
Z dotazu trochu cítím, že asi zálohování na pásky moc neznáte - není to vůbec podobné, jako odkopírovat soubor na disk.
-
Nerozumím dotazu. Bareos/Bacula si řeší přenosy vlastním agentem (daemonem).
Z dotazu trochu cítím, že asi zálohování na pásky moc neznáte - není to vůbec podobné, jako odkopírovat soubor na disk.
ano pasky jsem kdysi pouzival jen na windows...ted jsem si rekl ze po letech tu mechaniku pripnu na linuxovej stroj...
mel jsem na mysli neco takovehoto:
# tar cvzf - /data | ssh root@192.168.6.2 "cat > /dev/st0"
-
Nerozumím dotazu. Bareos/Bacula si řeší přenosy vlastním agentem (daemonem).
Z dotazu trochu cítím, že asi zálohování na pásky moc neznáte - není to vůbec podobné, jako odkopírovat soubor na disk.
ano pasky jsem kdysi pouzival jen na windows...ted jsem si rekl ze po letech tu mechaniku pripnu na linuxovej stroj...
mel jsem na mysli neco takovehoto:
# tar cvzf - /data | ssh root@192.168.6.2 "cat > /dev/st0"
Teoreticky by to jít mělo, ale nebudete mít žádnou správu dat na páskách. Tar přesně pro takový účel vznikl - ale před 4 dekádami :).
-
Náročnost nasazení a údržby Baculy/Bareosu je násobně vyšší, než např. u Veritas/ARCserver/Veeam/Acronis a pod.
Co je potřeba na Bareosu udržovat?!
-
zajima me zda pujde poslat zaloha na pasku pres ssh...coz predpokladam by nemel byt problem
Bacula/Bareos ma 4 oddělené části: director, storage (SD), file daemon (FD) a aplikaci (konzole, web nebo GUI). FD běží na stanici, která se má zálohovat. Zálohy probíhají (zjednodušeně) tak, že director řekne FD: zazálohuj tyhle soubory a pošli je na tenhle SD. SD má otevřený vlastní port, na ten se FD připojí a komunikují spolu speciálním protokolem.
...čili je otázka, proč bys tam rval ssh. Pokud je potřeba provoz šifrovat, používá se TLS. Všechny součásti systému ho umí, včetně oboustranného ověření identity.
-
Náročnost nasazení a údržby Baculy/Bareosu je násobně vyšší, než např. u Veritas/ARCserver/Veeam/Acronis a pod.
Co je potřeba na Bareosu udržovat?!
Např. databáze je ráda nekonzistentní, např. non ASCII znaky ve jménech souborů jsou peklo (default db je SQL_ASCII), ..., ... Prostě to vyžaduje nějaké znalosti správce.
-
Kde sa da kupit LTO6 za 500kc? Je mi jasne, ze na Heureke sa to nekupuje, ale ona ukazuje cenu 750kc.
https://www.mironet.cz/hp-ultrium-625-tb-lto6-data-tape+dp227704/#64404887 (https://www.mironet.cz/hp-ultrium-625-tb-lto6-data-tape+dp227704/#64404887)
Firmy jsou plátci DPH, proto pro firmu počítej cenu bez DPH.
DPH je trest za to, že chodíš do práce, to jsou další peníze, které ti stát sebere.
Firma si je uplatní.
Cena pro každou firmu: 688,- bez DPH
Pokud máš smlouvu a trochu obraty, jsi podstatně níž, než na 688Kč.
Celkem běžně se dostaneš na 600,- Kč.
Pokud si domluvíš dodávky s nějakou firmou z Německa, dostaneš se na těch 500 Kč.
Mimo to, někde jsem viděl nabídku na pásky za 550Kč (BEZ DPH) i tady v ČR, jen se mi to teď nechce hledat.
-
Co je potřeba na Bareosu udržovat?!
...nebo třeba práce s extended filesystem attributes, pokud používáte víc typů filesystémů (ext, zfs, ntfs, ...)...
-
jak tak paska vlastne funguje?
-kdyz na pasku nahraji data a nepretocim ji na zacatek, tak dalsi data se zapisi za ty puvodni?
-kdyz pasku vzdy pretocim, nove data budou prepisovat ty puvodni smerem od zacatku?
tipuji ze vlastne neni mozne pouzivat rsync...nebo se mylim?
-
Kde sa da kupit LTO6 za 500kc? Je mi jasne, ze na Heureke sa to nekupuje, ale ona ukazuje cenu 750kc.
Mimo to, někde jsem viděl nabídku na pásky za 550Kč (BEZ DPH) i tady v ČR, jen se mi to teď nechce hledat.
Pro tvojí informaci:
https://www.mironet.cz/quantum-data-cartridge-lto5-lto-ultrium-gen-5-16003200gb+dp106869/ (https://www.mironet.cz/quantum-data-cartridge-lto5-lto-ultrium-gen-5-16003200gb+dp106869/)
Pokud ti stačí 1.6TB, jsou pásky LTO5 levnější a v mechanice LTO6 je normálně zapíšeš.
Mohl by ses dostat na 450Kč/kus (den?).
Na jedné straně se ti zhorší poměr cena/kapacita, ale pokud těch pásek potřebuješ točit hodně, něco ušetříš.
Na tu pásku narveš bezpečně 2TB souborů i když tam bude dost videa, pokud bys měl jen video, nebude to s kompresí žádná sláva.
-
Např. databáze je ráda nekonzistentní, např. non ASCII znaky ve jménech souborů jsou peklo (default db je SQL_ASCII), ..., ... Prostě to vyžaduje nějaké znalosti správce.
1. SQL_ASCII je tam záměrně a je to default. Čili veškerá znalost v tomhle případě spočívá v pravidle "nainstaluj to a nic neřeš" :)
2. non-ascii názvy souborů se obnoví přesně tak, jak se zazálohovaly - čili na systémech se stejným kódováním žádný problém není.
3. Není to údržba, maximálně nastavení. Já jsem se ptal na údržbu.
-
...
Vše v praxi způsobuje, že musíte řešit víc problémů (incidentů, požadavků - nazývejte to, jak chcete), než u jiných systémů. Je sice hezké, že filename je obnovený stejně, ale v praxi nic nedohledáte v konzoli, když tam jsou české znaky. Databáze "nainstaluj a nestarej se" - taky hezký nápad, ale asi jste ještě u Baculy neřešil nekonzistentní FK.
Já neříkám, že není k použití. Sám bareos používám ke spokojenosti, ale pokud mám před sebou tazatele - méně zkušeného admina - pak i to vše, co jsem napsal, musí padat na misky vah při výběru řešení.
-
...nebo se mylim?
Musíš si to nastudovat ;)
Páska se chová tak, jak jí řekneš, že se má chovat.
Základ je vysvětlený třeba zde: https://www.cyberciti.biz/hardware/unix-linux-basic-tape-management-commands/ (https://www.cyberciti.biz/hardware/unix-linux-basic-tape-management-commands/) Nebo tady: https://wiki.zmanda.com/index.php/Tape_Driver_Semantics (https://wiki.zmanda.com/index.php/Tape_Driver_Semantics)
Jinak ve zkratce, po připojení pásky se "vlastně" objeví DVĚ zařízení.
Například st0 / nst0 a rozdíl v nich je ten, že zatímco první zařízení provede rewind na začátek pásky, druhé prostě skončí na daném místě. MT+TAR je lepší než DD, lépe se s tím pracuje, resp. já s páskou pracoval vždy jen s MT vyjma případů, kdy jsem chtěl natvrdo smazat zavadeč.
Skript pro připsání souboru a pásku by vypadal třeba takhle.
Přetoč pásku na začátek (pro jistotu).
Jdi na poslední EOF
Připiš soubor, připiš soubor, připiš soubor. Rewind.
Pokud bys ale zapisoval na pásku jen jeden velký blob.
Přetoč pásku na začátek, použij zařízení, které dělá automatický rewind, eject.
Páska dělá to, co chceš, aby dělala.
Není to hard disk, pracuje se s ní jinak.
-
Je sice hezké, že filename je obnovený stejně, ale v praxi nic nedohledáte v konzoli, když tam jsou české znaky.
Není s tím žádným problém u systémů, které používají UTF-8. Tj. všechny běžné systémy (u Win se na UTF-8 automaticky převádí).
Databáze "nainstaluj a nestarej se" - taky hezký nápad, ale asi jste ještě u Baculy neřešil nekonzistentní FK.
Ne, to jsem opravdu neřešil - a ani nevím, jak by mohly vzniknout, protože to databáze hlídá sama. Problém může nastat s orphanes a řeší ho příkaz bareos-dbcheck.
Já neříkám, že není k použití. Sám bareos používám ke spokojenosti, ale pokud mám před sebou tazatele - méně zkušeného admina - pak i to vše, co jsem napsal, musí padat na misky vah při výběru řešení.
Vidím to přesně opačně: méně zkušený admin bude zálohovat pár serverů, typicky s jedním, dvěma operačními systémy a na žádné problémy vůbec nenarazí. Nemá pro něj sebemenší smysl investovat do nějaké předražené komerční bestie, která má taky svých problémů dost.
Jedinej problém pro začínajícího admina bude pochopit konfiguraci. To je bez pochyby oříšek, ale to by byl i s čímkoli jiným (stejné síly).
-
https://www.root.cz/zpravicky/gnucobol-2-2-nova-stabilni-verze-po-osmi-letech/#newIndex1 (https://www.root.cz/zpravicky/gnucobol-2-2-nova-stabilni-verze-po-osmi-letech/#newIndex1)
Vy pojedete za Leninem?
A nemáš e-mail na Ruma?
-
Vidím to přesně opačně: méně zkušený admin bude zálohovat pár serverů, typicky s jedním, dvěma operačními systémy a na žádné problémy vůbec nenarazí. Nemá pro něj sebemenší smysl investovat do nějaké předražené komerční bestie, která má taky svých problémů dost.
Respektuji Váš názor.
Když se podívám na mzdu admina a cenu hardwaru, nepřijde mi žádné řešení na trhu předražené. Admin v malé firmě má sám na bedrech spoustu úkolů, aby se babral se složitými řešeními (a není nic smutnějšího než write-only záloha). Ve velké firmě se zase uplatní úspory z rozsahu.
Díky za diskusi.
-
Linux si s páskou velmi dobře poradí, minimálně LTO2,3,4,5.
mt proti st0 nebo nst0 a žádný velký software není potřeba.
Oproti ovladacum v Linux kernelu bych mel mensi vyhrady, ale nic zasadniho. Dulezitejsi je jestli si Bakula (a ostatni) poradi s robotem v paskove knihovne.
V tehle oblasti je to bohuzel jeste horsi nez u diskovych poli. Vetsina lidi co programuje pro Linux nema pristup k tak drahym hrackam a i kdyz uz pristup maji, tak ho nemuzou vyuzit pro vyvoj OS software.
Zalohovani pomoci tar-u upravdu patri do minuleho stoleti.
-
Zalohovani pomoci tar-u upravdu patri do minuleho stoleti.
Unix je taky z minulého století ::)
Že je něco staré ještě nemusí znamenat, že je to špatné.
-
Unix je taky z minulého století ::)
Že je něco staré ještě nemusí znamenat, že je to špatné.
No, ale zde se bavíme o zálohování na pásku pomocí tar + ssh. Takové řešení nemá moc racionálních důvodů a v dnešní době je překonané - mimo jiné i zálohováním na disk. Síla pásek leží někde jinde. Stejně jako síla Unixu neleží např. v desktopových aplikacích nebo CADU.
-
Kde mluvím o SSH?
Moje řešení funguje tak, že mám ke stroji s diskem iSCSI připojenou LTO mechaniku.
Ten iSCSI disk je připojený do serveru RW a zálohovací mašina k němu má jen R, je to z pohodlnosti.
Data jsou konzistentní, uzamčení řeší skript na serveru.
Proces běží následovně:
Vezmu data z 6TB iSCSI, zazálohuji vše potřebné s limity -exe|com; -(avi|mov|mpg|mkv)&(%size>300MB); ?%size*>2GB=!split^%zip; V tom momentě mám data už zkomprimovaná na pracovním disku (2TB) a pak se spustí TAR, který to prdne na pásku.
Vzhledem k tomu, že data na iSCSI odsouvá robot, nevím, proč bych měl používat nějaký silnější nástroj, než právě ten TAR. Pásku po vyjmutí z mechaniky zamknu a označím datum.
Když už, tak obnovuji celou pásku na pracovní disk, čistě z lenosti, jedním kliknutím si pásku překopíruju na pracovní disk. V 90% případů stačí sáhnout na ShadowCopy, v 9% jsou data na iSCSI (cca 14 dní) a zbývající jedno procento nastává velmi zřídka, některý rok vůbec.
Jsem schopný obnovit cokoliv v rámci jednotlivých dnů po dobu půl roku, cokoliv v rámci týdnů po dobu jednoho roku a měsíční zálohy po dobu tří let.
Vážně si nejsem jistý, jak by mi mohl nějaký pokročilý nástroj pomoci.
Používal jsem různé zálohovací nástroje a tohle je prostě bezúdržbové, nevím o tom.
Není tam žádná databáze, není co udržovat, je to jen sada skriptů.
Nic se nemůže rozbít, pásku můžu vzít k jiné mechanice a z libovolného linuxu jí obnovit.
Čtvrtletně obnovuji jednu pásku, abych měl jistotu, že zálohování funguje.
Udělám o tom zápis do deníku a nazdar párky.
-
...
Mě na Vašem řešení dráždí tři věci:
1. výběr dat k zálohování - je poplatný Vaší subjektivní zkušenosti, co je důležité, a co ne (a je jen na Vaší svědomitosti, abyste odchytil, pokud se potřeby firmy změní),
2. je poměrně složité na kooperaci s dalšími osobami - musí být další admin proškolený na tento způsob práce,
3. nepočítá s páskovou knihovnou, ale s ruční výměnou pásek.
Když si vezmu, co stojí čas tak kvalifikovaného odborníka, jako jste, a porovnám to s jednoduchým řešením D2D2T, na které mi dokáže navázat i méně zkušený admin bez zaškolování, přijde mi to Vaše řešení prostě zbytečně složité. Ne ve smyslu nezvladatelné, nebo technicky špatné - ale rizikové pro firmu. Je možné, že si tím tvoříte závislost firmy na sobě a Vašich řešeních. Jak zajišťujete, abyste na to měl čas a mozkovou kapacitu v době, kdy řešíte urgentnější úkoly? Podle mě na to existuje jediná možnost: mít Vás (admina) vytíženého tak málo (s rezervami), aby byla jistota, že to vždy zvládnete. Co dovolené? Co např. střednědobá nemoc (několik měsíců)?
Připadá mi, že v 21. století obhajujete trakař proti autu. Je možné, že máte pravdu v nějakém konkrétním případě, ale hodně pochybuji, že se dá Vaše zkušenost generalizovat.
BTW shadow copy je první, co dnešní ransomware vypíná, určitě bych ji dnes hodnotil na méně, než na 90 % jistoty.
-
Abych nebyl moc rozvláčný.
Zálohuje se to, co je definováno podle našeho standardu IT a po definovanou stejným standardem IT.
Jinými slovy, aby bylo možné udržet certifikace ve smyslu iso 27001/27002, existuje proces, dokumentace a metody.
S ohledem na to, že to plně vyhovuje VW, které čas od času posílá auditory, myslím, že to je uděláno dobře.
V popisu práce IT je "V pondělí vytisknout e-mail s reportem o průběhu zálohy, přiložit ho k pásce a s ní odevzdat Finančnímu manažerovi proti podpisu."
Jsem si jistý, že byste to zvládl i vy, opravdu se jedná o vytištění jednoho dokumentu, založení nové pásky, odnesení pásky do jiné kanceláře a provedení podpisu. Stejně tak by to zvládl i finanční manažer.
Komplikovanější situace nastává při čtvrtletním auditu, kdy se provádí - mimo jiné - i kontrola nastavení všech systémů proti standardu, kontrola účtů a logů. Vše proti záznamu do deníku - a podle předem definovaných scénářů tak, aby to bylo možné zkontrolovat a obstálo při plnohodnotném auditu 2700x.
Pokud by se prokázala nefunkčnost čehokoliv, vytvoří se na to standardní tiket, jako třeba na rozbitou tiskárnu a bude se to řešit tak, aby došlo k nápravě poruchy. Jelikož je to zásah na zařízení IT podléhajícímu auditu, je nezbytné provést testy obnovení a zálohy, tj. v podstatě po ukončení opravy musí dojít k otestování řešení přesně podle pravidelného čtvrtletního scénáře.
Pásková knihovna se nepoužívá, pásky musí být uloženy v jiné budově (doporučení dle ISO) a páska má dostatečnou kapacitu i rezervu, aby mohla cca 5 let sloužit.
Trochu mě dráždí tyto vaše pochybnosti obzvláště v kontrastu vysoké spokojenosti auditorů z Německa, kteří opakovaně vyslovují spokojenost s úrovní nastavení bezpečnosti ve firmě a to i z hlediska bezpečnosti zálohy dat a kontinuity provozu.
Pokud to vypadá, že s tou páskou trávím mnoho času, tak rozhodně ne, jsou to celkem asi dvě minuty týdně.
Vytisknu e-mail, vyměním pásku, vezmu hrnek na kafe a cestou jí odnesu. Nazdar párky. Než se mi to kafe uvaří, trvá podstatně déle.
-
Trochu mě dráždí tyto vaše pochybnosti obzvláště v kontrastu vysoké spokojenosti auditorů z Německa
Tak kdyz si obhajis nakup superduper sw za desetitisice/statisice, nechce se ti moc uznat, ze by ho slo nahradit necim tak stupidnim jako je tar ;)
-
Tak tato debata o taru je celkem bezpředmětná... tar je udělanej přesně pro potřeby pásek (Tape ARchiver) a pásky jsou už x desítek let pořád stejný.
-
Tak tato debata o taru je celkem bezpředmětná... tar je udělanej přesně pro potřeby pásek (Tape ARchiver) a pásky jsou už x desítek let pořád stejný.
konecne uderny argument
-
Jak je to s kapacitou pasek? To co je udavane je realna kapacita, tedy kdyz tam nahraju treba fotky, ktere se nezkomprimuji? Tusim ze je v tom hacek, dik...
-
Kde sa da kupit LTO6 za 500kc? Je mi jasne, ze na Heureke sa to nekupuje, ale ona ukazuje cenu 750kc.
Mimo to, někde jsem viděl nabídku na pásky za 550Kč (BEZ DPH) i tady v ČR, jen se mi to teď nechce hledat.
Pro tvojí informaci:
https://www.mironet.cz/quantum-data-cartridge-lto5-lto-ultrium-gen-5-16003200gb+dp106869/ (https://www.mironet.cz/quantum-data-cartridge-lto5-lto-ultrium-gen-5-16003200gb+dp106869/)
Pokud ti stačí 1.6TB, jsou pásky LTO5 levnější a v mechanice LTO6 je normálně zapíšeš.
Mohl by ses dostat na 450Kč/kus (den?).
Zase teoretik alebo niekto, kto zaplati tisicku aby usporil stovku ::).
LTO5 v LTO6 mechanike zapise a aj precita, ale rychlo si znici hlavu. Po 500 zapisanych paskach ju bude musiet vymenit. Kompatibilita je na urovni marketingu a pre pripad nutnosti, nie pre kazdodenne pouzivanie. LTO5 paska do LTO6 mechaniky je ako smirgel.
-
Zase teoretik alebo niekto, kto zaplati tisicku aby usporil stovku ::).
LTO5 v LTO6 mechanike zapise a aj precita, ale rychlo si znici hlavu. Po 500 zapisanych paskach ju bude musiet vymenit. Kompatibilita je na urovni marketingu a pre pripad nutnosti, nie pre kazdodenne pouzivanie. LTO5 paska do LTO6 mechaniky je ako smirgel.
Podlož svůj výplod (nechci psát žvást) oficiálním dokumentem.
Minimálně u mechanik od HP je to blábol, jako že jsem těch dokumentů k těm mechanikám viděl hodně.
Nicméně, prosím, předvěď se.
-
Jak je to s kapacitou pasek? To co je udavane je realna kapacita, tedy kdyz tam nahraju treba fotky, ktere se nezkomprimuji? Tusim ze je v tom hacek, dik...
Ano, ty jejich čísla vychází nejspíš z možností komprese kancelářských dokumentů a textových logů, měli by se na to uvádění té komprimované velikosti vyprdnout, dnes jsou obtížně komprimovatelná data podstatně běžnější.
Jak přijde na velká videa nebo fotky, zdaleka to není tak dobré.
Každopádně ta komprese není tak špatná, mechanika může operovat v módu RAW nebo v modu, kdy se provádí komprese, někdy se prostě nechceš komprimováním zdržovat a mechanika ti to umožní.
Mimochodem cena mechanik LTO-7 dost klesá, když má člověk štěstí, může jí od dodavatele v "akci" pořídit i za polovinu běžně udávané hodnoty, jen média jsou zatím celkem drahá, ale to se dá řešit a LTO7 média postupně zlevní.
https://zaznamova-media.heureka.cz/ibm-lto7-ultrium-6-15tb-38l7302/specifikace/#section (https://zaznamova-media.heureka.cz/ibm-lto7-ultrium-6-15tb-38l7302/specifikace/#section)
-
...
Ale zbytečně se čílíte, já jsem přeci připustil, že mohou existovat případy, kdy to může být nejlepší řešení. Víc se kolem toho snad hádat nemusíme :)
-
Tak tato debata o taru je celkem bezpředmětná... tar je udělanej přesně pro potřeby pásek (Tape ARchiver) a pásky jsou už x desítek let pořád stejný.
Ale struktura dat a potřeby obnovení se liší. Hrozby se liší. Tar neumí obsloužit knihovnu, evidovat labely vs. konkrétní zálohy atd. atd. Tar je superjednoduchý, superúčinný i superpřekonaný - to vše najednou, aniž by se to vylučovalo.
-
Jak je to s kapacitou pasek? To co je udavane je realna kapacita, tedy kdyz tam nahraju treba fotky, ktere se nezkomprimuji? Tusim ze je v tom hacek, dik...
Ano, ty jejich čísla vychází nejspíš z možností komprese kancelářských dokumentů a textových logů, měli by se na to uvádění té komprimované velikosti vyprdnout, dnes jsou obtížně komprimovatelná data podstatně běžnější.
Jak přijde na velká videa nebo fotky, zdaleka to není tak dobré.
Každopádně ta komprese není tak špatná, mechanika může operovat v módu RAW nebo v modu, kdy se provádí komprese, někdy se prostě nechceš komprimováním zdržovat a mechanika ti to umožní.
Mimochodem cena mechanik LTO-7 dost klesá, když má člověk štěstí, může jí od dodavatele v "akci" pořídit i za polovinu běžně udávané hodnoty, jen média jsou zatím celkem drahá, ale to se dá řešit a LTO7 média postupně zlevní.
https://zaznamova-media.heureka.cz/ibm-lto7-ultrium-6-15tb-38l7302/specifikace/#section (https://zaznamova-media.heureka.cz/ibm-lto7-ultrium-6-15tb-38l7302/specifikace/#section)
Dik a raw mod je teda u tveho odkazu predpokladam tedy 6tb fili u videa to bude o neco lepsi, ale ne o moc predpokladam...
-
Ale struktura dat a potřeby obnovení se liší. Hrozby se liší. Tar neumí obsloužit knihovnu, evidovat labely vs. konkrétní zálohy atd. atd. Tar je superjednoduchý, superúčinný i superpřekonaný - to vše najednou, aniž by se to vylučovalo.
Presne tak. Kdyz chci neco obnovit, tak si v GUI vyberu server, adresar, datum a SW za me vlozi spravnou pasku do mechaniky a pretoci ji na spravne misto. Predevsim obnova musi byt primocara.
Nechapu jak dneska jeste nekdo muze pouzivat na pasky tar. Navic potrebuju i nejaky scheduler a reporting.
-
První otázka je, jestli je nutné dlouhodobě archivovat video v nějaké super HD kvalitě, jestli nestačí mít pět dní (ostatně UOOU se pak ksichtí) na discích a na pásky dávat jen takové ty podstatnější věci. Chci říct, že se ty věci dají celkem třídit.
A ano, video neumí solidně zkomprimovat ani mechanika.
U videa ber v potaz "raw" kapacitu.
-
Ale struktura dat a potřeby obnovení se liší. Hrozby se liší. Tar neumí obsloužit knihovnu, evidovat labely vs. konkrétní zálohy atd. atd. Tar je superjednoduchý, superúčinný i superpřekonaný - to vše najednou, aniž by se to vylučovalo.
Presne tak. Kdyz chci neco obnovit, tak si v GUI vyberu server, adresar, datum a SW za me vlozi spravnou pasku do mechaniky a pretoci ji na spravne misto. Predevsim obnova musi byt primocara.
Nechapu jak dneska jeste nekdo muze pouzivat na pasky tar. Navic potrebuju i nejaky scheduler a reporting.
Pokud bych z těch pásek obnovoval něco častěji, tak si tu páskovou knihovnu taky pořídím.
Je mi líto peněz na něco, co bych použil jednou ročně.
-
První otázka je, jestli je nutné dlouhodobě archivovat video v nějaké super HD kvalitě, jestli nestačí mít pět dní (ostatně UOOU se pak ksichtí) na discích a na pásky dávat jen takové ty podstatnější věci. Chci říct, že se ty věci dají celkem třídit.
A ano, video neumí solidně zkomprimovat ani mechanika.
U videa ber v potaz "raw" kapacitu.
jelikoz jde o video ktere se pak monetizuje, tak bych ho nezahazoval :-) Dik za rady.
-
jelikoz jde o video ktere se pak monetizuje, tak bych ho nezahazoval :-) Dik za rady.
Jestli to je nějaký pěkný "kompro" na někoho a bude tam slušná monetizace, tak mi taky nějaké pošli.
Hodilo by se mi nový auto ;D
PS: Pásky jsou spíš na ukládání než přehrávání, není to videokazeta, kterou vložíš do přehrávače.
Než to přehraješ, budeš to muset z té pásky nejprve dostat, což trvá nějakou - ne právě malou - dobu.
-
Zase teoretik alebo niekto, kto zaplati tisicku aby usporil stovku ::).
LTO5 v LTO6 mechanike zapise a aj precita, ale rychlo si znici hlavu. Po 500 zapisanych paskach ju bude musiet vymenit. Kompatibilita je na urovni marketingu a pre pripad nutnosti, nie pre kazdodenne pouzivanie. LTO5 paska do LTO6 mechaniky je ako smirgel.
Podlož svůj výplod (nechci psát žvást) oficiálním dokumentem.
Minimálně u mechanik od HP je to blábol, jako že jsem těch dokumentů k těm mechanikám viděl hodně.
Nicméně, prosím, předvěď se.
Oficialne ti nikto neprizna, ze jeho mechaniky nepodporuju co vyrobca slubuje. Ked to mas aj s rozsirenou zarukou ako sucast StorageTek kniznice od Oraclu, tak ti mechaniky budu ochotne vymienat. Nikto sa ani len nepodivi, ze sa hlavy tak rychlo a predvidatelne nicia.
-
Pokud bych z těch pásek obnovoval něco častěji, tak si tu páskovou knihovnu taky pořídím.
Je mi líto peněz na něco, co bych použil jednou ročně.
A v tomto bodě se podle mě prostě mýlíte a převládá ve Vás IT odborník nad IT manažerem. Po první ztrátě dat, nebo po prvním výpadku, kdy > 20 lidí bude jeden den bez práce, se Vám priority možná prohodí. Pokud ovšem nebudete Vy sám prohozen oknem (vtip).
-
Podlož to dokumentem, do té doby je to jen FUD.
-
Podlož to dokumentem, do té doby je to jen FUD.
Je to skusenost a je na kazdom, ako s nou nalozi. Ja hovorim - bez zaruky LTO5 a LTO6 nemiesat. Bez zaruky by ma to stalo ma to uz desiatky mechanik.
-
A v tomto bodě se podle mě prostě mýlíte a převládá ve Vás IT odborník nad IT manažerem. Po první ztrátě dat, nebo po prvním výpadku, kdy > 20 lidí bude jeden den bez práce, se Vám priority možná prohodí. Pokud ovšem nebudete Vy sám prohozen oknem (vtip).
To asi těžko, data jsou ve dvou oddělených budovách na discích přístupná okamžitě, pásky jsou v nehořlavém trezoru. Až ta fabrika shoří tak, že nebudou data, budu propuštěn z důvodu "zrušení pracovního místa". Mimo to - což je čistě manažerská záležitost - vše je v souladu s oficiálně schválenou směrnicí podepsanou ředitelem firmy.
Jedna velmi velká firma v ČR "zálohuje" do cloudu, šašci ::) Píšu šašci, protože z důvodu chybného nastavení routeru k zálohování nedocházelo. Nikomu to nevadilo zhruba dva roky.
Jediné, co mi je možné vytknout z manažerského hlediska, je obsese zálohováním.
Mám obsedantně kompulzivní poruchu, pravidelně a to nejméně jednou týdně, obvykle když někdo zkusí otevřít zavirovaný e-mail, začnu mít obsesi, že přijdu o data, proto provedu kompulzi, jinými slovy vytvořím zálohu a uložím jí do lokálního trezoru. Firmu to stojí jisté množství pásek navíc a čistící pásky. S ohledem na plat je to myslím akceptovatelné.
-
Je to skusenost a je na kazdom, ako s nou nalozi. Ja hovorim - bez zaruky LTO5 a LTO6 nemiesat. Bez zaruky by ma to stalo ma to uz desiatky mechanik.
Prostě to byl žvást.
Kdyby to žvást nebyl, výrobce by na to upozornil a vyjmul to ze záruk, které se na mechaniku vztahují.
Případně by bylo možné tyto informace běžně vygooglovat. Prostě žvást. Hm.
-
To asi těžko, data jsou ve dvou oddělených budovách na discích přístupná okamžitě, pásky jsou v nehořlavém trezoru. Až ta fabrika shoří tak, že nebudou data, budu propuštěn z důvodu "zrušení pracovního místa". Mimo to - což je čistě manažerská záležitost - vše je v souladu s oficiálně schválenou směrnicí podepsanou ředitelem firmy.
Jedna velmi velká firma v ČR "zálohuje" do cloudu, šašci ::) Píšu šašci, protože z důvodu chybného nastavení routeru k zálohování nedocházelo. Nikomu to nevadilo zhruba dva roky.
Jediné, co mi je možné vytknout z manažerského hlediska, je obsese zálohováním.
Mám obsedantně kompulzivní poruchu, pravidelně a to nejméně jednou týdně, obvykle když někdo zkusí otevřít zavirovaný e-mail, začnu mít obsesi, že přijdu o data, proto provedu kompulzi, jinými slovy vytvořím zálohu a uložím jí do lokálního trezoru. Firmu to stojí jisté množství pásek navíc a čistící pásky. S ohledem na plat je to myslím akceptovatelné.
Pletete hrušky a jabka. Pokud někomu selhalo zálohování, a nevěděl o tom, je už lhostejno, jestli to bylo do cloudu, na disky, na RDX nebo na páskovou knihovnu. Hlavní příčinou je nenastavený reporting a monitoring a kontroly. To jsou minimálně tři selhání v řadě.
Těžko mě přesvědčíte, že je lepší mít IT-cvoka, co zálohuje ručně - byť dobře - oproti dobře nastavenému systému a procesům kontroly. To je jako kdybyste mě přesvědčoval, že auto s karburátorem a bez ABS bylo lepší, než současná auta. Možná tak na cenu údržby a na možnost oprav svépomocí, ale určitě ne na bezpečnost a celkovou spolehlivost.
Nabývám přesvědčení, že ve své práci tvoříte řetězec závislostí na sobě - to samozřejmě umí každý, kdo rozumí technice.
-
Ta věc na mně závislá není.
Jinak už jsem viděl požár, kde to blaflo všechno a zmizela celá serverovna.
Jestli tam byla nebo nebyla pásková knihovna nevím, ale kdyby byla, shořela by také.
Z mého pohledu, z toho co píšete vidím následující:
- Zálohy umístěné v serverovně, pokud dojde k rozsáhlému požáru, jsou ztraceny všechny zálohy a trocha hasiva uhasí leda doutnající zdroj serveru
- Není tam kontrola, nikomu nepředáváte pásky, nikdo vlastně neví, jestli zálohy běží
- Špatný manažerský úsudek (peníze nahradí dobrý systém)
- Nemožnost provést nezávislou historickou kontrolu, snaha problémy zametat pod koberec, případné selhání svést na chybu knihovny
- Neseznámení vedení firmy s plánem zálohování, nevidím schválení vedením firmy s plánem zálohování
- Atd, atd....
Pokud na sobě chceme hledat hnidy, můžeme pokračovat ve Vámi nastaveném agresivním tónu "jste špatný manažer".
-
Pokud na sobě chceme hledat hnidy, můžeme pokračovat ve Vámi nastaveném agresivním tónu "jste špatný manažer".
Kdepak, to byl jen můj subjektivní názor, vysvětlil jsem, proč bych to já takto nedělal. Snažil bych se, za cenu dražšího řešení, eliminovat ještě několik rizik navíc. A to v konkrétním případě, kdy by na tom záviselo 20+ uživatelů a jejich provoz.
U menších řešení bych naopak zvažoval nebabrat se s páskou a zvážit jiné alternativy, aby zálohování nevytvářelo tak velký tlak na IT-pracovníka, který má svých starostí i bez toho dost.
V případě všeobecně (kancelářsky) zaměřeného podniku by nemusel dobře fungovat Váš klíč selekce souborů (exkluze videí a velkých souborů), a vrtalo by mi hlavou, jak uhlídat, kdy ho budu muset změnit. V případě výrobního podniku bez marketingového oddělení (které produkuje důležité velké soubory i videa) si to asi dovolit můžete, protože můžete předpokládat, že hlavní data jsou maily, office dokumenty, výkresy a definice pro CNC.
Je takto shrnutá teze přijatelnější, než "jste špatný manažer"?
-
Je to skusenost a je na kazdom, ako s nou nalozi. Ja hovorim - bez zaruky LTO5 a LTO6 nemiesat. Bez zaruky by ma to stalo ma to uz desiatky mechanik.
Prostě to byl žvást.
Kdyby to žvást nebyl, výrobce by na to upozornil a vyjmul to ze záruk, které se na mechaniku vztahují.
Případně by bylo možné tyto informace běžně vygooglovat. Prostě žvást. Hm.
Takový výrobce by ani nemohl mít na své mechanice logo LTO, ani ty pásky. Protože specka LTO _vyžaduje_, aby bylo možné bez problémů číst média z posledních tří generací (dnes tedy LTO-5, 6, 7) a zapisovat na média z posledních dvou generací (dnes LTO-6, 7). To je jedna z vlastností, která vedla k tomu, že se LTO tak dobře prosadilo - zákazníci mají jistotu, že vývoj bude kontinuální a že jim jeden krásný den nezbude jen spousta pásek, rozbitá mechanika a počítače, které již staré mechaniky nezvládají (třeba se úplně změní interface, nebudou drivery atd.)
Jinak rozdíly mezi LTO-6 a LTO-7 páskami jsou, ale dost minimální - jiná délka, odlišná tloušťka, ale matroš stejný, tak kde je nějaký šmirgl?
-
diskuzi čtu se zájmem, ale už to vypadá jen na honění trika.
Záloha na pásky je v současnosti jediný plošně nasaditelný způsob jak uchovat dlouhodobě data pro archivaci/disaster recovery. Pokud firma chce mít data i za deset a více let, musí to dávat na pásky.
V ČR pásky používají všechny velké banky (netuším jak to má třeba řešení sberbank a další exoti), operátoři, velké průmyslové podniky (Škoda, ČEZ atd. atd.).
Není důležité jaké množství dat potřebuji zálohovat, jen chce počítat s tím, že cena za uložený TB na pásce exponenciálně klesá s množstvím dat. Znám ale podniky, kde zálohují stovky GB na pásky, jo jde to, stojí je to víc, ale přednostnosti jsou shodné.
-
Jinak rozdíly mezi LTO-6 a LTO-7 páskami jsou, ale dost minimální - jiná délka, odlišná tloušťka, ale matroš stejný, tak kde je nějaký šmirgl?
Prielom bol medzi LTO-5 a LTO-6. Niektore LTO-5 pasky su drsnejsie (problem sme nemali len my: http://www.backupcentral.com/forum/6/210027 http://www.reduser.net/forum/showthread.php?62329-Important-LTO-5-Media-Warning) a aspon nase LTO-5 hlavy pouzivaju materialy, ktore s tym vydrzia dlho. To neplati u LTO-6 a LTO-7 hlav pri praci s LTO-5 paskou.
LTO-6 a LTO-7 v nasich testoch spolu fungovali spravne.
Takový výrobce by ani nemohl mít na své mechanice logo LTO, ani ty pásky. Protože specka LTO _vyžaduje_, aby bylo možné bez problémů číst média z posledních tří generací (dnes tedy LTO-5, 6, 7) a zapisovat na média z posledních dvou generací (dnes LTO-6, 7). To je jedna z vlastností, která vedla k tomu, že se LTO tak dobře prosadilo - zákazníci mají jistotu, že vývoj bude kontinuální a že jim jeden krásný den nezbude jen spousta pásek, rozbitá mechanika a počítače, které již staré mechaniky nezvládají (třeba se úplně změní interface, nebudou drivery atd.)
Citanie a zapis funguju ako je predpisane, akurat sa hlavy zacnu rychlejsie kazit.
-
kde je nějaký šmirgl?
Já si myslím, že to koumák poplet a zaměnil používání čistících pásek pro první generaci s generací šestou.
Čistící pásky jsou totiž skutečně velmi mírně zbrazivní, ostatně musí z hlavy odstranit případné nečistoty.
Použití nevhodné čistící pásky by měl zabránit čip (každá páska obsahuje samotnou magnetickou pásku i "RFID čip"(sorry za nepřesnost).) Pokud se páska neidentifikuje jako korektní typ čistící pásky, neměla by se vůbec načíst, což je teorie, praxe je taková, že jsem v nouzi vyčistil LTO4 mechaniku čistítí páskou certifikovanou jen pro LTO1/2/3. Věřím, že tohle jedno vyčištění mechanice neublížilo, ale použití nevhodných čistítích pásek by mohlo mechaniku - z dlouhodobého hlediska zničit.
Koumák si to mohl splést i s životností médií, kdy médium nižší řady může vykazovat dřívější opotřebení v případě použití v mechanice nižší řady. Podle druhu LTO média má páska vydržet CCA!! (různé dle generace) asi 250 plných průchodů, tj. 250 plných čtení, 250 plných zápisů, 1 zápis a 254 čtení, 249 zápisů a 1 čtení...atd. Tento parametr v případě použití médií nižší řady v mechanice vyšší řady není garantován. Možná kvůli jinému mechanickému namáhání pásky. Ale dnes, kdy je většina pásek zapsána jen jednou a nikdy není přečtena, protože pro denní zálohování a obnovu jsou dostupné lepší způsoby, to asi nehraje roli. Je fakt, že pokud bych měl sadu pásek, které točím denně, zvolil bych pásky stejné generace a po roce/dvou je vyměnit, páska dá za tu dobu nějakých 80-90 cyklů, to je málo s ohledem na životnost pásky, ale ...
A ušetřit stovku?
https://www.mironet.cz/hp-ultrium-625-tb-lto6-data-tape+dp227704/ (https://www.mironet.cz/hp-ultrium-625-tb-lto6-data-tape+dp227704/)
Já tam vidím tedy jiný rozdíl než ušetřit stovku:
https://www.ab-com.cz/sony-lto-ultrium-7-6tb-record-cap-ltx6000gn-_d1311205.html (https://www.ab-com.cz/sony-lto-ultrium-7-6tb-record-cap-ltx6000gn-_d1311205.html)
Minimálně první rok-dva se někomu může vyplatit používat LTO6 média místo LTO7.
PS: Kompatibilita je -1 generace RW, -2 generace R
-
Co říkáš, je pořád blábol.
Problém BYLA média MAXEL v roce 2011.
Alespoň už víme, odkud se ten blábol vzal.
Jen pro informaci, blíží se rok 2018.
-
Co říkáš, je pořád blábol.
Problém BYLA média MAXEL v roce 2011.
Alespoň už víme, odkud se ten blábol vzal.
Precitaj si aj druhy odkaz. HP hovori "Kupujte HP/Maxell, ostatne pasky nicia hlavy" a IBM hovori "Kupujte IBM/Fuji, ostatne pasky nicia hlavy". Kazdy hovori, ze mas pouzivat jeho pasky a nestane sa to pri rovnakej generacii hlavy. Novsia hlava je citlivejsia a nicia ju obidve LTO5.
Jen pro informaci, blíží se rok 2018.
V praci ocakavame, ze dnes dokazeme obnovit aj zalohy z roku 2011 z LTO5. Ty to ocividne nekacas. Kolko je teda podla teba planovana vydrz pasky?
Kdyby to žvást nebyl, výrobce by na to upozornil a vyjmul to ze záruk, které se na mechaniku vztahují.
Ukaz mi jedno oficialne upozornenie na niektore pasky a vynatie zo zaruk. Nepodrezu si pod sebou konar, ze ich mechaniky nezvladnu dlhodobo citat certifikovane pasky.
-
Plácl jsi blábol a snažíš se ho obhájit, diskuse s tebou postrádá smysl.
-
Plácl jsi blábol a snažíš se ho obhájit, diskuse s tebou postrádá smysl.
Pane Milfausi, nevím, jak je to s páskami a opotřebováváním mechaniky - zatím jsem vždy měl stejný level mechaniky i kazet. Ale co vím jistě je, že jste to Vy, kdo v diskusi má jeden jediný správný názor a názory všech ostatních jsou zbytečné, nebo bláboly.
Myslím, že většina lidí stejně používá kazety nejvyššího podporovaného levelu, a neuškodí, že si přečtou, že existuje přinejmenším podezření, že využívání zpětné kompatibility může mít negativní důsledky. Je pravda, že parametry jakosti (výdrže) jsou garantovány vždy v odpovídajícím levelu LTO - tedy na tomto postřehu něco být může.
-
Ale co vím jistě je, že jste to Vy, kdo v diskusi má jeden jediný správný názor a názory všech ostatních jsou zbytečné, nebo bláboly.
Já si zatím všiml jediného a sice že vy se snažíte na ostatní házet špínu stylem "jsi špatný manažer".
To jsem viděl u jednoho ubožáka z Prahy, který si hrál na big bosse a přitom okrádal zaměstnavatele braním provizí z nevýhodných zakázek. Tací lidé se považují za světáky a otřelé manažery. No. Ať tak nebo tak, váš názor po vašich opakovaných výpadech mi je u (_._) a považuji Vás za chudáka. AAA něco plácl a snažil se to obhájit, plácnutí bylo podložené špatně vysvětlenou zkušeností s medii Maxell, je to pochopitelné, že se člověk snaží obhájit i když obhájit neobhajitelné je prostě volovina. Ve Vašem případě vidím jen nafoukanost, aroganci a hloupost. Nic, co by mě obohatilo.
-
Tak tato debata o taru je celkem bezpředmětná... tar je udělanej přesně pro potřeby pásek (Tape ARchiver) a pásky jsou už x desítek let pořád stejný.
Pásky sú rovnaké, len objemy dát, súborové systémy, predstavy managerov, sieťové infraštruktúry firiem, hrozby straty dát či zakryptovania ..... sa zmenili.
-
Pásky sú rovnaké, len objemy dát,
Irelevantní - použitím nějakého kanónu místo taru se objem nezmenší.
súborové systémy
Irelevantní - filesystémy systémů, na kterých tar běží, umí docela dobře. A i kdyby neuměl, dá se zkombinovat s libovolným nástrojem třeba typu fsarchiver. Narozdíl od kanónu, kde to může být problém.
predstavy managerov
Ok. Manažer může mít představu, že když za něco vyplázne stovky tisíc, tak je automaticky v bezpečí. Ale to se nejspíš nezměnilo, spíš to bylo vždycky.
, sieťové infraštruktúry firiem,
Irelevantní. Tar běží na jednom konkrétním systému, síťová infrastruktura je mu ukradená. Potřebuje se případně jenom dobouchat na úložiště, což ten kanón za stovky tisíc musí taky. Data se nijak magicky do cíle nedostanou.
hrozby straty dát
Hrozba ztráty dat je odjakživa stejná. Prostě se data ztratí :)
či zakryptovania ..... sa zmenili.
To je pravda, to je nová hrozba. Akorát nevím, v jakém smyslu jí kanón čelí líp než tar.
---
Když už bych chtěl řešením s tarem+skripty něco vyčítat, tak možná horší přehlednost a auditovatelnost. Ale ten systém, o kterém tady byla řeč, zjevně splňuje požadavky na něj kladený, takže je zjevně fit for purpose.
-
mohl by mi prosim nekdo strucne odpovedet jak je to ze zapisem na pasku (prepsani puvodniho, pokracovani za posledni zaznam) ?
dejme tomu ze mam prazdnou/smazanou kazetu a pres ssh na ni zapisu data:
tar zcvf - Pictures | ssh root@192.168.6.2 "cat > /dev/st0"
kazetu NEpretocim a druhy den udelam:
tar zcvf - Documents | ssh root@192.168.6.2 "cat > /dev/st0"
mel by se prepsat to puvodni? ocekaval bych ze ne
diky
-
Já už se tu do té diskuse nechtěl pouštět, ale asi by to chtělo ještě pár věcí uvést.
Pásky byly, jsou a budou vždy dosti neohrabané.
SSD se dá přirovnat k hubenému ťunťovi, co rejdí na městě na kole.
HD se dá přirovnat k tlustému a línému řidiči kamionu.
Pásku můžete srovnat se skládkou.
Pásková knihovna je pěkná věc, ale v zásadě to je jen jakési "kolečkové křeslo", bagr na skládce.
Když to jde, existuje celá řada lepších řešení.
Někomu může vyhovňovat zálohování do cloudu (nemám rád).
Jiný zálohuje na disky (do doby, než mu upadne disk s tou nejdůležitější zálohou).
Další zálohuje na iSCSI (do doby, než se na server dostane vir a iSCSI a další úložiště mu zašifruje).
IT má být líný natolik, aby všechno fungovalo a on si mohl čučet do monitoru a trollit na rootu nebo si programovat svůj "crack_3Dsexvilla.exe".
Právě poslední věc by mohla pásky z celého procesu vyloučit, ale nevylučuje.
Pásky se dají jednoduše nastavit tak, že o nich týden nebo čtrnáct dní nevíte a pak je odnesete pryč.
Nároky na bezpečnost dat stanovují různé požadavky, mimo jiné, aby byly zálohy na různých místech a tím se zajistili jakási vyšší bezpečnost záloh. Pásku prostě jednou za týden dáte někomu - pro tento účel vhodnému - a děj se vůle boží.
Pokud se něco semele a on ty zálohy ztratí, je to víc jeho problém než Váš, pokud byl tímto účelem pověřen (většinou HR/Finanční manažer/sám ředitel), je to stejné, jako kdyby se mu ztratily peníze nebo jakýkoliv jiný majetek.
Já tu pásky nikdy nehájil z hlediska "primární zálohy", ale jako dlouhodobé archivační médium.
Data mám na discích (iSCSI má svoje výhody / disk připojený přes SAMBA má menší) a když potřebuji něco obnovit, primárně sahám na nejdostupnější kopii, což je většinou Shadow Copy, pak ty iSCSI a o páskách nevím.
Pásky mi zajišťují to, že mám data v geograficky odlišné lokalitě (pokud nemůžete šupnout iSCSI mimo), mám důkazy o tom, že se zálohy vytváří (dokument o předání), mám důkaz o tom, že se i kontrolují (čtvrtletní audit) a mám v podstatě jistotu, že data mám. I kdyby blesk uhodil přímo do budovy a kabelem od antény (do některých serveroven jsou svedené antény od poskytovatele) sjel přímo do serverovny, kde by nadělal paseku, mám zálohu. Protože jí má finanční ředitel.
Jak to, že není záloha?
Když nebude záloha, je to průser můj i finančního ředitele.
Vymění se IT a finanční ředitel přiběhne a bude chtít pásku, tím je zajištěno, že se zálohy provádí i po výměně IT.
Přijde audit a já mám papír o tom, že se zálohy vytváří (předávám je proti podpisu) a mám zajištěnou jejich bezpečnost, splnil jsem všechny požadavky na zálohování kladené. (Pásky se mají šifrovat, to je důležité, protože by z firmy neměly odcházet nezašifrovaná data!!!)
V Automotive jsou podobné požadavky zcela běžné.
Zkoumá se, jestli budou zálohy i v případě, že se stane něco v serverovně (požár/vytopení/vykradení).
Proto tohle páskové knihovny rád:
- Je zjevné, že se zálohy provádí?
- Mohu dokázat, že se zálohy opravdu provádí? Nemyslím papírem, který si sám vytisknu a pěti tužkama podepíšu?
- Probíhá tam křížová kontrola? (Dám pásku finančnímu řediteli vs Bzzzzz Bzzz mašina hučí, ale mlčí.)
- Je tam dodržená kontinuita, tj. když mě někdo na hodinu vyhodí, budou zálohy probíhat pořád?
- Je tam sdílená odpovědnost? Data bývají nejcennější firemní majetek, selhání jednoho člověka se musí vyloučit.
Samozřejmě, při auditu se dokazuje daleko víc věcí, ale výše je uvedený základ, který MUSÍ být dodržen - pokud máte firmu, pro kterou pracujete, alespoň trochu rádi.
Hlavně, ve firmě se děje nějaká velká akce, začíná vánoční/letní odstávka, proběhl audit, probíhá roční uzávěrka.
Vy přijdete do kanceláře ředitele a řeknete "Udělal jsem mimořádnou zálohu, tady na té pásce jsou data, dáme to do trezoru."
To nemá smysl dělat desetkrát ročně, ale jednou ročně to je výhodné.
Vedení si zvykne a při podobné události přijdou sami.
Zvyšuje to důvěru, je to takové malé "politikaření", ale čím vyšší budete mít důvěru, tím snáz dostanete peníze na to, co je potřeba. Malými kroky, kdy chráníte firmu, kdy se staráte o to, aby důvěra ve vás byla vysoká, posilujete svojí pozici.
Výhodné je to i v tom, že ty zálohy prostě máte.
-
dejme tomu ze mam prazdnou/smazanou kazetu a pres ssh na ni zapisu data:
tar zcvf - Pictures | ssh root@192.168.6.2 "cat > /dev/st0"
kazetu NEpretocim a druhy den udelam:
tar zcvf - Documents | ssh root@192.168.6.2 "cat > /dev/st0"
Nepřečetl sis moje posty.
Používáš zařízení rewind.
-
Jinak ve zkratce, po připojení pásky se "vlastně" objeví DVĚ zařízení.
Například st0 / nst0 a rozdíl v nich je ten, že zatímco první zařízení provede rewind na začátek pásky, druhé prostě skončí na daném místě.
Normálně by se tě zeptal, jestli nejsi trochu blbej, ale asi by to nemělo smysl viď. Ty bys řekl, že blbej nejsi a zeptal se, proč se ti to zařízení st přetáčí. ...se bojím.
Zkus si přečíst, moje posty i ten tutorial.
Doplním, že netuším, jestli ten tvůj bastl vytvoří správně EOF.
SSH je super, ale rychlost bývá dosti ořezená, což nemusí pásce vůbec vyhovňovat, páska potřebuje konstantní tok dat, tohle může data přikapávat dost pomalu a mechanika i páska budou trpět.
-
Nepřečetl sis moje posty.
Používáš zařízení rewind.
nenasel jsem nic co by mi na tento dotaz odpovedelo, a pokud je opravdu takovy problem mi strucne odpovedet, tak vubec nechapu k cemu toto forum je
-
vubec nechapu k cemu toto forum je
Nojo, to jsem si všiml :P
Víš, kdybych to nepsal ve dvou předchozích postech (někde na první a třetí stránce viz citát), tak bych ti rád odpověděl.
Jenže takhle to dráždí, v tom postu je to velmi dobře vysvětlené, v tom tutorialu tak a ty se na to stejně ptáš.
Tak jsi blbej nebo jsi to přehlédl? Četl jsi ten tutorial? Ty to z toho nechápeš?
-
ZAJDAN
Tohle si přečti:
Jinak ve zkratce, po připojení pásky se "vlastně" objeví DVĚ zařízení.
Například st0 / nst0 a rozdíl v nich je ten, že zatímco první zařízení provede rewind na začátek pásky, druhé prostě skončí na daném místě.
Normálně by se tě zeptal, jestli nejsi trochu blbej, ale asi by to nemělo smysl viď. Ty bys řekl, že blbej nejsi a zeptal se, proč se ti to zařízení st přetáčí. ...se bojím.
Zkus si přečíst, moje posty i ten tutorial.
Doplním, že netuším, jestli ten tvůj bastl vytvoří správně EOF.
SSH je super, ale rychlost bývá dosti ořezená, což nemusí pásce vůbec vyhovňovat, páska potřebuje konstantní tok dat, tohle může data přikapávat dost pomalu a mechanika i páska budou trpět.
Pak si přečti ty tutorialy a bude ti to myslím naprosto jasné.
-
prehlidl jsem ten tutorial...uz to ctu...dozvedel jsem se, ze musim za kazdej zaznam zapsat znacku neboli ten EOF a dalsi zaznam zapsat za to jinak to prepise ty puvodni...
diky
-
chapu to tedy dobre ze pokud:
-zapisu na pasku data a nepridam EOF -> paska zustane na pozici a zacne se pretacet na zacatek az pri dalsim zapisu(prepise puvodni)
-zapisu na pasku data a pridam EOF -> paska zustane na pozici a zacne se pretacet na zacatek az pri dalsim zapisu a dle potreby pretoci na potrebnou znacku
-
Pokud budeš chtít na pásku zapisovat DD a ne přímo TAR/MT, tak tam ten EOF budeš muset ASI vytvořit.
Nejsem si jistý, nemyslím si, že DD ten EOF vytváří.
Tohle DD vymaže pásku rychle (smaže identifikátor):
dd if=/dev/zero of=/dev/st0 bs=512 count=1
Doplním, že názvy z st/ns se musíš upravit podle toho, co chceš s páskou dělat.
Inspirovat se můžeš třeba tady.
*** tar
tar -czf /dev/st0 /mnt/paska
tar -xzf /dev/st0
*** mt eject
mt -f /dev/st0 offline
mt -f /dev/st0 eject
*** mt rewind
mt -f /dev/st0 rewind
*** mt erase
mt -f /dev/st0 erase
*** mt status
mt -f /dev/st0 status
*** mt eof
mt weof
mt -f /dev/st0 eof
Najdi konec dat, kde končí poslední data
mt -f /dev/nst0 eod(b)
Předchozí záznam
# mt -f /dev/nst0 bsfm 1(c)
Následující záznam
# mt -f /dev/nst0 fsf 1
Když ti něco nepůjde a nebudu mít pocit, že jsem ti to už srozumitelně řekl, rád ti poradím ;D
-
chapu to tedy dobre ze pokud:
-zapisu na pasku data a nepridam EOF -> paska zustane na pozici a zacne se pretacet na zacatek az pri dalsim zapisu(prepise puvodni)
-zapisu na pasku data a pridam EOF -> paska zustane na pozici a zacne se pretacet na zacatek az pri dalsim zapisu a dle potreby pretoci na potrebnou znacku
Přetáčení ovlivňuje to, jestli jsi použil zařízení st nebo nst.
Páska je reprezentovaná vždy ZÁROVEŇ zařízením st a nst, tj. páska 0 je zároveň zařízení st0 i nst0, podle toho, jestli použiješ zařízení st0 nebo nst0 se páska buď po dojetí přetočí na začátek nebo zůstane stát tam, kde skončila.
EOF je identifikátor, něco jako návěstí (asi není vhodné přirovnání), které říká, tady končí jeden záznam a začíná druhý, pokud ten EOF nevytvoříš, těžko říct, co z toho DD vytvoří. Minimálně se nebudeš moct posunout mezi záznamy (posouváš se po značkách EOF), ale spíš ti z toho bez EOF vznikne jeden velký blob, nebo taky ne. (Příkaz DD pro zápis na pásku opravdu nemám zmáknutý). Zkus místo DD používat TAR, je to určitě pohodlnější.
-
Přetáčení ovlivňuje to, jestli jsi použil zařízení st nebo nst.
Páska je reprezentovaná vždy ZÁROVEŇ zařízením st a nst, tj. páska 0 je zároveň zařízení st0 i nst0, podle toho, jestli použiješ zařízení st0 nebo nst0 se páska buď po dojetí přetočí na začátek nebo zůstane stát tam, kde skončila.
EOF je identifikátor, něco jako návěstí (asi není vhodné přirovnání), které říká, tady končí jeden záznam a začíná druhý, pokud ten EOF nevytvoříš, těžko říct, co z toho DD vytvoří. Minimálně se nebudeš moct posunout mezi záznamy (posouváš se po značkách EOF), ale spíš ti z toho bez EOF vznikne jeden velký blob, nebo taky ne. (Příkaz DD pro zápis na pásku opravdu nemám zmáknutý). Zkus místo DD používat TAR, je to určitě pohodlnější.
diky za peknou odpoved...
pouzil jen /dev/st0
zatim posilam data na vzdalenou pasku pres ssh s kombinaci cat
tar zcvf - Pictures/* | ssh root@192.168.6.2 "cat > /dev/st0"
a tady pro mne vznika problem, ze pres cat nebude mozne predat informaci eof/eom
nechci ted instalovat zadne mega reseni typu bacula/bareos a tak mi zbyvaji dve reseni, a to bud vyhradit na stroji kde je pripnuta paska velky disk...na nej nahrnout vsechna vzdalena data a pak lokalne pres mt zapsat na pasku, nebo najit zpusob jak informaci o znackach predat pres ssh
-
SSH je super, ale rychlost bývá dosti ořezená, což nemusí pásce vůbec vyhovňovat, páska potřebuje konstantní tok dat, tohle může data přikapávat dost pomalu a mechanika i páska budou trpět.
Jakou máš pásku?
LTO2? LTO5? LTO6?
Tady máš porovnání mechanik:
http://www.maximummidrange.com/blog/lto-tape-comparison-charts/1883 (http://www.maximummidrange.com/blog/lto-tape-comparison-charts/1883)
Pokud to tam nejsi schopný cpát rychleji, než je rychlost pásky, pásková mechanika se bude zastavovat a roztáčet, zastaví se a roztočí, zastaví se a roztočí = něco zničíš a nebude to trvat asi moc dlouho.
-
Jakou máš pásku?
LTO2? LTO5? LTO6?
Pokud to tam nejsi schopný cpát rychleji, než je rychlost pásky, pásková mechanika se bude zastavovat a roztáčet, zastaví se a roztočí, zastaví se a roztočí = něco zničíš a nebude to trvat asi moc dlouho.
TANDBERG LTO3 Ultrium
-
(Pásky se mají šifrovat, to je důležité, protože by z firmy neměly odcházet nezašifrovaná data!!!)
Kde je uložen klíč?
-
TANDBERG LTO3 Ultrium
To je dobrá páska, dokonce vím o někom, kdo by ti mohl prodat nepoužité pásky po kilču, můžu mu přeposlat tvůj e-mail.
Nicméně, tahle páska umí ukládat rychlostí cca 80MB/s
https://cs.wikipedia.org/wiki/Linear_Tape_Open
A to si myslím, že na tu mašinu přes SSH neprotlačíš.
Lepší by bylo to tam nakopírovat, což není problém (ta páska není tak velká, takové disky se válí všude možně).
A pak přes SSH pustit příkaz, který to na pásku přehrne.
Něco jako: plink root@mašina -m local_script.sh nebo jinak, to už je na tobě.
Když se ti bude chtít, můžeš to udělat tak, že si chybové kódy přeneseš na mašinu, ze které to pouštíš.
(Argumenty se dají posílat tam i zpět.)
Je s tím trochu víc drbání, ale uvidíš, jestli to všechno doběhlo, jak jsi očekával.
Samozřejmě to chce udělat i skript na ověření zálohy.
No s Baculou bys měl život nejspíš jednodušší.
Záleží na tobě, jestli chceš řešení click+done nebo od toho očekáváš věci, které ti bacula třeba nabídne, ale až po vynaložení stejného úsilí, které dáš do napsaní skriptů.
Mimo to, určitě se hodí, aby ta mašina uměla poslat e-mail v případech kdy:
- plánovač kontroluje, kdy záloha proběhla naposled, pokud neproběhla, měl by začít kňourat (poslat e-mail)
- pokud dojde k chybě, mělo by ti to vygenerovat e-mail
- pokud na tom počítači začne něco zavánět, mělo by ti to poslat e-mail (smart disku, stav SW raidu)
Lidé jsou stvoření líná a pokud chodí e-maily typu "úspěch" začnou to ignorovat.
Proto si myslím, že je lepší logovat především neúspěch, zato relativně intenzivně.
Já mám řešení, že v e-mailu musíš kliknout na odkaz (pustí ack.php), spuštění daného skriptu uklidní server.
(V e-mailu je zeleně napsáno kolik GB šlo na pásku fontem 60 :-D nebo červeně chyba, abych nad tím nemusel přemýšlet.)
...použij Baculu :-D
-
Kde je uložen klíč?
Není tam klíč, je tam jen heslo. Na zálohovací mašině, která je oddělená od zbytku sítě, má ho ředitel i finanční ředitel oba v zalepených obálkách. Jsou lepší možnosti, resp. ono by to šlo udělat o hodně lépe, ale je to good enough.
Pokud by to někdo hacknul, stáhne si data ze serveru a nazdar párky, nemusí se dobývat na zálohovací mašinu.
Je tam splněno "musí zná a musí mít". I když se páska ztratí, bez hesla je k prdu.
Systém klíčů je použitý na počítákách uživatelů, všechny notebooky musí mít bitlocker.
Systém vyžaduje, aby všechna média, která opouští firmu, byla šifrovaná.
No, tak to nejsou, nedá se uhlídat každý Franta, co si přinese a odnese flashku.
Řešením by bylo limitovat připojení USB pro THP pracovníky (ve výrobě to nejde), ale to by řvali a stejně by si mohli poslat data jednoduše e-mailem nebo uploadnout nějakým formulářem třeba na ulož.to (uložto jede přes anonymizéry)...
Určitá úroveň svinčíku je vždycky.
Nezašifrovaná zatoulaná páska by byl pjůser.
Resp. až vejde v platnost GDPR bude zatoulaná páska pjůser i tak...
-
Irelevantní - použitím nějakého kanónu místo taru se objem nezmenší.
Pokud máte dataset o X páskách, je rozdíl, jestli s nimi pracujete nějak inteligentěji (ideálně i s načítáním barcodů), nebo jestli ne. Je rozdíl, jestli se na jednu pásku vešlo X záloh, nebo jestli jedna záloha je na X pásek.
Ok. Manažer může mít představu, že když za něco vyplázne stovky tisíc, tak je automaticky v bezpečí. Ale to se nejspíš nezměnilo, spíš to bylo vždycky.
Manažeři nejsou tak pitomí, jak je prezentujete. Vyvinul se pohled na to, jak se řídí rizika a změnil se poměr ceny technologií (šly dolů) a ceny práce (jde nahoru). Riziky nejsou jen samotné ztráty dat, ale za rizika lze považovat např. i řízení lidských zdrojů, nepřetržitost obchodu, ... A pokud mám koupit něco za XXX tis. Kč, ale uvolnit tím ruce zkušenému IT seniorovi, pak to udělám. Za jedno šetřím jeho čas na smysluplnější práci, za druhé riskuji menší zásah do podnikání, pokud mi tento klíčový člověk odejde.
Irelevantní. Tar běží na jednom konkrétním systému, síťová infrastruktura je mu ukradená. Potřebuje se případně jenom dobouchat na úložiště, což ten kanón za stovky tisíc musí taky. Data se nijak magicky do cíle nedostanou.
Dříve ve firmách běželo X fyzických serverů a možnosti zálohování začínaly tarem a končily nějakými zálohovacími systémy fungujícími na principu agentů. Dnes mají ty samé firmy násobně více virtuálních strojů, protože každý systém si může dovolit ten komfort běžet ve svém prostředí - to situaci zkomplikovalo. Na druhou stranu ale přišla možnost zálohovat kompletní VM a bitové přírůstky na virtuálních discích. To je sakra velká změna v infrastruktuře a v potřebách a možnostech zálohování.
hrozby straty dát
Ani v tom se nedá úplně souhlasit. Jsou situace, kde se hrozba nezměnila - pokud admin dodržuje určité zásady, je chráněný firewallem, obměňuje hardware, má dobře nastavenou retenci záloh... Bohužel, v realitě firmy berou různé (sub)systémy od různých dodavatelů a šetří se na centrální správě. To otevřelo dveře novým hrozbám.
Novým typem hrozby jsou ransomware, které data ničí systematicky, a tak dlouhou dobu, že i běžné provozní zálohy jsou zasaženy. Někdo má schéma zálohování odjakživa dobré, a tato hrozba ho neovlivnila. Někdo rotuje zálohy po pár dnech, a jemu se situace změnila.
---
Když už bych chtěl řešením s tarem+skripty něco vyčítat, tak možná horší přehlednost a auditovatelnost. Ale ten systém, o kterém tady byla řeč, zjevně splňuje požadavky na něj kladený, takže je zjevně fit for purpose.
S tím se dá souhlasit, jen bych ještě doplnil revidovatelnost. Audit je namátková vnější činnost vedoucí k podchycení chyb. Zatímco admin potřebuje interně revidovat nastavení záloh - kontrolovat, jestli zálohuje vše, co má, a s požadovanou retencí dat.
-
...
Abysme si rozuměli: pochopitelně netvrdím, že se nic nezměnilo. Jenom nevidím tak jasnou vazbu mezi "něco se změnilo" a "najednou je na to potřeba koupit kanón".
Jediný příklad za všechny: ano, objem dat roste. Ale podobným tempem roste kapacita pásek. Q.E.D.
Existuje spousta prostředí, kde si umím představit, že "stará řešení" fungují naprosto v pohodě.
-
Není tam klíč, je tam jen heslo. Na zálohovací mašině, která je oddělená od zbytku sítě, má ho ředitel i finanční ředitel oba v zalepených obálkách. Jsou lepší možnosti, resp. ono by to šlo udělat o hodně lépe, ale je to good enough.
Ptal jsem se na to proto, protože problém "jak zabezpečit, aby se k pásce nedostal nikdo nepovolaný" se šifrováním mění na "jak zabezpečit, aby se nikdo nepovolaný nedostal ke klíči" ;)
-
Ptal jsem se na to proto, protože problém "jak zabezpečit, aby se k pásce nedostal nikdo nepovolaný" se šifrováním mění na "jak zabezpečit, aby se nikdo nepovolaný nedostal ke klíči" ;)
Tady se spoléhá na to, že je podstatně jednodušší haxnout server nebo střelit příslušného manažera do kolene, čímž se získá data taky. Čínská špionáž A) zaměstná svého koně u firmy B) haxne server C) koupí celou firmu.
Fakticky to je jen zabezpečení před náhodnou ztrátou pásky.
Když někdo tu pásku najde, k ničemu mu není.
Kolik ajťáků by odolalo tomu, kdyby před něj někdo postavil kufr prašulí "A dones mi kopii disků z firmy!", já bych to se slzou v oku odmítl, ale věřím tomu, že značná část ajťáků ne. Kdyby se to navíc podpořilo nějakým argumentem "vezmi prachy nebo tě udáme za hraní tetrisu v pracovní době", tak odhaduji na 90%.
Přemýšlel jsem nad tím, jestli je to super nebo ne, pořád věřím tomu, že to je good enough.
V NBU se používá(tipuji že pořád) heslo nbusr123 a vedoucí pak sofistikovanější heslo nbadm1234 a jak si žili šťastně a spokojeně.
-
Fakticky to je jen zabezpečení před náhodnou ztrátou pásky.
Ok, to je fér.
Přemýšlel jsem nad tím, jestli je to super nebo ne, pořád věřím tomu, že to je good enough.
Netvrdím, že ne. Jenom mě baví uvažovat nad tím, když člověk někde zavede šifrování, co tím vlastně řeší. Vynoří se pak spousta zajímavých otázek :) Jako třeba "měl by šifrovací klíč uložit někam šifrovaně?" :))
-
Jako třeba "měl by šifrovací klíč uložit někam šifrovaně?" :))
To je možná filozofická otázka.
Já jsem toho názoru (mohu se plést), že záloha slouží především k tomu, aby bylo možné data bez problémů obnovit.
Jinak to jako záloha tak trochu postrádá smyslu.
Pásky se skladují zabezpečeně a u důvěryhodných lidí, tj. nedávají se uklízečce.
Důvěryhodná osoba může mít cestou do banky bouračku a k páskám se mohou dostat nepovolané osoby.
(Jaké je tam riziko zneužití?)
Vůči ztrátě jsou tedy relativně odolné tím, že jsou zaheslované.
I dneska hodně lidí pásky nešifruje.
V jiné firmě jsem viděl, jak IT sypal pásky normálně do směsného odpadu (odkud jsem je pak vybíral, protože LTO5 pásky doma používám). Kdybych byl kujva, tak si můžu stáhnout data, protože nic zálohovaného samozřejmě nebylo.
To si myslím, že je potenciální bezpečnostní problém.
Na druhou stranu, potenciální nutně neznamená skutečný, protože inženýr, který bude ten sběrný odpad s lopatou v ASA prohrabávat, si nevšiml ani té rozčtvrcené ženské a z letargie by ho mohla vytrhnout asi jen zlatá cihla.
-
PS: DOMA se na pásky dají odlejvat přímo truecryptový kontejnery.
Člověk se pak nemusí zabývat tím, jestli se k té pásce dostane někdo cizí.
Osáma Bobik Láďa to říkal.
-
No s Baculou bys měl život nejspíš jednodušší.
Záleží na tobě, jestli chceš řešení click+done nebo od toho očekáváš věci, které ti bacula třeba nabídne, ale až po vynaložení stejného úsilí, které dáš do napsaní skriptů.
Mimo to, určitě se hodí, aby ta mašina uměla poslat e-mail v případech kdy:
- plánovač kontroluje, kdy záloha proběhla naposled, pokud neproběhla, měl by začít kňourat (poslat e-mail)
- pokud dojde k chybě, mělo by ti to vygenerovat e-mail
- pokud na tom počítači začne něco zavánět, mělo by ti to poslat e-mail (smart disku, stav SW raidu)
Lidé jsou stvoření líná a pokud chodí e-maily typu "úspěch" začnou to ignorovat.
Proto si myslím, že je lepší logovat především neúspěch, zato relativně intenzivně.
Já mám řešení, že v e-mailu musíš kliknout na odkaz (pustí ack.php), spuštění daného skriptu uklidní server.
(V e-mailu je zeleně napsáno kolik GB šlo na pásku fontem 60 :-D nebo červeně chyba, abych nad tím nemusel přemýšlet.)
...použij Baculu :-D
ok...pokud se mam tedy zbavit rucni prace tak je potreba GUI..jake doporucujete pro baculu?
-
ok...pokud se mam tedy zbavit rucni prace tak je potreba GUI..jake doporucujete pro baculu?
U Baculy/Bareosu záleží nejvíc na tom, jestli se ti podaří dobře vychytat konfiguraci na tvůj use case. V ideálním případě se ti to podaří stoprocentně a pak žádný GUI nepotřebuješ, nic neřešíš, je to bezúdržbové. CLI je docela dobré (resp. je hrozné, ale dá se na to zvyknout ;) ). Podobně je to i s tím oficiálním GUI klientem: je to děs, ale v ideálním případě ho používáš málo, takže je ti to putna.
Pro Bareos je teď ještě nějaký nový webui, ale nezkoušel jsem - mám vlastní minimalistický webui přesně na to, co potřebuju já :)
-
Kdyby okolo vás šlo nějaký hezký WebGUI, dejte vědět, rád se přiučím.
-
Existuje spousta prostředí, kde si umím představit, že "stará řešení" fungují naprosto v pohodě.
Souhlas.
-
ok...pokud se mam tedy zbavit rucni prace tak je potreba GUI..jake doporucujete pro baculu?
Bacula / bareos mají GUI jen na monitoring, obnovu, a spouštění jobů.
Konfiguraci stejně musíte napsat ručně. Poté, co napíšete konfiguraci a vše vyzkoušíte, tak uvidíte, že to GUI vlastně ani postrádat nebudete - v ten okamžik už přes bconsole zvládnete všechno.
-
Zdravim diskutujici,
co maji delsi praktickou zkusenosti s LTO mechanikama. Jak jsou na tom s realnou zivotnosti? Je treba se obavat nakupu pouzite mechaniky (konkretne LTO-4). Samozrejme, ze je to kus od kusu, ale predpokladam, ze firmy se toho zbavuji ani ne, ze by mechanika odchazela, ale spis resi prechod na novejsi generaci a zejmena vyssi kapacitu. Je to tak?
-
Kdyby okolo vás šlo nějaký hezký WebGUI, dejte vědět, rád se přiučím.
https://www.bareos.org/en/bareos-webui.html
-
(konkretne LTO-4)
U LTO4 by nemusel být takový problém, samozřejmě to máš kus od kusu, můžeš mít pech, co ti na to mám říct.
Mechanika se dá sehnat okolo šesti tisíc včetně několika pásek, zrovna teď mi někdo jednu nabízel (fakt pěknou sestavu), můžu mu přeposlat e-mail.
Problematická jsou právě LTO5, tenkrát kolísala kvalita pásek, ale hromada lidí kupuje právě sudou generaci.
Druhou, čtvrtou i šestou.
Druhá generace je velmi dobrá a pořídíš jí okolo tisícovky komplet včetně fungl čistící pásky, řadiče (vesměs jsou SCSI) a nějakých LTO2 pásek.
Třetí generace se pohybuje cenou okolo dvou až čtyř tisíc.
Čtvrtá - víc mechanik se prodává v Německu, cena je různá, líp nekupovat to nejlevnější, za cca 200 Euro pořídíš dobrou bez pásek.
-
Presne tak. Kdyz chci neco obnovit, tak si v GUI vyberu server, adresar, datum a SW za me vlozi spravnou pasku do mechaniky a pretoci ji na spravne misto. Predevsim obnova musi byt primocara.
Nechapu jak dneska jeste nekdo muze pouzivat na pasky tar. Navic potrebuju i nejaky scheduler a reporting.
Taky jak jsem si kdysi hrál s TARem, tak při jakékoli chybě jednoho bitu ukončí úlohu a člověk se nedostane k ničemi. Možná se to dá nějak obejít, nevim, nepřišel jsem na to. Spousta těch aplikací asi TAR používá jako spodní vrstvu, ale co je nad tím je důležité :D
Když jsme u toho, měl by někdo tip na nějakou relativně jednoduchou aplikaci, se kterou bych mohl udělat jednorázově trvalou zálohu statických dat a pak třeba jednou za rok přihodil inkrementální? Požaduju od toho, aby to vědělo co je na jaké pásce a řeklo mi kterou případně vložit, v případě poškození části dat to obnovilo aspoň ostatní soubory (a ne že to vyplivne ERROR a nazdar, konec) a samozřejmě záloha probíhala tak, že tam strčim pásku, až se naplní to počká, než vložím další a zmáčknu Enter, a tak dokola a tak dále.
Koukal jsem, že toho existuje dost, např. Mondo by mělo pásky umět. Ale ideálně něco, co zvládne člověk, co není zrovna T1 admin, bez šílených konfigurací…takže určitě ne bakula :D Skutečně mi stačí že to bude umět pokyn tenhle adresář chci zapsat a pak už jen měnit pásky.
Mám dvě staré (ještě DDS/DAT) mechaniky, dá se to najít dneska v podstatě v kontejneru a média taky máte za pár korun. Pokud potřebujete sem-tam něco spolehlivě odarchivovat a nechat někde válet příštích 5 let, tak na to jsou IMHO pásky ideální (ostatně, jak již bylo zmíněno, Tape ARchiver) a pokud vám nevadí takhle jednou ročně povyměňovat za týden pár tuctů pásek, tak se můžete dobrat klidně k terabajtům kapacity za naprosto směšné drobné, není třeba utíkat do kšeftu hned pro novou Ultrium mechaniku. Ostatně, kdyby si chtěl někdo hrát, máme ve skladu právě jakousi knihovnu co je v ní 800 GB (nemá to všechny pásky v největší kapacitě, když se to osadí, tak dává tuším 1,2 TB). Nezkoušel sem, ale vypadá, že jí nic není :)
Aktuálně mám v těch DDR3 a DAT40 něco mezi 2 a 3 TB, nevim přesně, a ve skladu dalšího aspoň půl tera v dalších páskách :D Akorát to nějak roky vázne na to, že jsem právě nepohnul s tím, čím na ně něco zapsat, no :D
-
Akorát to nějak roky vázne na to, že jsem právě nepohnul s tím, čím na ně něco zapsat, no :D
Tak zkus nějaký nový Ultrium, sice stojí ~50+K, ale zato tam můžeš kopírovat přetažením v Průzkumníkovi. ;D
-
Má to balík pro Debian?
-
Mám tu SDLT 160GB/300GB komprimovaně, asi 10 pásek čistící kazetu atd.
Je to lepší než ty malé 4GB mrňky.
Za něco to rád vyměním, nikde nepoužívám SDLT.
LTO i SDLT funguje v debianu bez problémů.
Stačí nastavit konfiguraci.
-
Mám tu SDLT 160GB/300GB komprimovaně, asi 10 pásek čistící kazetu atd.
Je to lepší než ty malé 4GB mrňky.
Za něco to rád vyměním, nikde nepoužívám SDLT.
LTO i SDLT funguje v debianu bez problémů.
Stačí nastavit konfiguraci.
Co za to, pripadne co pijes?
-
Co za to, pripadne co pijes?
Hadr pětikilo SATA/SAS v cajku, případně dvě 300 GB SAS 3.5" a drobné budu mít na poštovné.
-
a drobné budu mít na poštovné.
Aby to bylo zřejmé.
Myslím o těch drobných 100GB víc v SAS než co chci v SATA ;)
-
(konkretne LTO-4)
U LTO4 by nemusel být takový problém, samozřejmě to máš kus od kusu, můžeš mít pech, co ti na to mám říct.
Mechanika se dá sehnat okolo šesti tisíc včetně několika pásek, zrovna teď mi někdo jednu nabízel (fakt pěknou sestavu), můžu mu přeposlat e-mail.
To by bylo super, diky - pisoar (na) seznam.cz - je to email na spamy, ale obcas ho ctu.
-
Poslal jsem mu e-mail, uvidíme, kdy se ti ozve.
-
Milfausi...jeste bych Te poprosil o upresneni...neni mi jasne zda tu EOF zancku pridavam spravne:
mt -f /dev/st0 erase
mt -f /dev/st0 rewind
tar cvf /dev/st0 /mnt/BACKUP
mt -f /dev/st0 eof
#pridani dalsich dat za stavajici
mt -f /dev/st0 eod
tar cvf /dev/st0 /mnt/BACKUP
mt -f /dev/st0 eof
-
Milfausi...ještě bych tě poprosil o upřesnění, proč ten člověk pořád používá rewind zařízení tam, kde má použít no-rewind?
-
Milfausi...ještě bych tě poprosil o upřesnění, proč ten člověk pořád používá rewind zařízení tam, kde má použít no-rewind?
General Commands Manual MT(1)
NAME
mt - control magnetic tape drive operation
SYNOPSIS
mt [-V] [-f device] [--file=device] [--rsh-command=command] [--version] operation [count]
DESCRIPTION
This manual page documents the GNU version of mt. mt performs the given operation, which must be one of the tape operations listed below, on a
tape drive.
The default tape device to operate on is taken from the file /usr/include/sys/mtio.h when mt is compiled. It can be overridden by giving a
device file name in the environment variable TAPE or by a command line option (see below), which also overrides the environment variable.
The device must be either a character special file or a remote tape drive. To use a tape drive on another machine as the archive, use a filename
that starts with `HOSTNAME:'. The hostname can be preceded by a username and an `@' to access the remote tape drive as that user, if you have
permission to do so (typically an entry in that user's `~/.rhosts' file).
The available operations are listed below. Unique abbreviations are accepted. Not all operations are available on all systems, or work on all
types of tape drives. Some operations optionally take a repeat count, which can be given after the operation name and defaults to 1.
eof, weof
Write count EOF marks at current position.
fsf Forward space count files. The tape is positioned on the first block of the next file.
bsf Backward space count files. The tape is positioned on the first block of the next file.
fsr Forward space count records.
bsr Backward space count records.
bsfm Backward space count file marks. The tape is positioned on the beginning-of-the-tape side of the file mark.
fsfm Forward space count file marks. The tape is positioned on the beginning-of-the-tape side of the file mark.
asf Absolute space to file number count. Equivalent to rewind followed by fsf count.
seek Seek to block number count.
eom Space to the end of the recorded media on the tape (for appending files onto tapes).
rewind Rewind the tape.
offline, rewoffl
Rewind the tape and, if applicable, unload the tape.
status Print status information about the tape unit.
retension
Rewind the tape, then wind it to the end of the reel, then rewind it again.
erase Erase the tape.
mt exits with a status of 0 if the operation succeeded, 1 if the operation or device name given was invalid, or 2 if the operation failed.
nechám si poradit....
man mluví jen o rewind..pripadne mi logicke si pasku pretocit a pak najet na pozadovanou znacku
nebude tim resenim namisto st0 pouzit nst0 ...?
-
mt -f /dev/st0 erase
mt -f /dev/st0 rewind
tar cvf /dev/st0 /mnt/BACKUP
mt -f /dev/st0 eof
Přeložím na kroky:
mt -f /dev/st0 erase ---- smaž pástku a protože je použité zařízení rewind, přetoč jí na začátek
mt -f /dev/st0 rewind ---- přetoč pásku a protože je použité rewind zařízení, přesuň se na začátek
tar cvf /dev/st0 /mnt/BACKUP -- naval to na pásku a protože je použité rewind zařízení, pretoč jí na začátek
mt -f /dev/st0 eof --předchozí operace tě přesunula na začátek pásky (použil jsi rewind st0), takže jsi na začátku a vytvoříš eof
Než se naučíš rozdíl mezi zařízením, které po provedení operace přetočí pásku na začátek (rewind) a které po provedení operace skončí, kde je (norewind), nebudeme se pouštět do žádných větších akcí.
-
Než se naučíš rozdíl mezi zařízením, které po provedení operace přetočí pásku na začátek (rewind) a které po provedení operace skončí, kde je (norewind), nebudeme se pouštět do žádných větších akcí.
:_) díky.....s tím zařízením jsem to naznačil v poslední větě předchozího příspěvku
-
Velice přehledný popis (návod) je zde:
https://www.cyberciti.biz/hardware/unix-linux-basic-tape-management-commands/
-
jaké máte zkušenosti s čistícími kazetami?
jak dlouho trvá čistící proces?
díky
-
Kdyby někdo chtěl, tak právě prodávám LTO4 mechaniku včetně několika LTO4 pásek, box, kabel i řadič.
Nechci za to myslím nijak moc.
https://forum.root.cz/index.php?topic=16423.0 (https://forum.root.cz/index.php?topic=16423.0)
-
Je sice hezké, že filename je obnovený stejně, ale v praxi nic nedohledáte v konzoli, když tam jsou české znaky.
Není s tím žádným problém u systémů, které používají UTF-8. Tj. všechny běžné systémy (u Win se na UTF-8 automaticky převádí).
Databáze "nainstaluj a nestarej se" - taky hezký nápad, ale asi jste ještě u Baculy neřešil nekonzistentní FK.
Ne, to jsem opravdu neřešil - a ani nevím, jak by mohly vzniknout, protože to databáze hlídá sama. Problém může nastat s orphanes a řeší ho příkaz bareos-dbcheck.
Já neříkám, že není k použití. Sám bareos používám ke spokojenosti, ale pokud mám před sebou tazatele - méně zkušeného admina - pak i to vše, co jsem napsal, musí padat na misky vah při výběru řešení.
Vidím to přesně opačně: méně zkušený admin bude zálohovat pár serverů, typicky s jedním, dvěma operačními systémy a na žádné problémy vůbec nenarazí. Nemá pro něj sebemenší smysl investovat do nějaké předražené komerční bestie, která má taky svých problémů dost.
Jedinej problém pro začínajícího admina bude pochopit konfiguraci. To je bez pochyby oříšek, ale to by byl i s čímkoli jiným (stejné síly).
Díky za Vaše postřehy. Bareos je trochu hardcore na nastavení, ale dokumentace je poměrně dobrá a admin něčeho *NIX je na podobné záležitosti docela zvyklý. Bareos používám dokonce na domácí zálohy (mám dokonce i tapeloader, ale ještě jsem ho během 2 měsíců nestihl pořádně nakonfigurovat - je to doma), které jdou zatím tedy na NAS...
-
Vidím to přesně opačně: méně zkušený admin bude zálohovat pár serverů, typicky s jedním, dvěma operačními systémy a na žádné problémy vůbec nenarazí. Nemá pro něj sebemenší smysl investovat do nějaké předražené komerční bestie, která má taky svých problémů dost.
Respektuji Váš názor.
Když se podívám na mzdu admina a cenu hardwaru, nepřijde mi žádné řešení na trhu předražené. Admin v malé firmě má sám na bedrech spoustu úkolů, aby se babral se složitými řešeními (a není nic smutnějšího než write-only záloha). Ve velké firmě se zase uplatní úspory z rozsahu.
Díky za diskusi.
Jistě že mzda dobrého admina nebo dokonce systémového inženýra je docela pořádná položka. Ono dát ale nižší statisíce korun za něco, co umí stejně dobře (nebo i lépe) FOSS Bacula nebo Bareos... to už nějaký ten den práce uhradí. Obecně můžu říct, že vím o několika větších i absolutně minimálních nasazeních Bareos v okolí a neslyšel/ nezažil jsem problém a to ani když se upgradoval hardware nebo operační systém nebo měnilo RAID pole.
Myslím, že když se do dokumentace trochu ponoříte, zjistíte, že Bareos není špatný ani na doma.
-
Kde sa da kupit LTO6 za 500kc? Je mi jasne, ze na Heureke sa to nekupuje, ale ona ukazuje cenu 750kc.
Mimo to, někde jsem viděl nabídku na pásky za 550Kč (BEZ DPH) i tady v ČR, jen se mi to teď nechce hledat.
Pro tvojí informaci:
https://www.mironet.cz/quantum-data-cartridge-lto5-lto-ultrium-gen-5-16003200gb+dp106869/ (https://www.mironet.cz/quantum-data-cartridge-lto5-lto-ultrium-gen-5-16003200gb+dp106869/)
Pokud ti stačí 1.6TB, jsou pásky LTO5 levnější a v mechanice LTO6 je normálně zapíšeš.
Mohl by ses dostat na 450Kč/kus (den?).
Zase teoretik alebo niekto, kto zaplati tisicku aby usporil stovku ::).
LTO5 v LTO6 mechanike zapise a aj precita, ale rychlo si znici hlavu. Po 500 zapisanych paskach ju bude musiet vymenit. Kompatibilita je na urovni marketingu a pre pripad nutnosti, nie pre kazdodenne pouzivanie. LTO5 paska do LTO6 mechaniky je ako smirgel.
Nevím o tom, LTO5 běží a je testováno v LTO6 mechanice bez problému. Nám mechanika neodešla a to je prosím 24x tapeloader, kde se otočí kolem deseti nebo více pásek za týden. Navíc cleaning tape je obyčejně pro více generací. Brusný papír to rozhodně není...
-
LTO5 běží a je testováno v LTO6 mechanice bez problému. Nám mechanika neodešla a to je prosím 24x tapeloader, kde se otočí kolem deseti nebo více pásek za týden. Navíc cleaning tape je obyčejně pro více generací. Brusný papír to rozhodně není...
Děkuji za potvrzení, musím říct, že mě ten člověk trochu znejistěl.
Vím o tom, že před pěti lety měl jeden výrobce médií problémy, ale člověk samozřejmě nechce, aby se komukoliv cokoliv potvrdilo. Musím říct, že mám s používáním médií řadu zkušeností, ale ne na úrovni tak intenzivního využití!
VELMI DĚKUJI ZA VÁŠ NÁZOR!
Považuji ho za mimořádně důležitý.
Ostatně ze začátku budou a JSOU pásky LTO7 nesmyslně drahé, jejich cena klesne až postupně a přitom mechaniku lze pořídit v nabídce za podobné peníze, jako LTO6.
-
Vidím to přesně opačně: méně zkušený admin bude zálohovat pár serverů, typicky s jedním, dvěma operačními systémy a na žádné problémy vůbec nenarazí. Nemá pro něj sebemenší smysl investovat do nějaké předražené komerční bestie, která má taky svých problémů dost.
Respektuji Váš názor.
Když se podívám na mzdu admina a cenu hardwaru, nepřijde mi žádné řešení na trhu předražené. Admin v malé firmě má sám na bedrech spoustu úkolů, aby se babral se složitými řešeními (a není nic smutnějšího než write-only záloha). Ve velké firmě se zase uplatní úspory z rozsahu.
Díky za diskusi.
Jistě že mzda dobrého admina nebo dokonce systémového inženýra je docela pořádná položka. Ono dát ale nižší statisíce korun za něco, co umí stejně dobře (nebo i lépe) FOSS Bacula nebo Bareos... to už nějaký ten den práce uhradí. Obecně můžu říct, že vím o několika větších i absolutně minimálních nasazeních Bareos v okolí a neslyšel/ nezažil jsem problém a to ani když se upgradoval hardware nebo operační systém nebo měnilo RAID pole.
Myslím, že když se do dokumentace trochu ponoříte, zjistíte, že Bareos není špatný ani na doma.
No já se momentálně snažím rozchodit Bareos doma, aby mi zálohoval na pásku data z domácího win serveru. Už do toho čumím tři dny (myšleno konfigurace) a zatím nic moc pokrok. Asi to budu muset fakt všechno dočíst do konce a zkouknout YT videa taky do konce... :-)
-
No já se momentálně snažím rozchodit Bareos doma, aby mi zálohoval na pásku data z domácího win serveru. Už do toho čumím tři dny (myšleno konfigurace) a zatím nic moc pokrok. Asi to budu muset fakt všechno dočíst do konce a zkouknout YT videa taky do konce... :-)
Psal jsem, ze pro cloveka, ktery takovy typ zalohovani nikdy nevidel, je to trochu darda :) Ale imho stoji za to to prekousnout a pak mas nastroj na vsechno :)
Pokud bys umel rozumne popsat problem, treba bysme dokazali pomoct.
-
Na takovéto domácí žvýkání - co třeba backuppc? UI takové strohé, ale funguje to a základní konfigurace není nijak složitá. Nějakou podporu pro pásky jsem tam neviděl, ale to resim krátkým bash skriptem. Na doma (používám i ve firmě) dostačující.
-
Na takovéto domácí žvýkání - co třeba backuppc? UI takové strohé, ale funguje to a základní konfigurace není nijak složitá. Nějakou podporu pro pásky jsem tam neviděl, ale to resim krátkým bash skriptem. Na doma (používám i ve firmě) dostačující.
Myslím, že na domácí přežvýkání Windows Serveru je nejjednodušší nasadit Zálohování Windows (součást systému).
-
Vestavěné zálohování je taky varianta, chtěl bych však, aby zálohování prováděl jiný stroj než ten, jehož data chci uchovávat. Chci data přemísťovat metodou "pull", ne "push", druh D2D2T. Ze stroje s Debianem přes rsync na jeho lokální hdd dostanu, co potřebuju a tento jeho (nyní) lokální obsah budu podle nějakého schématu sypat na pásku. To je moje představa. No a na ten debianí stroj jsem nainstaloval bareos a snažím se ho rozchodit...
-
Vestavěné zálohování je taky varianta, chtěl bych však, aby zálohování prováděl jiný stroj než ten, jehož data chci uchovávat. Chci data přemísťovat metodou "pull", ne "push", druh D2D2T. Ze stroje s Debianem přes rsync na jeho lokální hdd dostanu, co potřebuju a tento jeho (nyní) lokální obsah budu podle nějakého schématu sypat na pásku. To je moje představa. No a na ten debianí stroj jsem nainstaloval bareos a snažím se ho rozchodit...
Z windows na debiana pomocí rsync, chápu to správně?
-
Vestavěné zálohování je taky varianta, chtěl bych však, aby zálohování prováděl jiný stroj než ten, jehož data chci uchovávat. Chci data přemísťovat metodou "pull", ne "push", druh D2D2T. Ze stroje s Debianem přes rsync na jeho lokální hdd dostanu, co potřebuju a tento jeho (nyní) lokální obsah budu podle nějakého schématu sypat na pásku. To je moje představa. No a na ten debianí stroj jsem nainstaloval bareos a snažím se ho rozchodit...
Z windows na debiana pomocí rsync, chápu to správně?
Ano. Buď přes mountnutá smb sdílení nebo na win stroji pojede CygWin. Nebo je to zcestná myšlenka?
-
Ano. Buď přes mountnutá smb sdílení nebo na win stroji pojede CygWin. Nebo je to zcestná myšlenka?
Síla zálohování Windows je v VSS (Volume Snapshot Service / Shadow Copy). Bareos ho využije jen okrajově, a rsync ho nevyužije vůbec. Hodně zjednodušeně řečeno: rsyncem zazálohujete jen neotevřené soubory.
A za to chcete navěsit právě poměrně sofistikovaný systém, jako je bareos.
Přijde mi to jako nevyrovnané řešení. V jednom místě možná moc slabé, a v jiném místě předimenzované.
Pokud bareos a pull (což je asi dobrá myšlenka), pak bych na Windows nainstaloval aspoň bareos-client.
Pokud na Windows serveru běžíte instanci SQL serveru nebo něco podobného, pak bych raději volil úplně jiný typ zálohování, protože se uscriptujete, aby to fungovalo dobře, a ukontrolujete, abyste měl v budoucnu jistotu, že to nezkolabovalo.
-
O systém win jako takový mi ani tak nejde. Používám ho doma jako úložiště (s pomocí Stablebit Drivepool) a potřebuju archivovat pouze uživatelská data. Bareos client už tam mám, připravený, až porozumím zbytku...
Ale díky za postřeh. S VSS moc zkušeností nemám, prý snad některý ransomware jej umí "zrušit"... Proto taky chci uložená data sosat odjinud, ze "spolehlivého" jednoúčelového stroje.
-
O systém win jako takový mi ani tak nejde. Používám ho doma jako úložiště (s pomocí Stablebit Drivepool) a potřebuju archivovat pouze uživatelská data. Bareos client už tam mám, připravený, až porozumím zbytku...
Ale díky za postřeh. S VSS moc zkušeností nemám, prý snad některý ransomware jej umí "zrušit"... Proto taky chci uložená data sosat odjinud, ze "spolehlivého" jednoúčelového stroje.
Tady jsme se nepochopili. VSS uchovává verze téhož souboru na disku v různých časových verzích, to ano. Dá se to využít k získání starších dat téhož souboru, to také ano. A je pravda, že ransomware tuto funkci vypínají, aby se nedalo dostat k nezašifrovaným datům před nákazou.
Prvotní účel VSS je ale jiný. Jde o to, že k souborům se tvoří snapshot, a zálohovací software pak zálohuje tento snapshot, který není aktuálně otevřený pro zápis. To nemá nic společného s tou první, funkcí, kterou ovlivňuje ransomware.
Pokud zálohujete jen soubory, které nikdo nemá otevřené pro zápis (nebo jen výjimečně), tak VSS nemusíte řešit.
Co Vám na bareosu nejde konkrétně? Něčím začněte, odpovědi se na to už najdou.