SW pro zalohovani na disk

[Jan Kasprzak]

Ing. Pavel PaJaSoft Janoušek wrote:
: > hlucnost a teplo. V jednom z techto pripadu jde o domaci 
: > pracovni stanici
: > - kdzy si treba co rok az dva koupim vetsi disk, tak bych rad 
: > ten druhy
: > nejvetsi pouzil na zalohovani.
: 
: 	Tomu rozumim, vzhledem k moznostem Linux SW RAID se nemusi jednat o
: stejne ci vubec fyzicke disky, staci jeden, dokonce ani se nemusime bavit o
: partition, ale treba jen o loop mountovani souboru/u~ (soubor odpovidajici
: kapacity vytvorime pres dd id=/dev/zero...).

	Jo, ale ten zalohovaci musi byt stejne velky nebo vetsi nez to
co se zalohuje. Ja bych rad pracoval stylem "mam velky disk a neco
z nej chci zalohovat", ne "mam maly disk a delam nekolik jeho kopii
na velky disk".

: :) za malo, myslim, ze jsem potrebu pochopil presne, ale spise jsem zustal
: nepochopen... - ten RAID samozrejme nebude "on-line" stale, ale pouze v
: okamziku, kdy chci udelat zalohu - snapshot... - divam se na to podobne jako
: treba SCM Subversion na repository... - revize = snapshot celeho tree.

	Ano, ale tohle nevyuziva diskovy prostor tak dobre, jak by mohlo.

: 	Cili jeste jednou - standardni beh je v degradovanem rezimu, v
: pripade zalohy raidhotadd, necham provest synchronizaci a pak zase
: odpojim... - nemusim resit zadne soubory, MBR recordy, proste nic... kdyz si
: rozmyslim, tak v pripade partition vezmu loadlin a reknu, ze neco ala
: root=/dev/hdaXY a mam hotovo... Cokoli na bazi backupu souboru apod. mi
: prijde jako slozitejsi, nez tento jednoduchy snapshot filesystemu...

	Neposkytuje to zalohu starsich verzi. Plytva to kapacitou disku.
cp -lR a rsync je fakt asi lepsi.

-Y.

-- 
| Jan "Yenya" Kasprzak  <kas at {fi.muni.cz - work | yenya.net - private}> |
| GPG: ID 1024/D3498839      Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/   Czech Linux Homepage: http://www.linux.cz/ |
> Whatever the Java applications and desktop dances may lead to, Unix will <
> still be pushing the packets around for a quite a while.      --Rob Pike <