Vraag DD gebruiken voor het klonen van schijven


Er zijn een aantal vragen geweest met betrekking tot hulpmiddelen voor het klonen van schijven en dd is minstens één keer gesuggereerd. Ik heb al overwogen om te gebruiken dd mezelf, voornamelijk vanwege het gebruiksgemak en dat het gemakkelijk beschikbaar is op vrijwel alle opstartbare Linux-distributies.

Wat is de beste manier om te gebruiken dd voor het klonen van een schijf? Ik deed een snelle Google-zoekopdracht en het eerste resultaat was een ogenschijnlijke mislukte poging. Is er iets dat ik moet doen na gebruik? dd, d.w.z. is er iets dat NIET kan worden gelezen met behulp van dd?


176
2018-05-05 18:21


oorsprong


Ik ben me bewust hoe dd werkt, mijn vraag was meer in de richting van bekende problemen gerelateerd aan dd bij het klonen van schijven (zoals beschreven door de link), misschien was dit niet erg duidelijk. Wat zijn antwoord bevat en dat van jou is niet: "Ik heb er nooit een probleem mee gehad". Ik heb ook je antwoord geacteerd, omdat je zeker een aantal interessante punten hebt gepresenteerd (ik vind het leuk dat er geen voortgangsindicatie is). - falstro
Het lijkt erop dat je de Spolsky Bump hebt: joelonsoftware.com/items/2009/05/29.html - Kyle Cronin
heb dit hier niet gezien toen ik een vergelijkbare vraag over superuser vroeg (en beantwoordde) superuser.com/questions/11453/... - warren
Het is ironisch dat Joel de vraag als een goed voorbeeld van serverfout heeft gekoppeld, hoewel geen van de antwoorden goed was. Er was niet één antwoord tussen 25 (exclusief opmerkingen) met het recht dd opties voor het overslaan van slechte blokken - wat essentieel is bij het klonen van schijven voor herstel. Ik voegde een beter antwoord toe, dat schijven kan klonen met slechte blokken: dd if=/dev/sda of=/dev/sdb bs=4096 conv=sync,noerror - Sam Watkins
Ik denk dat het herstellen van dd mogelijk "faalt" als we het hebben over schijfgeometrie-afhankelijke bestandssystemen en het herstellen gebeurt op niet-identieke harde schijven? Ik ondervond een aantal fouten bij het herstellen van dd, en ik denk dat dit het probleem was in mijn geval. - Marco


antwoorden:


dd is zeker de beste klonen tool, het zal een 100% replica creëren door simpelweg het volgende commando te gebruiken. Ik heb er nooit een probleem mee gehad.

dd if=/dev/sda of=/dev/sdb bs=32M

Houd er rekening mee dat u bij het klonen van elke byte deze niet moet gebruiken op een station of partitie die wordt gebruikt. Vooral applicaties zoals databases kunnen hier niet goed mee omgaan en je zou kunnen eindigen met corrupte data.


152
2018-05-05 18:31



Natuurlijk, zolang / dev / sdb minstens zo groot is als / dev / sda ... - Eddie
voeg een "bs = 100M conv = notrunc" toe en het is veel sneller in mijn ervaring. - Tim Williscroft
wees heel voorzichtig met de letters 'i' en 'o' ... - bandi
Niemand lijkt deze truc te kennen ... dd is een asymmetrisch kopieerprogramma, wat betekent dat het eerst zal lezen, dan schrijven en dan terug. Je kunt DD naar zichzelf pipen en hem dwingen om de kopie symmetrisch uit te voeren, zoals deze: dd if=/dev/sda | dd of=/dev/sdb. In mijn tests gaf het uitvoeren van de opdracht zonder de pijp me een doorvoer van ~ 112 kb / s. Met de pijp kreeg ik ~ 235kb / s. Ik heb nog nooit problemen met deze methode ondervonden. Succes! - Mistiry
@Mistiry, dat is niet de betekenis van het woord symmetrisch. - psusi


Om ruimte te besparen, kunt u gegevens comprimeren die zijn geproduceerd door dd met gzip, bijvoorbeeld:

dd if=/dev/hdb | gzip -c  > /image.img

U kunt uw schijf herstellen met:

gunzip -c /image.img.gz | dd of=/dev/hdb

Om nog meer ruimte te besparen, defragmenteert u de schijf / partitie die u van tevoren wilt klonen (indien van toepassing), en maakt u alle resterende ongebruikte ruimte leeg, waardoor gzip gemakkelijker kan worden gecomprimeerd:

mkdir /mnt/hdb
mount /dev/hdb /mnt/hdb
dd if=/dev/zero of=/mnt/hdb/zero

Wacht een beetje, dd zal uiteindelijk falen met een "schijf vol" bericht, dan:

rm /mnt/hdb/zero
umount /mnt/hdb
dd if=/dev/hdb | gzip -c  > /image.img

U kunt ook een dd-proces op de achtergrond laten uitvoeren om de status te melden door het een signaal te sturen met het kill-commando, bijvoorbeeld:

dd if=/dev/hdb of=/image.img &
kill -SIGUSR1 1234

Controleer uw systeem - de bovenstaande opdracht is voor Linux, OSX en BSD. Dd-opdrachten verschillen in de signalen die zij accepteren (OSX gebruikt SIGINFO - u kunt op drukken Ctrl+T om de status te melden).


104
2018-05-06 22:47



Werkt dit ook met "moderne" fs zoals een BTRFS, NILFS, [waar je maar van kunt dromen]? - Steve Schnepp
DD werkt op block-apparaten, een niveau van abstractie lager dan het bestandssysteem, dus het zou moeten, ja. Ik heb het echter nog niet echt geprobeerd. Hmm, NILFS ziet er interessant uit, ik zal daarnaar moeten kijken. - David Hicks
+1 voor de kill -SIGUSR1 %1en de opdracht OSX dd aanvaardt gelukkig SIGUSR1 ... super handig, bedankt! - stuartc
+1 voor Kill -SIGUSR1 1234 Ik was daar naar op zoek. - hot2use
Zou het moeten zijn: dd if=/dev/hdb | gzip -c > /image.img.gz ? - Mike Causer


VOORZICHTIGHEID: dd'en een live bestandssysteem kan bestanden beschadigen. De reden is simpel, het heeft geen begrip van de activiteit van het bestandssysteem die mogelijk gaande is, en doet geen poging om het te beperken. Als een schrijf gedeeltelijk onderweg is, krijgt u een gedeeltelijke schrijven. Dit is meestal niet goed voor dingen en over het algemeen fataal voor databases. Bovendien, als je het typo-gevoel verknoeit als en van parameters, wee je. In de meeste gevallen, rsync is een even effectief hulpmiddel geschreven na de komst van multitaskingen biedt consistente weergaven van afzonderlijke bestanden.

DD moet echter de bitstatus van een niet-gemonteerde schijf nauwkeurig vastleggen. Bootloaders, llvm-volumes, UUID's en labels partitioneren, enz. Zorg er gewoon voor dat je een drive hebt die in staat is om de bit van de doeldrive voor bit te spiegelen.


37
2018-05-05 20:20



Ik vermoed dat sync is niet het antwoord op het oplossen van corruptieproblemen. Wat gebeurt er als een deamon of iets meer bestanden schrijft na de sync, tijdens de dd operatie? - Deleted
Het is een goed idee eerst de schijf op te halen (of opnieuw te koppelen als alleen-lezen) maar dit is niet altijd mogelijk - Alex Bolotov
In dat geval gebruik je rsync en laat je het bestand verwerken met magic om een ​​consistent bestand te krijgen en laat Copy On Write-semantiek de binnenkomende schrijfopdrachten afhandelen. - jldugger
Ik zou willen toevoegen dat het draaien van dd op een gekoppeld bestandssysteem de bestanden op het gemounte bestandssysteem NIET CORRUPT, maar wat hier bedoeld wordt is dat de kopie van het bestandssysteem noodzakelijkerwijs in een bekende goede staat is. - 3molo
Gebruik makend van rsync zal ervoor zorgen dat de interne gegevens in het bestemmingsbestandssysteem is consistent. Het zal niet zorg ervoor dat de gegevens in de bestanden consistent zijn - om dat te doen, zou u de bestanden moeten vergrendelen en alle programma's die naar de bestanden schrijven zouden deze sloten moeten respecteren. - Martin Geisler


Wanneer u dd gebruikt om een ​​schijf te klonen die mogelijk slechte sectoren bevat, gebruikt u "conv = noerror, sync" om ervoor te zorgen dat deze niet stopt wanneer er een fout optreedt en vult de ontbrekende sector (en) met nulbytes in. Dit is meestal de eerste stap die ik moet nemen als ik probeer te herstellen van een defecte of falende schijf - neem een ​​kopie voordat ik herstelpogingen voer en herstel op de goede (gekloonde) schijf. Ik laat het over aan de hersteltool om met lege sectoren om te gaan die niet gekopieerd konden worden.

Het is ook mogelijk dat de snelheid van dd wordt beïnvloed door de instelling van de bs (blokgrootte). Ik probeer meestal bs = 32768, maar je zou het misschien op je eigen systemen willen testen om te zien wat voor jou het snelst werkt. (Hierbij wordt ervan uitgegaan dat u om een ​​andere reden geen specifieke blokgrootte hoeft te gebruiken, bijvoorbeeld als u naar een band schrijft.)


26
2018-05-07 02:42



Als je een schijf hebt met slechte sectoren, zou je echt 'ddrescue' moeten gebruiken in plaats van dd. Het is veel efficiënter en heeft een veel betere kans om meer gegevens te herstellen. (Maak het niet verward met dd_rescue, wat niet zo goed is) - davr
zou geen grote blokgrootte moeten gebruiken bij het proberen om slechte blokken over te slaan, anders zal het te veel overslaan. 4096 is groot genoeg. - Sam Watkins


Om een ​​schijf te klonen, hoeft u alleen de invoer en uitvoer op te geven naar dd:

dd if=/dev/hdb of=/image.img

Zorg er natuurlijk voor dat je de juiste rechten hebt om direct te lezen van / dev / hdb (ik raad aan om als root te draaien), en dat / dev / hdb is niet gemount (u wilt niet kopiëren terwijl de schijf wordt gewijzigd - montage als alleen-lezen is ook acceptabel). Eenmaal voltooid, zal image.img een byte-voor-byte kloon van de gehele schijf zijn.

Er zijn een paar nadelen aan het gebruik van dd om schijven te klonen. Ten eerste zal dd je hele schijf kopiëren, zelfs lege ruimte, en als je dit op een grote schijf hebt gedaan, kan dit resulteren in een extreem groot beeldbestand. Ten tweede biedt dd absoluut geen voortgangsindicaties, wat frustrerend kan zijn omdat het kopiëren lang duurt. Ten derde: als u deze afbeelding kopieert naar andere stations (opnieuw met behulp van dd), moeten deze even groot of groter zijn dan de originele schijf, maar u kunt geen extra ruimte gebruiken op de doelschijf totdat u formaat van uw partities.

U kunt ook een rechtstreekse schijf-naar-schijfkopie doen:

dd if=/dev/hdb of=/dev/hdc

maar je bent nog steeds onderworpen aan de bovenstaande beperkingen met betrekking tot vrije ruimte.

Wat problemen of problemen betreft, doet dd voor het grootste deel uitstekend werk. Echter, een tijdje geleden had ik een harde schijf die op het punt stond te sterven, dus gebruikte ik dd om te proberen en te kopiëren welke informatie ik eroverheen kon voordat het volledig stierf. Vervolgens werd geleerd dat dd de leesfouten niet goed afhandelt - er waren verschillende sectoren op de schijf die dd niet kon lezen, waardoor dd op zou geven en de kopie zou stoppen. Op dat moment kon ik geen manier vinden om dd te vertellen om door te gaan ondanks het tegenkomen van een leesfout (hoewel het lijkt alsof het die instelling heeft), dus heb ik nogal wat tijd besteed aan het handmatig opgeven van overslaan en probeer ik de onleesbare secties over te slaan.

Ik heb wat tijd besteed aan het onderzoeken van oplossingen voor dit probleem (nadat ik de taak had voltooid) en ik vond een programma genaamd ddrescue, wat volgens de site werkt als dd maar blijft lezen, zelfs als er een fout optreedt. Ik heb het programma nog nooit gebruikt, maar het is het overwegen waard, vooral als de schijf waarvan je kopieert oud is, wat slechte sectoren kan hebben, zelfs als het systeem in orde lijkt.


17
2018-05-05 18:26



... dd geeft absoluut geen voortgangsindicaties ... - nou, dit is niet waar - er is een beetje een lastige manier om vooruitgang te tonen - je moet pid van dd proces ('ps -a | grep dd') achterhalen en dan signaal USR1 naar dit proces sturen - 'kill -USR1 < dd_pid_here> '(zonder <>) die dd forceren om voortgangsinformatie weer te geven. - Michal Bernhard
"verschillende sectoren op de schijf die dd niet kon lezen": ik denk dat conv=sync,noerror zou helpen. - Gauthier
De conv=sync,noerror opties zijn essentieel, ze laten dd toe om slechte blokken over te slaan en ze uit te zetten in de afbeelding, zodat de dingen correct zijn uitgelijnd. Props voor de weinige mensen die daar iets over hebben gezegd. - Sam Watkins
GNU ddrescue biedt voortgangsindicatie zonder speciale opties, en u kunt het kopiëren stoppen en verdergaan waar u was gebleven. - endolith
Een minder lastige manier om vooruitgang te boeken met dd is om de optie toe te voegen status=progress - James


Als de bronschijf helemaal is beschadigd, kunt u meer geluk hebben dd_rhelp met dd_rescue (mijn persoonlijke voorkeur) of GNU ddrescue.

De reden hierachter is dat, bij leesfouten, dd blijft proberen en proberen en proberen - mogelijk lang wachten tot er zich time-outs voordoen. dd_rescue doet slimme dingen zoals het lezen van een fout, vervolgens een plekje verderop op de schijf en leest terug naar de laatste fout, en dd_rhelp is eigenlijk een dd_rescuesessiemanager - slim starten en hervatten dd_rescue loopt om het weer sneller te maken.

Het eindresultaat van dd_rhelp is maximale data hersteld in minimale tijd. Als je weggaat dd_rhelp hardlopen, op het einde doet precies dezelfde taak als dd tegelijkertijd. Echter, als dd leesfouten tegengekomen bij byte 100 van uw 100 Gb schijf, dan zou u lang moeten wachten om de andere 9.999.9900 bytes * te herstellen, terwijl dd_rhelp+dd_rescue zou het grootste deel van de gegevens veel sneller herstellen.


11
2018-05-31 02:12



Sommige helpen bij het kiezen tussen dd_rescue en ddrescue: askubuntu.com/a/211579/50450 - Johann


De bronschijf mag geen gekoppeld bestandssysteem hebben. Als een gebruiker die het blokapparaat kan lezen (rootwerken), voer dan 'dd if = / dev / sda ....' uit.

Nu, een van de leuke dingen hier is dat je een stroom van bytes aan het maken bent ... en daar kun je veel mee doen: comprimeer het, stuur het over het netwerk, deel het in kleinere klodders, enz.

Bijvoorbeeld:

dd if=/dev/sda | ssh user@backupserver "cat > backup.img"

Maar krachtiger:

dd if=/dev/sda | pv -c | gzip | ssh user@backupserver "split -b 2048m -d - backup-`hostname -s`.img.gz"

Het bovenstaande kopieert een gecomprimeerde afbeelding van de harde schijf van de bron naar een systeem op afstand, waar het wordt opgeslagen in genummerde 2G-stukjes met behulp van de naam van de bronhost, terwijl u op de hoogte blijft van de voortgang.

Merk op dat, afhankelijk van de grootte van de schijf, de snelheid van de CPU op de bron, de snelheid van de CPU op de bestemming, de snelheid van het netwerk, enz. Misschien wilt u compressie overslaan, of de compressie aan de externe kant uitvoeren, of de compressie van ssh inschakelen.


7
2018-05-29 19:23



+1 Piping door gzip kan veel tijd en bandbreedte besparen! - M. Dudley
Ik moet ook opmerken dat het toevoegen van 'bs = 1M' aan de dd-opdracht de snelheid doorgaans aanzienlijk zal verbeteren. - retracile


Om een ​​schijf te klonen, hoeft u alleen de invoer en uitvoer op te geven dd:

dd if=/dev/hdb of=hdb.img

Zorg er natuurlijk voor dat u over de juiste machtigingen beschikt om rechtstreeks uit te lezen /dev/hdb (Ik zou aanraden om als root te worden uitgevoerd), en dat /dev/hdb is niet gemount (u wilt niet kopiëren terwijl de schijf wordt gewijzigd). Eenmaal voltooid, hdb.img wordt een byte-voor-byte kloon van de hele schijf.

Er zijn een paar nadelen aan het gebruik dd om schijven te klonen. Eerste, dd zal je hele schijf kopiëren, zelfs lege ruimte, en als je klaar bent op een grote schijf kan dit resulteren in een extreem groot beeldbestand. Tweede, dd geeft absoluut geen voortgangsindicaties, wat frustrerend kan zijn omdat het kopiëren lang duurt. Ten derde: als u deze afbeelding kopieert naar andere stations (opnieuw met behulp van dd), moeten deze even groot of groter zijn dan de originele schijf, maar u kunt geen extra ruimte gebruiken op de doelschijf totdat u formaat van uw partities.

U kunt ook een rechtstreekse schijf-naar-schijfkopie doen:

dd if=/dev/hdb of=/dev/hdc

maar je bent nog steeds onderworpen aan de bovenstaande beperkingen met betrekking tot vrije ruimte.

Het eerste nadeel kan worden opgelost door de gegevens te gzippen terwijl u de kopie maakt. Bijvoorbeeld:

dd if=/dev/hdb | gzip -9 > hdb.img.gz

Het tweede nadeel kan worden opgelost door de pipeview te gebruiken (pv) hulpmiddel. Bijvoorbeeld:

dd if=/dev/hdb | (pv -s `fdisk -l /dev/hdb | grep -o '[0-9]*\{1\} MB' | awk '{print $1}'`m) | cat > hdb.img

Ik ken geen manier om het derde nadeel te overwinnen.

Bovendien kunt u de kopieertijd versnellen door dit te vertellen dd om met grotere hoeveelheden gegevens te werken. Bijvoorbeeld:

dd if=/dev/hdb of=hdb.img bs=1024

6
2018-05-29 22:03



Je hebt al de weg gewezen om het derde nadeel te overwinnen ... formaat van de partities. Het vergroten van een partitie is over het algemeen een veilige en snelle operatie (versus krimpen of bewegen, wat traag en gevaarlijker is omdat het gegevens verplaatst). - davr
gzipping werkt niet met een schijf die al enige tijd wordt gebruikt, omdat deze wordt gevuld met huidige of verwijderde gegevens. gzip werkt alleen als de lege ruimte nul is, wat alleen het geval is bij een gloednieuwe schijf. - Tozz
@Tozz: U kunt de compressibiliteit van een bestandssysteembeeld verbeteren door het bestandssysteem te vullen met een bestand gevuld met 0's, het te synchroniseren met een schijf en het vervolgens te verwijderen. dd if=/dev/zero bs=1M of=/balloon; sync; rm /balloon  (Modulo extra intelligentie in de laag van het bestandssysteem.) - retracile


Een ander leuk ding dat je kunt doen met dd- en reddingsschijven, is kopieergegevens via het netwerk:

remote_machine$ nc -l -p 12345

local_machine$ dd if=/dev/sda | nc remote_machine 12345

Je kunt gzip in beide pijplijnen plakken als het netwerk niet lokaal is. Gebruik voor voortgang pv. Om de netcat van local_machine stop te zetten nadat het klaar is met kopiëren, zou je kunnen toevoegen -w 5 of zoiets.


5
2018-05-29 18:09



Dit is niet helemaal correct. De opdracht 'remote_machine' mist iets, zoals > disk_backup.img of |dd of=/dev/sdb of iets anders, afhankelijk van wat je wilt doen. Ik gok dat je een schijfimage niet naar stdout wilt dumpen. - davr
En gooi in gzip aan beide kanten om de verzonden gegevens verder te minimaliseren. - 3molo