Potreboval by som si z casu na cas vyhotovit zálohu disku a vyhodnotil som dd ako ideálnu voľbu (jedná sa o headless server, ovladany cez SSH, OS je Debian)
-
K serveru su pripojené 3 disky (A, B, C) pričom A a B maju po 300GB a C ma 2TB, avšak aj na disku A aj B je len asi po 20-30 GB dat.
-
Robim dd zalohu do .img súboru z A alebo B na disk C. Ale .img súbory sú obrovské - zbytočne (viem že to dd tak robí) - čo mi doteraz nevadilo lebo na Céčko vošli po dve zálohy z každého disku, ale teraz by som ich potreboval preniesť na USB-čku (64GB)
-
otázka znie - akú efektivitu bude mat kompresia na takto vzniknuté .img súbory ? a ktorý kompresný program použiť ? gzip, bzip, zip, tar ? dačo iné ?
-
asi by dost pomohlo keby ze nalokované bloky boli zapísané nulami, však ? ak hej ako to spravím ? ako zapíšem nuly len na nepoužité bloky tých diskov ?
-
predstavujem si to asi tak, že sa pripojím cez ssh, pustím príkaz na zápis núl, potom pustím dd, a potom pustím kompresiu a ked pridem k serveru už si len ten súbor skopírujem na usbčko a prenesiem na druhy server
-
alebo existuje iné riešenie ? napadla ma clonezilla (ale to je asi len live obraz a ten obraz sa neda priamo mountnut ak sa nemýlim). DD používam hlavne preto, že kopia jedného .img súboru je ovela rychlejsia ako kopirovať tie tisíce malých dokumentov (asi aj kvoli slabsiemu HW) a .img súbor viem mountúť na druhom serveri a cez rsync rýchlo aktualizovať
dd je blbost. ano, da sa to, ale blbost.
rsync-ni si data na C, a skomprimuj. povodne rsync data nechaj, a pri dalsom rsynci ti uz skopiruje len diffy...
nie som v tomto žiadny odborník (som totálne mimo..) ale pokiaľ viem tak dd proste skopíruje všetko čo je na disku, áno aj voľné miesto... takže nejaké zálohy cez dd by som fakt nerobil pokiaľ tam máš len tých pár dát ako máš
ono to nie je take jezdnoznacne. vsetko zalezi od "stavu" disku. pokial na 300g disku bolo 100g dat, a 50g sa vymazalo, tak po z-dd-ckovani disku a skompirmovani budu skomprimovane data obsahovat aj tych vymazanych 50g, pretoze vymazanim dat sa data z disku realne neodstrania. jedna moznost teda je, vzdy pred dd-ckovanim vyplnit disk nulami - dd if=/dev/zero of=/zero.dd bs=1M count=xxx, samozrejeme xxx nastavit tak, aby sa nezaplnil cely disk. a potom moze prist na samotne dd-ckovanie disku a komprimaciu. z toho vyplyva, ze dd proste nie je na zalohovanie vhodne. zalohuju sa data...
ako ked mas tam 2x 300 GB disky, tak z teho sprav RAID1 v prvom rade
tar urcitie nie, nerobi kompresiu ... pozri porovnanie
statistika
... alebo pouzi rsync (odporucam)
krasny skript. a co sa asi tak stane, ked zaplnis komplet cely disk...?
btw, mozes mi to upravit pre toto:
... tar urcitie nie, nerobi kompresiu...
tar urcite ano. sice nerobi priamo kompresiu, ale vie starovat a skomprimovat v jednom kroku volanim externeho programu (vid. volby j,x,...)
... pozri porovnanie...
chyba ti tam 7z, ktory je este ucinnejsi ako lzma.
ale treba sa pozriet aj na cas komprimovania. je otazne, ci sa mi oplati pouzitim inej kompresie usetrit 3% velkosti, ale cas (a teda aj vytazenie servera) sa predlzi napr. o 10%...
Iba pre uplnost, tar nema compresiu. Unmountni disk a skus zalohovat s gzip:
Obnovenie zo zalohy:
Obnovenie zo zalohy:
zcat moja-zaloha.dd.gz | dd of=/dev/sdaX
kraaaaaaasa, fakt krasne. a ked /dev/sdaX je polovica povodnej particie? a ked chcem zo zalohy vytiahnut jeden subor?
# zerofree /dev/sdaX
tak urcite
man zerofree:
... filesystem has to be unmounted or mounted read-only for zerofree to work...
tak DD nieje ten spravny nastroj aj ked iba pre uplnost je mozne mount DD image s pouzitim loop a offset a tak vytiahnut akykolvek subor. Priklad:
Tato poziadavka sa nenachadza v povodnej otazke. V opacnom pripade rsync moze byt ucelnejsi.
Read-Only nieje problem. Unmounted alebo read-only filesystem je tiez doporuceny pre DD:
inak nieco ako:
tiez pomoze.
Read-Only nieje problem.
ani pre /?
takze si to zhrnieme:
1. chces "vynulovat" cely disk
300G (disk) - 30G (data) = 270G
270G * 1024 = 276480MB (toto treba vydedeckovat nulami)
rychlost disku ti dam cca 90MB/s (teda pokial nemas seriozne serverove disky; pokial to je virtual tak cau parky...)
cize 276480MB / 90MB/s = 51min
a to cele 2 krat, pretoze 2 disky = 102min
2. "zalohovanie" diskov
300G pri 90MB/s =~ 57min
a to cele 2 krat, pretoze 2 disky = 114min
3. kompresia
- tazko odhadnut, zalezi na cpu
4. obnova
- dekompresia - opat zalezi na cpu
- vobec netusim, co zaloha obsahuje. jedina moznost je moutnut subor. na to musim mat prava
- nedokazem vybrat konkretny/e subor/y zo zalohy
- dalsich xy nevyhod
celkova dlzka zalohovania = 2hod 36min + kompresia
--------------------------------------------------------------------
navrhovane riesenie:
1. rsync
- urobit prvotny rsync oboch diskov
30G / 90MB/s =~ 6min , ale dajme tomu cca 15min, pretoze male subory atd., to cele 2x = 30min
2. kazdy dalsi rsync bude uz len o skopirovani vzniknuteho rozdielu medzi datami a povodnym rsyncom. cas bude zalezat od velkosti diffu
3. starovat a skomprimovat data - zase zalezi na cpu
obnova:
- viem co zaloha obsahuje
- viem z nej vythianut konkretny/e subor/subory
- nemusim byt root na pracu so zalohou
- xy dalsich vyhod...
celkova dlzka zalohovania = skopirovanie zmeny dat, ktore nastali medzi zalohovnim
ak si este stale myslis, ze zalohovanie pomocou dd je dobra volba, tak...
Ak máš server na ktorom Ti záleží, tak záloha DD počas behu systému nemusí umožniť obnovu konzistentných dát. Pozri sa po hotových nástrojoch, a vyber si nejaký. Nezabudni aj na to, aby si správnym spôsobom odzálohoval databázy a citlivé aplikácie.
PS: Ak máš ten server virtuálny, a nepotrebuješ obnovu jednotlivých súborov, tak sa opýtaj poskytovateľa že ako ćasto sa robia snapshoty, koľko to vyjde na faktúre a koľko môže trvať rollback point in time.
Ja som riesil kadejake zalohivacie nastroje a snapshoty a podobne a prekombinoval som to tak ze som zabudol na najprimitivnejsie riesenie - priamo zbalit tie data do zipu.
.
dd som chcel len kvoli tomu ze vysledy .img viem priamo mountnut a je to jeden subor
.
Niekto pisal ze si mam spravit raid. Raid tam je kazdy z tych diskov ma zrkadlo. Ale spojit ich nemozem na kazdom su ine data ktore chcem oddelene.
.
K pocitaniu casu - cas nie je problem pri vytvarani zalohy ale len pri jej kopirovani na USB. dd alebo kompresiu som pustal na dialku cez ssh aj den dopredu. Ale kopirovanie dat na usb mi pri 1 velkom subore trva polku casu ako pri tisicoch malych suborov.
.
Ale ked ich zozipujem tak je to top riesenie, neviem preco som to opomenul.
.
Len pre info server je moj a je to bezny lacny serverovy disk wd red, zaloha je externy disk.
.
Dakujem za nazory a rady, urcite ich pouzijem
ešte by som doplnil, že OS serveru beží z daľšieho disku, ktorý zálohujem samostatne, tu sa jednalo vyhradne o zálohu dát - konkrétne ide o textové a tabulkové súbory a nejake pdfka a občas obrazky
-
momentálne riešenie funguje tak, že disky A a B rsyncom zalohujum na Cčko, tam potom púštam kompresiu a výsledný súbor si len skopírujem na USB a prenesiem kde treba
Bacha na rsync, to je prevít milá pani :) Čo si zmažeš na disku sa zmaže aj na zálohe, rovnako ti prevalí aj zmenené súbory. Pozri si man rsync aby si sa vyhol nemilým prekvapaniam.
vdaka za upozornenie ale to je ciel, ja potrebujem identickú verziu na oboch miestach, samozrejme pravidelné zálohy si ponechávam mimo a aj v pc v zmysle hesla zalohovat, zalohovat, zalohovat
Viem, ze to neriesi momentalnu situaciu, ale uz dlhsie vsade kde sa to da davam KVM virtualizaciu a az v nej na LVM-kach robim servery. Aka je vyhoda ? Nuz, lahka zaloha-snapshot lvm-ka s virtualkou, lahka i obnova, i do urovne suborov. Podmienky su samozrejme jasne, podpora virtualizacie a dost miesta na diskoch. No vyhody su naozaj velke.
A este lepsie to ma spravene Proxmox ;)