Fórum Root.cz
Hlavní témata => Software => Téma založeno: herrneiss 24. 03. 2017, 00:18:37
-
Dobrý večer,
Nevíte někdo, jak efektivně inkrementálně zálohovat (raw) obrazy virtuálních disků (qemu)? Zatím zálohuji 200GB disk programem rdiff-backup, funguje to, napoprvé to trvá <1 hod, ale další zálohy trvají >5 hod, dlouho trvá výpočet toho rozdílu.
Děkuji za rady.
-
kdyz bys misto raw pouzil qcow2 (nativni format Qemu) tak muzes snadno snapshotovat (a i si je jednotlive pak primountovat)
virsh snapshot-create-as jmenovirtualu "jmeno snapshotu" --atomic
-
Zkus se podívat na BorgBackup https://borgbackup.readthedocs.io (https://borgbackup.readthedocs.io) . Oproti rdiff-backup je deduplikace o dost rychlejší.
-
kdyz bys misto raw pouzil qcow2 (nativni format Qemu) tak muzes snadno snapshotovat (a i si je jednotlive pak primountovat)
virsh snapshot-create-as jmenovirtualu "jmeno snapshotu" --atomic
qcow ale za to plati urcitou ztratou vykonu ne?
-
Zkus se podívat na BorgBackup https://borgbackup.readthedocs.io (https://borgbackup.readthedocs.io) . Oproti rdiff-backup je deduplikace o dost rychlejší.
Tohle by me zajimalo z hlediska funkcnosti. U klasickeho zalohovani filesystemu si deduplikaci umim predstavit. Ale jak si ma clovek predstavit deduplikaci z hlediska zalohovani obrazu disku, cili zvenci?
Ja si ani neumi predstavit rozumne samotne inkrementalni zalohovani VM obrazu. Rekneme ze zalohuje ten 200GB obraz. Co z toho vznikne? Komprimovany soubor o velke velikosti? A ted pokud chceme inkrement, tak musime cely soubor precist na porovnani, nebo se udela dalsi zaloha tech 200GB, to se porovna s tim komprimakem a pak se udela rozdilovka? Protoze si myslim, ze nikdy neni vysledek komprese stejny i kdybychom 2x komprimovali to same.
-
Takto:
Deduplication based on content-defined chunking is used to reduce the number of bytes stored: each file is split into a number of variable length chunks and only chunks that have never been seen before are added to the repository.
Ale pozor na:
EXPECT THAT WE WILL BREAK COMPATIBILITY REPEATEDLY WHEN MAJOR RELEASE NUMBER CHANGES (like when going from 0.x.y to 1.0.0 or from 1.x.y to 2.0.0).
-
kdyz bys misto raw pouzil qcow2 (nativni format Qemu) tak muzes snadno snapshotovat (a i si je jednotlive pak primountovat)
virsh snapshot-create-as jmenovirtualu "jmeno snapshotu" --atomic
qcow ale za to plati urcitou ztratou vykonu ne?
Lepší je qed formát, blíží se výkonu raw při zachování dalších výhod jako je možnost cow, snapshotů, zabrání pouze zaplněného místa...
-
kdyz bys misto raw pouzil qcow2 (nativni format Qemu) tak muzes snadno snapshotovat (a i si je jednotlive pak primountovat)
Dík za radu. QCOW2 snapshoty znám a u jiných vm běžně používám. U tohoto virtuálního počítače mi ale jde především o výkon, proto je obraz disku uložen na ssd disku, na něm již ale prakticky není více volného místa. Použitím qcow2 formátu bych zaprvé část výkonu ztratil, a zadruhé by velikost qcow2 souboru se snapshoty rostla a na ssd disk by se mi nevešla. Zálohovat proto potřebuji někam jinam na obyčejný plotnový disk.
-
Kdyz uz mas nad celym diskem jeden velkem RAW soubor, tak uz je asi lepsi to naformatovat na LVM a mit VPS primo na LVM oddilu (a pak delat LVM snapshoty). Vykon by mel byt ze vsech zpusobu asi nejrychlejsi (ale v praxi jsem netestoval).
-
Ja si ani neumi predstavit rozumne samotne inkrementalni zalohovani VM obrazu. Rekneme ze zalohuje ten 200GB obraz. Co z toho vznikne? Komprimovany soubor o velke velikosti? A ted pokud chceme inkrement, tak musime cely soubor precist na porovnani, nebo se udela dalsi zaloha tech 200GB, to se porovna s tim komprimakem a pak se udela rozdilovka? Protoze si myslim, ze nikdy neni vysledek komprese stejny i kdybychom 2x komprimovali to same.
Rok inkrementálně zálohuji rdiif-backupem a funguje to dobře (několikrát už jsem ze zálohy i obnovoval) Akorát to tak dlouho trvá. Disk má 200 GB, 90 inkrementů zabírá asi 500 GB. Na disku je virtuál s windows.
-
kdyz bys misto raw pouzil qcow2 (nativni format Qemu) tak muzes snadno snapshotovat (a i si je jednotlive pak primountovat)
virsh snapshot-create-as jmenovirtualu "jmeno snapshotu" --atomic
qcow ale za to plati urcitou ztratou vykonu ne?
Ten qcow2 jde prealokovat, pak by měl být výkon vyšší. Teoreticky by se to mělo chovat podobně jako raw ale s možnostmi qcow2.
Další varianta je udělat baseimage raw a qcow2 overlay. Pak by to šlo i rozdělit na dva disky, což se může hodit.
http://serverfault.com/a/677646 (http://serverfault.com/a/677646)
S tím qed nevím, má někdo výsledky nějakých testů?
-
Děkuji všem za rady, problém jsem nakonec vyřešil ke své spokojeností pomocí BorgBackup (děkuji p. Vanišovi za doporučení). Deduplikace je v mém případě asi 5x rychlejší než pomocí rdiff-backup.
Kdyby se to někomu hodilo, posílám část zálohovacího skriptu (qemu+libvirt, borg):
virsh snapshot-create-as --domain $serverName $snapshotName --diskspec $diskName,file=$snapshotPath$snapshotName --diskspec sda,snapshot=no --disk-only --atomic # nad virtuálním diskem si vytvořím snapshot, do kterého se zapisuje během zálohování
borg create -C zlib "$borgPath::`date +'%Y-%m-%d_%H-%M'`" $imagePath$diskFile # zálohuji
virsh blockcommit $serverName $diskName --wait --active --verbose --pivot && # data ze snapshotu commitnu zpátky do hlavního obrazu
virsh snapshot-delete $serverName --current --metadata # ... a snapshot smažu
borg prune -v --list --keep-daily=7 --keep-weekly=4 --keep-monthly=6 $borgPath # ještě smažu staré zálohy