---

Hej NG
jeg har fået en 'ny' og støre hd til hvor jeg gerne skulle have systemet
flyttet over på, jeg har set et eller andet sted at det kan gøres med små
midler, hvordan er det lige det gøres

System = Debian

/Carsten

---

Carsten <spam@spam.dk> writes:

> jeg har fået en 'ny' og støre hd til hvor jeg gerne skulle have systemet
> flyttet over på, jeg har set et eller andet sted at det kan gøres med små
> midler, hvordan er det lige det gøres

Google efter "Hard Disk Upgrade Mini How-To"

--
Peter Makholm | One thing you do is prevent good software from
peter@makholm.net | being written. Who can afford to do professional
http://hacking.dk | work for nothing?
| -- Bill Gates

---

Carsten wrote:

> jeg har fået en 'ny' og støre hd til hvor jeg gerne skulle have
> systemet flyttet over på, jeg har set et eller andet sted at det kan
> gøres med små midler, hvordan er det lige det gøres
>
> System = Debian

En metode jeg to gange før har brugt med held:

1. Sæt ny disk i.
2. Boot LiveCD.
3. Partitioner og formater ny disk.
4. Mount ny disk og kopier alt over med cp -ax (hvis filsystemet er
opdelt, så gør dette for hver del).
5. Installer bootloader på MBR af nye disk.
6. Sluk, byt diske, boot og test.

--
PeKaJe

"I don't really mind her being unfaithful," sighed the man to his
marriage counselor, "but I just can't sleep three in a bed."

---

Peter Jensen wrote:
> En metode jeg to gange før har brugt med held:
>
> 1. Sæt ny disk i.
> 2. Boot LiveCD.
> 3. Partitioner og formater ny disk.
> 4. Mount ny disk og kopier alt over med cp -ax (hvis filsystemet er
> opdelt, så gør dette for hver del).
> 5. Installer bootloader på MBR af nye disk.
> 6. Sluk, byt diske, boot og test.

Ja. Bortset fra at cp -ax hverken er den hurtigste eller sikreste måde.

Du bør enten benytte tar til at flytte hele filsystemer:

$ (cd /fra; tar cf - .)|(cd /til; tar xvBpf -)

Eller (måske nemmere) tage det hele et niveau ned og bruge dd. Du skal
blot sørge for at alle nye partitions er mindst ligeså store som de gamle:

For alle partitions:
dd if=/dev/fra of=/dev/til

bagefter køres en resizer på filsystemerne. F.eks. hvis ext3:

$ fsck.ext3 -f /dev/nypartition
$ resize2fs /dev/nypartition

Husk at hvis du har flyttet disken i systemet skal /etc/fstab nok lige
rettes inden der bootes
Derefter installer din Boot-loader.

Peter

---

Den Wed, 30 Nov 2005 09:41:04 +0100 skrev Peter Mogensen:
> Peter Jensen wrote:
>> En metode jeg to gange før har brugt med held:
>>
>> 1. Sæt ny disk i.
>> 2. Boot LiveCD.
>> 3. Partitioner og formater ny disk.
>> 4. Mount ny disk og kopier alt over med cp -ax (hvis filsystemet er
>> opdelt, så gør dette for hver del).
>> 5. Installer bootloader på MBR af nye disk.
>> 6. Sluk, byt diske, boot og test.
>
> Ja. Bortset fra at cp -ax hverken er den hurtigste eller sikreste måde.
>
> Du bør enten benytte tar til at flytte hele filsystemer:
>
> $ (cd /fra; tar cf - .)|(cd /til; tar xvBpf -)

Jeg skiftede fra 2*tar til cp da det gik op for mig hvor meget længere
tid det tager med tar, og at cp -a får alle de skumle ting (rettigheder,
devices) med også.

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Peter Mogensen wrote:

>> En metode jeg to gange før har brugt med held:
>>
>> 1. Sæt ny disk i.
>> 2. Boot LiveCD.
>> 3. Partitioner og formater ny disk.
>> 4. Mount ny disk og kopier alt over med cp -ax (hvis filsystemet er
>> opdelt, så gør dette for hver del).
>> 5. Installer bootloader på MBR af nye disk.
>> 6. Sluk, byt diske, boot og test.
>
> Ja. Bortset fra at cp -ax hverken er den hurtigste eller sikreste
> måde.
>
> Du bør enten benytte tar til at flytte hele filsystemer:
>
> $ (cd /fra; tar cf - .)|(cd /til; tar xvBpf -)

Jeg vil gerne høre din argumentation for at tar metoden skulle være
hurtigere. Begge metoder skal ind og finde alle filer, men tar har
desuden det overhead at tar-strukturen skal laves og pakkes ud. Det er
måske ikke meget, men det kan da umuligt være hurtigere. Desuden er
lange kommandoer som denne svære at huske og muligheden for fejl er
betydelig. Hvis jeg skulle kopiere et filsystem til en remote maskine,
*så* ville jeg dog benytte denne metode, i kombination med enten ssh
eller netcat.

Noget andet der undrer mig er at du siger at cp metoden er mindre sikker
end alternativet. Kunne du forklare hvad der i så fald skulle gå galt?
Det burde i hvert fald ikke være muligheden for en typo ...

> Eller (måske nemmere) tage det hele et niveau ned og bruge dd. Du skal
> blot sørge for at alle nye partitions er mindst ligeså store som de
> gamle:
>
> For alle partitions:
> dd if=/dev/fra of=/dev/til
>
> bagefter køres en resizer på filsystemerne. F.eks. hvis ext3:
>
> $ fsck.ext3 -f /dev/nypartition
> $ resize2fs /dev/nypartition

Fordel: Ingen overhead for at læse fra og skrive til et filsystem.
Unødvendigt at formatere den nye partition.

Ulempe: Kopierer også fri plads, så kan være (endog meget) langsommere.
Kopien ender med at have samme filsystem (så man kan f.eks. ikke skifte
til et mere optimalt). fsck og resize operationerne tager også
betydeligt tid (æder nok en evt. gevinst).

--
PeKaJe

Why use Windows, when there is a door?

---

Peter Jensen wrote:
> Jeg vil gerne høre din argumentation for at tar metoden skulle være
> hurtigere.

Det har jeg vist aldrig påstået.
Derimod vil jeg påstå at cp ikke kan finde ud af special-files og nogen
ældre version kan sikkert heller ikke så godt med symlinks.

> Fordel: Ingen overhead for at læse fra og skrive til et filsystem.
> Unødvendigt at formatere den nye partition.
>
> Ulempe: Kopierer også fri plads, så kan være (endog meget) langsommere.
> Kopien ender med at have samme filsystem (så man kan f.eks. ikke skifte
> til et mere optimalt). fsck og resize operationerne tager også
> betydeligt tid (æder nok en evt. gevinst).

Ja. selvfølgelig...
men nu laver man jo heller ikke så mange af den slags operationer om
dagen, så hvad gør det hvis man alligevel skal lave noget andet imens
den arbejder.
Den kan nu sagtens være hurtigere, hvis partition er næsten fuld (som
den jo er hvis man flytter fordi man er ved at løbe tør for plads).

fsck og resize tager ikke så lang tid sammenlignet med flytningen.

Peter

---

Peter Mogensen wrote:
> Peter Jensen wrote:
>
>>Jeg vil gerne høre din argumentation for at tar metoden skulle være
>>hurtigere.
>
>
> Det har jeg vist aldrig påstået.


Ups ...jo. Det sagde jeg faktisk. Det var egentlig ikke min pointe.
Jeg tvivler nu på at CPU-belastningen er en faktor, da vi alligevel
venter på disken.

Peter

---

Peter Mogensen wrote:

>> Jeg vil gerne høre din argumentation for at tar metoden skulle være
>> hurtigere.
>
> Det har jeg vist aldrig påstået.

Jo.

> Derimod vil jeg påstå at cp ikke kan finde ud af special-files og
> nogen ældre version kan sikkert heller ikke så godt med symlinks.

Du burde måske læse manualen for cp med de parametre jeg gav. Det er
godt nok GNU extensions, men jeg regner med at chancerne er store for at
det er den version OP har på sit Debian system. Jeg har selv brugt
kommandoen til at flytte mit nuværende system to gange uden nogen
problemer.

>> Fordel: Ingen overhead for at læse fra og skrive til et filsystem.
>> Unødvendigt at formatere den nye partition.
>>
>> Ulempe: Kopierer også fri plads, så kan være (endog meget)
>> langsommere. Kopien ender med at have samme filsystem (så man kan
>> f.eks. ikke skifte til et mere optimalt). fsck og resize
>> operationerne tager også betydeligt tid (æder nok en evt. gevinst).
>
> Ja. selvfølgelig... men nu laver man jo heller ikke så mange af den
> slags operationer om dagen, så hvad gør det hvis man alligevel skal
> lave noget andet imens den arbejder.

Jeg kan komme på rigeligt mange situationer hvor det kan betyde en hel
del at kopieringen forløber hurtigst muligt.

> Den kan nu sagtens være hurtigere, hvis partition er næsten fuld (som
> den jo er hvis man flytter fordi man er ved at løbe tør for plads).
>
> fsck og resize tager ikke så lang tid sammenlignet med flytningen.

Næh, men de tager med garanti længere tid end den overhead man sparer
ved ikke at læse fra filsystemet, da en fsck pr. definition er nødt til
at læse filsystemet og analysere det. Det kan dog stadig være at der er
noget sparet tid for hele processen, men det er svært at sige generelt.

Alt dette er værd at huske når man skal vælge mellem dd, cp, og tar
metoden. Personligt ville jeg nok kun bruge dd metoden hvis jeg skulle
klone et installeret image til store mængder af identiske diske. Og så
måske hvis jeg har en near-failure på en disk, hvor det betyder noget at
data *læses* hurtigst muligt. tar metoden ville jeg tilsvarende kun
bruge til at pipe et filsystem over ssh eller netcat til en fjern
maskine. Her udnyttes at tar-strukturen gemmer filsystemet over en
kommunikationskanal der ikke er beregnet på at transportere et
filsystem. For lokal kopiering med henblik på opgradering af disk, er
den foretrukne metode klart cp -ax. Den er simpel, hurtig, og den
virker.

--
PeKaJe

But alas, all you have is invective, and the logical equivalent of monkeys
flinging crap. -- Jim Richardson responding to DFS in COLA

---

Peter Jensen wrote:
> Peter Mogensen wrote:
>
>
>>>Jeg vil gerne høre din argumentation for at tar metoden skulle være
>>>hurtigere.
>>
>>Det har jeg vist aldrig påstået.
>
> Jo.

Ja. det opdagede jeg også lige efter jeg postede. Beklager.

>>Derimod vil jeg påstå at cp ikke kan finde ud af special-files og
>>nogen ældre version kan sikkert heller ikke så godt med symlinks.
>
> Du burde måske læse manualen for cp med de parametre jeg gav. Det er
> godt nok GNU extensions, men jeg regner med at chancerne er store for at
> det er den version OP har på sit Debian system. Jeg har selv brugt
> kommandoen til at flytte mit nuværende system to gange uden nogen
> problemer.

Ja. Hvordan har den det med:
# cp -ax /dev/zero /storfilmednuller

> Jeg kan komme på rigeligt mange situationer hvor det kan betyde en hel
> del at kopieringen forløber hurtigst muligt.

Det kan jeg også. Det aktuelle problem er bare ikke en af dem.

> Næh, men de tager med garanti længere tid end den overhead man sparer
> ved ikke at læse fra filsystemet, da en fsck pr. definition er nødt til
> at læse filsystemet og analysere det. Det kan dog stadig være at der er
> noget sparet tid for hele processen, men det er svært at sige generelt.

Det er iøvrigt ganske muligt at fsck kan springes over. Jeg plejer bare
at gøre det for gå med livrem og seler, da jeg normalt laver den slags
når jeg mistænker disken for at være på vej til at dø.
resize2fs tager ingen tid.

Peter

---

Peter Mogensen wrote:

>> Du burde måske læse manualen for cp med de parametre jeg gav. Det er
>> godt nok GNU extensions, men jeg regner med at chancerne er store for
>> at det er den version OP har på sit Debian system. Jeg har selv
>> brugt kommandoen til at flytte mit nuværende system to gange uden
>> nogen problemer.
>
> Ja. Hvordan har den det med:
> # cp -ax /dev/zero /storfilmednuller

Det laver en device node magen til /dev/zero, der hedder
/storfilmednuller. Hvad havde du forventet at den skulle gøre?

>> Jeg kan komme på rigeligt mange situationer hvor det kan betyde en
>> hel del at kopieringen forløber hurtigst muligt.
>
> Det kan jeg også. Det aktuelle problem er bare ikke en af dem.

Næh, men folk har det med at søge på Usenet for at finde løsninger på
deres problemer, så en god diskussion af alle løsningsmuligheder er
altid praktisk. Desuden har jeg argumenteret for at cp løsningen er den
optimale i dette tilfælde.

>> Næh, men de tager med garanti længere tid end den overhead man sparer
>> ved ikke at læse fra filsystemet, da en fsck pr. definition er nødt
>> til at læse filsystemet og analysere det. Det kan dog stadig være at
>> der er noget sparet tid for hele processen, men det er svært at sige
>> generelt.
>
> Det er iøvrigt ganske muligt at fsck kan springes over. Jeg plejer
> bare at gøre det for gå med livrem og seler, da jeg normalt laver den
> slags når jeg mistænker disken for at være på vej til at dø.
> resize2fs tager ingen tid.

Prøv bare at springe fsck over når du kører resize2fs. Så tager det i
hvert fald ingen tid, da den nægter at køre på et filsystem der har
været mounted siden sidste fsck ...

--
PeKaJe
   Any thread which begins on a serious subject will become frivolous, and
   any thread which begins on a frivolous subject will become serious.
      -- Rillion's Second Law

---

Peter Jensen wrote:

>>Ja. Hvordan har den det med:
>># cp -ax /dev/zero /storfilmednuller
>
>
> Det laver en device node magen til /dev/zero, der hedder
> /storfilmednuller. Hvad havde du forventet at den skulle gøre?

Det samme som den gør på min maskine. Laver en meget stor fil med nuller.

Peter

---

Peter Mogensen wrote:

>>> Ja. Hvordan har den det med:
>>> # cp -ax /dev/zero /storfilmednuller
>>
>> Det laver en device node magen til /dev/zero, der hedder
>> /storfilmednuller. Hvad havde du forventet at den skulle gøre?
>
> Det samme som den gør på min maskine. Laver en meget stor fil med nuller.

Enten gør du noget forkert, eller også er din cp defekt. Standard
coreutils på en Debian maskine er GNU versionen, og der virker det
korrekt.

--
PeKaJe
   > Linux is like a wooden pushcart.
   If it is, then Windows must be closer to a cardboard box with square
   wheels. -- rapskat in response to a troll in COLA

---

Peter Jensen wrote:
> Enten gør du noget forkert, eller også er din cp defekt. Standard
> coreutils på en Debian maskine er GNU versionen, og der virker det
> korrekt.

Ohh.... jeg kan se i min history at jeg gjorde noget forkert da jeg
tested.... douh!
Det er selvfølgelig meget fint at teste det man siger, men så skal man
jo også teste rigtigt... Jeg skal være den første til at indrømme at jeg
var et fjols her.

Ok... cp -ax håndterer special files. På et GNU system.

Peter

---

Den Thu, 01 Dec 2005 13:10:43 +0100 skrev Peter Mogensen:
> Peter Jensen wrote:
>> Enten gør du noget forkert, eller også er din cp defekt. Standard
>> coreutils på en Debian maskine er GNU versionen, og der virker det
>> korrekt.
>
> Ohh.... jeg kan se i min history at jeg gjorde noget forkert da jeg
> tested.... douh!
> Det er selvfølgelig meget fint at teste det man siger, men så skal man
> jo også teste rigtigt... Jeg skal være den første til at indrømme at jeg
> var et fjols her.
>
> Ok... cp -ax håndterer special files. På et GNU system.

Ja, man skal lige passe på at man læser manualen inden man fyrer
sådan en kommando af på en HP/UX (eller Solaris eller *BSD).

# who | wc -l
358
# killall -1 httpd
^C
# who | wc -l
123

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

On Wed, 30 Nov 2005 09:41:04 +0100, Peter wrote:

> Peter Jensen wrote:

>> 4. Mount ny disk og kopier alt over med cp -ax (hvis filsystemet er
>> opdelt, så gør dette for hver del).
>> 5. Installer bootloader på MBR af nye disk.
>> 6. Sluk, byt diske, boot og test.

> Ja. Bortset fra at cp -ax hverken er den hurtigste eller sikreste måde.

> Du bør enten benytte tar til at flytte hele filsystemer:

> $ (cd /fra; tar cf - .)|(cd /til; tar xvBpf -)

For lige at forvirre ekstra, så plejer jeg at bruge rsync (som sikkert
har mere overhead end cp og tar tilsammen) - så kan jeg altid køre
kommandoen en gang til og få et lille check på at alt er kopieret som
det skal.


Mvh.

--
"Simsala-hyp!" Adam Sjøgren
asjo@koldfront.dk

---

Den Wed, 30 Nov 2005 21:01:02 +0100 skrev Adam Sjøgren:
> On Wed, 30 Nov 2005 09:41:04 +0100, Peter wrote:
>
>> Peter Jensen wrote:
>
>>> 4. Mount ny disk og kopier alt over med cp -ax (hvis filsystemet er
>>> opdelt, så gør dette for hver del).
>>> 5. Installer bootloader på MBR af nye disk.
>>> 6. Sluk, byt diske, boot og test.
>
>> Ja. Bortset fra at cp -ax hverken er den hurtigste eller sikreste måde.
>
>> Du bør enten benytte tar til at flytte hele filsystemer:
>
>> $ (cd /fra; tar cf - .)|(cd /til; tar xvBpf -)
>
> For lige at forvirre ekstra, så plejer jeg at bruge rsync (som sikkert
> har mere overhead end cp og tar tilsammen) - så kan jeg altid køre
> kommandoen en gang til og få et lille check på at alt er kopieret som
> det skal.

Man kan i princippet også køre rsync bagefter hvis man bruger
cp første gang.

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

---

On Thu, 01 Dec 2005 09:27:38 +0100, Mogens wrote:

> Adam Sjøgren wrote:

>> For lige at forvirre ekstra, så plejer jeg at bruge rsync (som sikkert
>> har mere overhead end cp og tar tilsammen) - så kan jeg altid køre
>> kommandoen en gang til og få et lille check på at alt er kopieret som
>> det skal.

> Skal rsync ikke have rigtigt mange switche på for at få
> alt med (/dev nodes, symlinks, sparse filer, ekstra hardlinks)?

Jeg har lært "rsync -varz" uden ad, og den bruger jeg altid (ok, jeg
kan huske hvad 'z' betyder og undlader den over hurtige netværk eller
internt).

Så vidt jeg husker skal jeg vist bede den om at gå uden om /proc, men
det skal man vel også med tar og cp, eller hyr?

(Jeg kan ikke huske hvordan rsync klarer /dev; det er for lang tid
siden jeg sidst har skiftet harddisk).

Grunden til at jeg nævner rsync er at jeg er meget glad for at kunne
få det ekstra check på at alt gik godt, ved at køre den igen.

Jeg får altid dårlige nerver over at nogle filer er gået i ged pga. ny
kabling, IRQ- eller DMA-konflikter eller lignende

(Det kan være det er ved at være en saga med dagens hardware; det er
også lang tid siden jeg har købt nyt af det


Mvh.

--
"I gotta go right now; someone is videotaping me in my Adam Sjøgren
spaceship" asjo@koldfront.dk

---

Adam Sjøgren wrote:

> Så vidt jeg husker skal jeg vist bede den om at gå uden om /proc, men
> det skal man vel også med tar og cp, eller hyr?

Det er det -x gør ved cp. /proc er teknisk set et andet filsystem, så
cp går ikke ned i dens underbiblioteker med mindre man dummer sig og
starter den dér. -x har samme effekt på rsync, og for tar er det
vistnok -l.

--
PeKaJe

"Microsoft has done more for the fault tolerance industry than any
other company. They have made end-users very tolerant of faults".

---

On 01 Dec 2005 14:18:50 GMT, Peter wrote:

> Adam Sjøgren wrote:

>> Så vidt jeg husker skal jeg vist bede den om at gå uden om /proc,
>> men det skal man vel også med tar og cp, eller hyr?

> Det er det -x gør ved cp. /proc er teknisk set et andet filsystem, så
> cp går ikke ned i dens underbiblioteker med mindre man dummer sig og
> starter den dér. -x har samme effekt på rsync, og for tar er det
> vistnok -l.

Ah, ok, tak.

(Normalt vil jeg gerne tage alle filsystemer (når f.eks. /usr eller
/var ligger på separate partitioner), men lige /proc's indhold er lidt
kedeligt at komme til at kopiere).


Mvh.

--
"I gotta go right now; someone is videotaping me in my Adam Sjøgren
spaceship" asjo@koldfront.dk

---

On Thu, 01 Dec 2005 15:57:22 +0100, Mogens wrote:

> Adam Sjøgren wrote:
> ...
>> Jeg har lært "rsync -varz" uden ad, og den bruger jeg altid (ok, jeg
>> kan huske hvad 'z' betyder og undlader den over hurtige netværk eller
>> internt).

> Hvad med sparse files? Og hardlinkede filer?
[...]

Ingen anelse, det har åbenbart ikke spillet nogen rolle de gange jeg
har skiftet harddiske.

Tak for gennemgangen, i fremtiden vil jeg prøve at huske 'rsync
-varzSH' i stedet.

Hvordan får man GNU 'cp -ax' til at håndtere sparse files? Hvis jeg
forstod dit eksempel ret:

$ cd /var/log/
$ ls -l lastlog
-rw-rw-r-- 1 root utmp 293460 2005-12-01 15:01 lastlog
$ du lastlog
16 lastlog
$ cp -ax lastlog /tmp/
$ cd /tmp/
$ ls -l lastlog
-rw-rw-r-- 1 asjo asjo 293460 2005-12-01 15:01 lastlog
$ du lastlog
68 lastlog
$

Åh, den gør det selv, nogle gange:

"By default, sparse SOURCE files are detected by a crude heuristic and
the corresponding DEST file is made sparse as well. That is the behav-
ior selected by --sparse=auto. Specify --sparse=always to create a
sparse DEST file whenever the SOURCE file contains a long enough
sequence of zero bytes. Use --sparse=never to inhibit creation of
sparse files."

- man cp(1)

> Man skal have -H med til rsync for at
> få hardlinks rigtigt. tar og GNU "cp -ax" klarer det af sig selv.

Og hvad skal man skrive til tar og GNU cp for at få dem til at checke
at filerne der er kopieret stemmer overens med originalerne?


Mvh.

--
"I gotta go right now; someone is videotaping me in my Adam Sjøgren
spaceship" asjo@koldfront.dk