Názory k článku
Jak zálohovat rychle a bezbolestně

cituji:

„Bohužel tu je i několik překážek, které bezpečnosti našim datům chybí.“

Používám již delší dobu, ale zálohování spouštím ručně.
pokud tohle rozchodím, bude to dokonalé :-)

díky

Pred nejakym casem jsem take koukal na udev a jestli si pamatuji dobre, tak jsem nekde videl zminku ze skript spousteni pomoci RUN by nemel bezet dlouho protoze udev je behem behu pauznuty:

Writing udev rules

Zminka je ve tretim odstavci. Nikdy jsem se nedostal k tomu si s tim hrat, takze nemam zadne zadne prakticke zkusenosti, ale myslim ze za zminku to stoji.

A čo niečo také:

#!/bin/bash
echo "Spúšťam skript"
( sleep 1; echo "Toto spúšťa niečo iné" ) &
echo "Končím skript"
exit 0

toto by neriešilo problém dlho bežiaceho skriptu? Samozrejme sleep je len kvôli ukážke.

Nezožerte ma, neviem, pýtam sa…

myslím, že ne, kdysi jsem si s tím hrál a nějak to nechtělo takto fungovat. Vyřešil jsem to tehdy napsáním skriptíku, který nedělal nic jenom čekal na případnou zprávu od udevu (prostě koukal na pojmenovanou rouru). Udev místo spouštění nějakého skriptu pouze zapsal do této pojmenované roury nějaké heslo, tím se probudil ten můj skriptík a provedl požadovanou akci… krkolomné, ale v té chvíli funkční…

kdyz uz mas #!/bin/bash tak proc pouzivas ‚[‘, ktere volaji externi program – test – kdyz muzes pouzit interni ‚[[‘ ??? trochu lamerina, ne?

Dalo se to napsat trochu lip, nicmene dekuji za informaci, myslel jsem, ze [ je v bashi taky builtin.

Ovsem nemate uplnou pravdu – prinejmensim v Debianu Lenny jsou „[“ a „test“ dve nezavisle binarky, ktere se navzajem nijak nevolaji ;-).

$ ls -l /usr/bin/[ /usr/bin/test
-rwxr-xr-x 1 root root 34504 2008–04–04 16:22 /usr/bin/[
-rwxr-xr-x 1 root root 22852 2008–04–04 16:22 /usr/bin/test

$ strace -e file,process [ -d /bin/bash ]
execve(„/usr/bin/[“, [„[“, „-d“, „/bin/bash“, „]“], [/* 20 vars */]) = 0
access(„/etc/ld­.so.nohwcap“, F_OK) = –1 ENOENT (No such file or directory)
access(„/etc/ld­.so.preload“, R_OK) = –1 ENOENT (No such file or directory)
open(„/etc/ld­.so.cache“, O_RDONLY) = 3
access(„/etc/ld­.so.nohwcap“, F_OK) = –1 ENOENT (No such file or directory)
open(„/lib/i6­86/cmov/libc.so­.6“, O_RDONLY) = 3
open(„/usr/lib/lo­cale/locale-archive“, O_RDONLY|O_LAR­GEFILE) = 3
stat64(„/bin/bash“, {st_mode=S_IF­REG|0755, st_size=700492, …}) = 0
exit_group(1) = ?

$ strace -e file,process test -d /bin/bash
execve(„/usr/bin/tes­t“, [„test“, „-d“, „/bin/bash“], [/* 20 vars */]) = 0
access(„/etc/ld­.so.nohwcap“, F_OK) = –1 ENOENT (No such file or directory)
access(„/etc/ld­.so.preload“, R_OK) = –1 ENOENT (No such file or directory)
open(„/etc/ld­.so.cache“, O_RDONLY) = 3
access(„/etc/ld­.so.nohwcap“, F_OK) = –1 ENOENT (No such file or directory)
open(„/lib/i6­86/cmov/libc.so­.6“, O_RDONLY) = 3
open(„/usr/lib/lo­cale/locale-archive“, O_RDONLY|O_LAR­GEFILE) = 3
stat64(„/bin/bash“, {st_mode=S_IF­REG|0755, st_size=700492, …}) = 0
exit_group(1) = ?

Nevím jak u vás, ale můj bash 3.2.25 hlásí
$ type '['
[ is a shell builtin

Hlavní nevýhodou raidu není ani tak že odejde celý počítač, i když i to je nebezpečí, ale hlavně nechrání před vymazáním dat uživatelskou chybou – například rm -rf / :-)

Asi tak. Kdyz uz se v clanku o zalohovani objevi vyrazy RAID1/5/6 apod, tak by v nem melo byt vzapeti zdurazneno, ze RAID neni totez co zalohovani. RAID resi redundanci resp. nepretrzitou dostupnost sluzeb resp. dat v pripade kolapsu disku. Zalohovani resi obnovu dat v pripade jejich ztraty ci poskozeni (kde kolaps disku je pouze jedna z moznych pricin, a pravdepodobne ne nejcastejsi – casteji se jedna spis o chybu uzivatele ci administratora; a takovych moznych pricin jsou mraky). Navic rozumne zalohovaci reseni pocita is verzovanim a drzi nekolik verzi meneneho souboru nazpet, coz RAID opet nijak neresi (ani to z principu resit nemuze).

len skoda, ze nezvlada detegovat presuny suborov/preme­novania adresarov. teoreticky by to slo riesit kombinaciou rdiff-backup+lessfs, lenze lessfs sa v mojich testoch bohuzial ukazal ako neprilis stabilny.. :-(

zalohuju pomoci Back in time, ktery vyuziva rsync. Kdysi davno jsem si naklikal jednoduche, ale naprosto dostatecne nastaveni a vic neresim. GUI je pro KDE i pro GNOME.

Já s výhodou využívám při programování i psaní obyčejných textů Git, kde si jednoduše nastavím dva repozitáře proti sobě, které vzájemně synchronizuju. Má to výhodu, že si tím ukládám kompletní historii a kopíruju si ji na druhý stroj. Když seženu třetí stroj, budu mít tři paralelní kopie a moje paranoidní já bude zase trošku klidnější.

Git je dobry pro zdrojaky a podobne male soubory a soubory co se moc nemeni(fotky, hudba), ale treba nejakou Virtualbox image bych mu necpal, protoze pri zmene souboru vytvari tusim jeho plnou kopii a tedy požírá více místa na disku. Na druhou stranu je to i výhoda, protože když se u rozdílového zálohování posere rozdílový soubor se zmenovymy vektory tak je to hodne spatny.

Docela mne pobavilo, že přesně tento problém jsem řešil 2 dni dozadu a nakonec jsem dokonvergoval k nasledujícímu řešení pomocí duply, což je nadstavba jiného inkrementálního řešení duplicity:

http://www.nax.cz/2010/03/25/encrypted-laptop-backups-using-duply/

v tom tvem blogpostu – s/to safe/to save/g

Díky za upozornění. Fixnuto.

dat do cronu zfs snapshot a pak zfs send na druhej low-cost stroj ;)

S uspechem pouzivam backup2l.

jednoduchy shell skript, ktery resi i inkrementalni zalohy. Doporucuji alespon vyzkouset.

Na zalohovacim stroji pouzivam zfs on fuse. Mam jeden pool se dvema disky (raid1, to umi zfs samo o sobe). Vytvorim na zfs adresar /mnt/zalohy/stroj1, a spustim z cronu kazdej den

zfs snapshot mnt/zalohy/stroj1@20­10–03–26
rsync -aqhz –progress -e ssh root@stroj1:/m­nt/zalohy/stroj1 –delete

na zfs mam aktivovanou kompresi a deduplikaci. Celkem jednoduchy a efektivni.

ale deduplikacia zatial existuje len v solarisovom zfs, nie?

aha, takze v git-e uz je tiez

SUBSYSTEMS je tuším deprecated (použít ATTR a ATTRS pro rodiče)

Pěkné, právě jsem podle návodu vše zprovoznil, byl to asi poslední krok k dokonalosti a bezbolestnosti zálohování.

Děkuji Adame, pěkný článek.