[Ubuntu 10.10] dd script?

[Sneiker]

Hallo,
Ik kom ergens niet uit, hopelijk kunnen jullie mij in ieder geval een beetje op weg helpen.

Ik wil van alles wat er in een map zit een dd maken en daar natuurlijk ook de md5jes van goed doen.
Nu heb ik dus gekeken of ik een hele map gewoon in 1x kan dd'en. Zoals iets van of=/home/xuser maar dat kan niet.

Nu dacht ik zelf iets als ls > ls.txt en dan cat ls.txt > dd.sh
Maar in dat dd.sh moet het dus wel in de goeie format. Heeft hier iemand een oplossing voor?

Korte samenvatting;

Ik wil van een map de hele inhoud dd'en + md5sum goed hebben, maar hoe?

Hopelijk weten jullie iets.

[swbr]

Waarom zou je dat willen doen?

Mijn eerste reactie is: Waarom stop je het niet gewoon in een tarball?

[Sneiker]

Antaresje schreef op maandag 14 februari 2011 @ 15:56:
Waarom zou je dat willen doen?

Mijn eerste reactie is: Waarom stop je het niet gewoon in een tarball?

Omdat je dan niet meer goed de md5sum kan doen volgens mij. Waardoor je niet zou kunnen aantonen dat het precies de zelfde file is. Wat ik dus wel wil

[Rainmaker]

Kan wel.

Tar geeft je 1 file, die je kunt md5sum'men.

Als je die tar aan de andere kant controleert, heb je de garantie dat de tar goed is aangekomen.

dd kan prima 1 file / blockdevice / iets anders, maar altijd maar 1. Dus moet je ze bij elkaar in 1 file proppen.

[LinuX-TUX]

Sneiker schreef op maandag 14 februari 2011 @ 16:04:
[...]


Omdat je dan niet meer goed de md5sum kan doen volgens mij. Waardoor je niet zou kunnen aantonen dat het precies de zelfde file is. Wat ik dus wel wil

Waarom zou de md5sum dan veranderen? Denk je dat als ik een gedownloade iso van ubuntu 7 keer rename en 2 keer heen en weer kopieer de md5sum veranderd? Dat zou behoorlijk irritant wezen als dat zo was

Zou ik continue corrupte ISO's hebben liggen

[ Voor 5% gewijzigd door LinuX-TUX op 14-02-2011 16:11 ]

[swbr]

Sneiker schreef op maandag 14 februari 2011 @ 16:04:
[...]


Omdat je dan niet meer goed de md5sum kan doen volgens mij. Waardoor je niet zou kunnen aantonen dat het precies de zelfde file is. Wat ik dus wel wil

Tuurlijk wel. Eerst bepaal je de md5 sum van je bestand. Dan tar/gzip/whatever je het bestand. Als je het bestand later weer uitpakt, moet de md5 sum nog steeds hetzelfde zijn als toen je begon.

[ Voor 42% gewijzigd door swbr op 14-02-2011 16:12 ]

[Kees]

Waarom wil je perse dd'en? Is gewoon cp niet goed genoeg?

En als je echt zo'n onbetrouwbare storage hebt en je gewoon 100% moet checken voor de md5sum dan kun je wel iets doen met find, dd (waarom in godsnaam dd?) en md5sums.

[Sneiker]

Voor een opdrachtgever moet ik de alle log files kopiëren. Nouja dat is dus redelijk een map vol. En ik dacht altijd dat je daar altijd dd voor moet gebruiken omdat dat juridisch goed is. Voor als er later ooit nog wat mee gedaan moet worden.

[Kees]

kopie = kopie, of je dat nu met dd doet of cp, het is 100% hetzelfde. Als je echt helemaal zeker wil zijn dat de kopie goed is, dan kun je md5sums vergelijken na de copy actie (hint: die veranderen niet tenzij je een error krijgt tijdens het kopieren). Ook zou je rsync ervoor kunnen gebruiken, die jast ook al een checksum over de file heen.

De reden dat ik denk dat dd ergens is blijven hangen is als je een digitaal forensisch onderzoek doet naar een harde schijf, dan maak je inderdaad eerst even een kopie met dd, en dan ga je op de kopie werken om op die manier niet het origineel te beschadigen/invalid te maken. Maar tenzij jouw werkgever de politie is, en de logfiles die je moet kopieren bewijs zijn in eoa rechtszaak en niet van jou, dan maakt het niet heel erg veel uit wat je doet, en als dat wel het geval is, dan zou ik zeggen; stap naar de digitale recherche, en doe dat niet zelf.

[Sneiker]

Ja maar het probleem is dus, de opdrachtgever weet niet of hij er een rechtszaak van wilt maken. Maar wilt er niet te veel geld aan uitgeven.

[LinuX-TUX]

Sneiker schreef op maandag 14 februari 2011 @ 16:51:
Ja maar het probleem is dus, de opdrachtgever weet niet of hij er een rechtszaak van wilt maken. Maar wilt er niet te veel geld aan uitgeven.

DD / image dan gewoon de partitie of schijf. Snap nog steeds uberhaupt niet wat je dan probeerd te doen, maar als je dan toch begint met 'ik wil alles zo authentiek mogelijk behouden' doe het dan ook van A tot Z. Ben je bang dat timestamps / last accessed tijden ed gaan veranderen?

[Kees]

Sneiker schreef op maandag 14 februari 2011 @ 16:51:
Ja maar het probleem is dus, de opdrachtgever weet niet of hij er een rechtszaak van wilt maken. Maar wilt er niet te veel geld aan uitgeven.

Koop een schijf die even groot of groter is en dd dan gewoon de hele disk.

[Rainmaker]

DD de partitie / het LV desnoods en zet het op een DVD / blueray.

[Sneiker]

Ben ik weer, ja dat kan ook allemaal maar ben net even bezig geweest met het script en heb me dit bedacht.

for A in `ls -R /test`; do dd if=$A of=/test2/$A; done

Maar wanneer dan moet het script in de map staan. Maar ik zou het script graag in een andere map willen hebben staan. + Nu gaat hij niet dieper dan de map /test.

Nu dacht ik gebruik find ipv ls maar dan komen er nog meer problemen.

[Kees]

Het kan allemaal wel, maar gebruik gewoon cp. Dit prutsen met dd zou mij, mocht ik een rechter zijn, alleen maar verbazen, want dd voegt helemaal 0,0 nada niets noppes de rien, nothing extra aan deze kopieeractie toe in termen van veiligheid, extra zeker zijn dat je alle data kopieert etc. Het is alsof je een foto van een dossier maakt, die inscanned, en het vervolgens uitprint om er een kopie van te maken terwijl je het ook gewoon onder een kopieermachine had kunnen leggen.

Gewoon 'cp [-a] /logs1 /logs2', en daarna kun je, als je het wil, gewoon met diff aan de gang gaan, of met md5sums die je opslaat.

Een klein voorbeeldje dan.

$ mkdir testlog1 testlog2
(even teslog1 met wat files gevult)
$ cp testlog1/* testlog2/
$ md5sum testlog1/*
d41d8cd98f00b204e9800998ecf8427e  testlog1/access.log
b4c117cb8c7186deb40b4b46fbdb3597  testlog1/access.log.1

$ md5sum testlog2/*
d41d8cd98f00b204e9800998ecf8427e  testlog2/access.log
b4c117cb8c7186deb40b4b46fbdb3597  testlog2/access.log.1

(goh, identiek wie had dat gedacht)
$ diff testlog1/ testlog2/
$ echo $?
0
(returncode 0 = ze matchen)

Als je een md5sum van de originele log hebt, en je geeft de rechter een kopie, dan kan hij met behulp van die md5sum zelf wel bepalen of het gelijk is. Ik snap niet waarom je nu zo moeilijk probeert te doen.

[LinuX-TUX]

Kees schreef op dinsdag 15 februari 2011 @ 11:39:
Het kan allemaal wel, maar gebruik gewoon cp. Dit prutsen met dd zou mij, mocht ik een rechter zijn, alleen maar verbazen, want dd voegt helemaal 0,0 nada niets noppes de rien, nothing extra aan deze kopieeractie toe in termen van veiligheid, extra zeker zijn dat je alle data kopieert etc. Het is alsof je een foto van een dossier maakt, die inscanned, en het vervolgens uitprint om er een kopie van te maken terwijl je het ook gewoon onder een kopieermachine had kunnen leggen.

Gewoon 'cp [-a] /logs1 /logs2', en daarna kun je, als je het wil, gewoon met diff aan de gang gaan, of met md5sums die je opslaat.

Een klein voorbeeldje dan.

$ mkdir testlog1 testlog2
(even teslog1 met wat files gevult)
$ cp testlog1/* testlog2/
$ md5sum testlog1/*
d41d8cd98f00b204e9800998ecf8427e  testlog1/access.log
b4c117cb8c7186deb40b4b46fbdb3597  testlog1/access.log.1

$ md5sum testlog2/*
d41d8cd98f00b204e9800998ecf8427e  testlog2/access.log
b4c117cb8c7186deb40b4b46fbdb3597  testlog2/access.log.1

(goh, identiek wie had dat gedacht)
$ diff testlog1/ testlog2/
$ echo $?
0
(returncode 0 = ze matchen)

Als je een md5sum van de originele log hebt, en je geeft de rechter een kopie, dan kan hij met behulp van die md5sum zelf wel bepalen of het gelijk is. Ik snap niet waarom je nu zo moeilijk probeert te doen.

Mee eens. Enige WAT dd zou KUNNEN bijdragen daarentegen is het volgende.

Er was eens een bestandje wat hij had verwijderd ... pas dan, echt ALLEEN dan heeft DD meerwaarde om te gebruiken. Anders totaal niet!

Meerwaarde: dd is direct copy DUS zou je theoretisch nog files van het FS kunnen recoveren achteraf.

---

@hieronder:
Touche. Heb eigenlijk dd nog nooit gebruikt voor files .... alleen voor partities & totale disks

[ Voor 3% gewijzigd door LinuX-TUX op 15-02-2011 12:00 ]

[Kees]

LinuX-TUX schreef op dinsdag 15 februari 2011 @ 11:58:
[...]
Mee eens. Enige WAT dd op zou KUNNEN leveren daarentegen is het volgende.

Er was eens een bestandje wat hij had verwijderd ... pas dan, echt ALLEEN dan heeft DD meerwaarde om te gebruiken. Anders totaal niets!

Meerwaarde: dd is direct copy DUS zou je theoretisch nog files van het FS kunnen recoveren achteraf.

Dan is het een meerwaarde als je de volledige disk/partitie/fs kopieert, maar dat wil hij niet, hij wil afzonderlijke files dd'en

[Sneiker]

Kees schreef op dinsdag 15 februari 2011 @ 11:59:
[...]

Dan is het een meerwaarde als je de volledige disk/partitie/fs kopieert, maar dat wil hij niet, hij wil afzonderlijke files dd'en

true, nou bedankt mannen . Ik heb het allemaal even voorgelegd.

[John_Glenn]

Als het om de juridische aspecten gaat (enne, ik ben geen jurist): tar en cp enzo garanderen niet dat de metadata hetzelfde blijft. Bij uitpakken van je tarball kan je bijvoorbeeld niet de ctime van de bestanden terugzetten. Ook een md5sum op bestandsniveau neemt alleen de data in aanmerking, niet de metadata.

Misschien dat de ctimes van belang zijn? Aanneembaar maken dat er niet met bestanden is geklooid, dat soort dingen? In dat geval heeft dd + md5sum van de hele partitie toch voordelen...