-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathddrutility.html
1410 lines (1316 loc) · 67.3 KB
/
ddrutility.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<!-- This manual is for ddrutility (version 2.8.1, 13 October 2022).
Copyright (C) 2012, 2013, 2014, 2015, 2016 Scott Dwyer.
This manual is free documentation: you have unlimited permission
to copy, distribute and modify it. -->
<!-- Created by GNU Texinfo 5.2, http://www.gnu.org/software/texinfo/ -->
<head>
<title>Ddrutility Manual</title>
<meta name="description" content="Ddrutility Manual">
<meta name="keywords" content="Ddrutility Manual">
<meta name="resource-type" content="document">
<meta name="distribution" content="global">
<meta name="Generator" content="makeinfo">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<link href="#Top" rel="start" title="Top">
<link href="#Index" rel="index" title="Index">
<link href="dir.html#Top" rel="up" title="(dir)">
<style type="text/css">
<!--
a.summary-letter {text-decoration: none}
blockquote.smallquotation {font-size: smaller}
div.display {margin-left: 3.2em}
div.example {margin-left: 3.2em}
div.indentedblock {margin-left: 3.2em}
div.lisp {margin-left: 3.2em}
div.smalldisplay {margin-left: 3.2em}
div.smallexample {margin-left: 3.2em}
div.smallindentedblock {margin-left: 3.2em; font-size: smaller}
div.smalllisp {margin-left: 3.2em}
kbd {font-style:oblique}
pre.display {font-family: inherit}
pre.format {font-family: inherit}
pre.menu-comment {font-family: serif}
pre.menu-preformatted {font-family: serif}
pre.smalldisplay {font-family: inherit; font-size: smaller}
pre.smallexample {font-size: smaller}
pre.smallformat {font-family: inherit; font-size: smaller}
pre.smalllisp {font-size: smaller}
span.nocodebreak {white-space:nowrap}
span.nolinebreak {white-space:nowrap}
span.roman {font-family:serif; font-weight:normal}
span.sansserif {font-family:sans-serif; font-weight:normal}
ul.no-bullet {list-style: none}
-->
</style>
</head>
<body lang="en" bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#800080" alink="#FF0000">
<h1 class="settitle" align="center">Ddrutility Manual</h1>
<a name="Top"></a>
<div class="header">
<p>
Next: <a href="#Introduction" accesskey="n" rel="next">Introduction</a>, Up: <a href="dir.html#Top" accesskey="u" rel="up">(dir)</a> [<a href="#Index" title="Index" rel="index">Index</a>]</p>
</div>
<a name="ddrutility"></a>
<h1 class="top">ddrutility</h1>
<p>This manual is for ddrutility (version 2.8.1, 13 October 2022).
</p>
<p>This documentation was created and is maintained as a texinfo file, and
translated to markdown for use on the ddrutiltiy Sourceforge Wiki page. The
navigation does not work on the Wiki page. You can download help.html from the
files section and open it with a web browser and the navigation will work.
</p>
<table class="menu" border="0" cellspacing="0">
<tr><td align="left" valign="top">• <a href="#Introduction" accesskey="1">Introduction</a>:</td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top">• <a href="#ddru_005ffindbad" accesskey="2">ddru_findbad</a>:</td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top">• <a href="#ddru_005fntfsbitmap" accesskey="3">ddru_ntfsbitmap</a>:</td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top">• <a href="#ddru_005fntfsfindbad" accesskey="4">ddru_ntfsfindbad</a>:</td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top">• <a href="#ddru_005fdiskutility" accesskey="5">ddru_diskutility</a>:</td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top">• <a href="#Important-Notes" accesskey="6">Important Notes</a>:</td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top">• <a href="#Reporting-Bugs" accesskey="7">Reporting Bugs</a>:</td><td> </td><td align="left" valign="top">
</td></tr>
<tr><td align="left" valign="top">• <a href="#Index" accesskey="8">Index</a>:</td><td> </td><td align="left" valign="top">
</td></tr>
</table>
<hr>
<a name="Introduction"></a>
<div class="header">
<p>
Next: <a href="#ddru_005ffindbad" accesskey="n" rel="next">ddru_findbad</a>, Previous: <a href="#Top" accesskey="p" rel="prev">Top</a>, Up: <a href="#Top" accesskey="u" rel="up">Top</a> [<a href="#Index" title="Index" rel="index">Index</a>]</p>
</div>
<a name="Introduction-1"></a>
<h2 class="chapter">1 Introduction</h2>
<a name="index-introduction"></a>
<p>Ddrutility is a linux based set of utilities designed to assist with data
recovery, specifically as a supplement to GNU ddrescue. Each utility has its own
version number followed by the date last updated. Note that most if not all of
these utilities need to be ran as root. It contains the following programs:
</p>
<p><code>ddru_findbad</code>
</p>
<p><code>ddru_ntfsbitmap</code>
</p>
<p><code>ddru_ntfsfindbad</code>
</p>
<p><code>ddru_diskutility</code>
</p>
<p><code>ddru_findbad</code> is actually the original ddrutility version 1.6. None of
its functionality has changed; only the name and documentation have been
changed, and some bug fixes and improvements have been done. It is a bash script
that will try to find which files are related to bad sectors in a ddrescue log
file. It relies on 3rd party utilities for its functions. It may not work on all
systems. It can be slow, and can be very slow if not unusable if there are a lot
of bad sectors in the list (it does not work well with a large error size).
While I will fix any bugs found in it, I do not plan on performing any major
updates or improvements of its functionality. It is possible (hopeful) that I
may create new utilities to replace it (or parts of it) in the future. These
utilities would not rely on 3rd party functions, and would be faster.
</p>
<p><code>ddru_ntfsbitmap</code> is a utility to extract the bitmap file from a NTFS
partition, and then process it and create a domain file to be used with
ddrescue. This would allow for only recovering the used portion of the
partition, and not spending time reading unused and unneeded data.
</p>
<p><code>ddru_ntfsfindbad</code> is a utility for NTFS partitions to find which files
are related to bad sectors in a ddrescue log file. You should use this for NTFS
partitions in place of the original ddru_findbad, as it is MUCH faster than the
original ddru_findbad, gives more useful output, and does NOT require any 3rd
party utilities. It will also do the best it can to work with a damaged file
system (and even give you an idea of how damaged).
</p>
<p><code>ddru_diskutility</code> is an advanced LINUX ONLY utility that can perform
several different functions on a disk, using some direct pass-through disk
commands. Current functions include device inquiry, sector reads, and read long
commands. It is meant for advanced users.
</p>
<hr>
<a name="ddru_005ffindbad"></a>
<div class="header">
<p>
Next: <a href="#ddru_005fntfsbitmap" accesskey="n" rel="next">ddru_ntfsbitmap</a>, Previous: <a href="#Introduction" accesskey="p" rel="prev">Introduction</a>, Up: <a href="#Top" accesskey="u" rel="up">Top</a> [<a href="#Index" title="Index" rel="index">Index</a>]</p>
</div>
<a name="ddru_005ffindbad-1"></a>
<h2 class="chapter">2 ddru_findbad</h2>
<a name="index-ddru_005ffindbad"></a>
<a name="index-ddru_005ffindbad-1"></a>
<p><code>ddru_findbad</code> is meant to be a compliment to gnuddrescue. It finds
which files are related to the bad sectors. It will also work with a home made
file of a bad sector list (see LOGFILE below). Note that ddru_findbad may not
work on a mounted drive or image.
</p>
<p>If you performed a rescue that had some leftover bad sectors, but the file
system seems ok and you are wondering what might still be damaged by the
unrecovered sectors, then this program is for you. The filesystem of the target
must be intact enough for ddru_findbad to work. If you are unable to mount the
target and view its directory, then ddrutility probably won’t work and will just
give errors. In this case you may have to run some sort of repair tools on the
target first and hope that the filesystem can be repaired to a working state.
Note that any repair tool ran on the target could possibly cause ddru_findbad to
have inaccurate results. It is recommended that you always make an extra copy of
the recovered copy and work with that copy.
</p>
<p><code>ddru_findbad</code> is not meant to be run on the drive that actually has the
bad sectors. It is meant to be ran against a recovered copy of the drive. FAT
and HFS+ will fail if ran against the actual drive, as ifind seems to feel the
need to actually read the sectors in question. NTFS and EXT seem to be processed
without trying to read the sectors in question, however understand that they
still will be trying to read the file table (which could have bad sectors) to
get results.
</p>
<p><code>ddru_findbad</code> must be run as root (sudo).
</p>
<p><code>ddru_findbad</code> works on NTFS, EXT2/3/4, FAT16/32, and HFS+ file systems
(note that EXT4 will report as EXT3).
</p>
<p><code>ddru_findbad</code> requires sleuthkit to be installed for normal operation.
Sleuthkit is not included as standard in current Ubuntu versions. (sudo apt-get
install sleuthkit)
</p>
<p><code>ddru_findbad</code> requires ntfs-3g to be installed for NTFS support. If it
is not available then NTFS partitions will not be able to be processed, and
errors may be produced if trying to do so. Ntfs-3g seems to be included in
current Ubuntu versions. (sudo apt-get install ntfs-3g)
</p>
<p><code>ddru_findbad</code> requires GNU fdisk to be installed to be able to process
GPT partitioned disks. If GNU fdisk is not available, then it will use fdisk,
but it will not be able to process GPT partitions and may produce errors if
trying to do so. GNU fdisk is not included as standard in current Ubuntu
versions. (sudo apt-get install gnu-fdisk)
</p>
<p>Ubuntu Rescue Remix contains the above requirements, so it should run on the
live cd.
</p>
<p><code>ddru_findbad</code> will work on a whole drive recovery, or a single
partition recovery. It will work with a target device or image file.
</p>
<p>Results are left in 4 main output files. Results_summary is a condensed sorted
summary file, and is probably the most useful output. Results_list is the main
output file. It contains information about every sector processed with one line
per sector. It is designed to be easily processed to obtain desired final
results (such as the summary file). Results_info contains information about the
partition table and file system(s) and can be expanded with the moreinfo option.
Results_debug is mostly for troubleshooting purposes and most error messages are
sent to it. If you request help for any problems with ddru_findbad I may ask for
these 4 files.
</p>
<p><code>ddru_findbad</code> makes several temporary files in the directory that it is
run from. It deletes them when finished. Do not mount the target and run
ddru_findbad from within the target, as that would cause writing to the target
and you probably don’t want that!
</p>
<p><code>ddru_findbad</code> does not knowingly write or alter any data on the target
drive and does not require the file system of the target to be mounted. However,
it makes calls to different 3rd party tools which SHOULDN’T do any writing for
what they are, but this has not been verified.
</p>
<p>Some errors or warnings may appear on screen when running. Don’t panic, some
errors can be normal, as long as there is a good output. I have tried to
eliminate all the errors that I have found, but I cannot test all possibilities.
Most error messages are sent to results_debug. If you question the error, please
feel to email or post on the homepage so that I can determine if it is something
I should work on.
</p>
<p>The format for running ddru_findbad is:
</p>
<div class="example">
<pre class="example">ddru_findbad <var>target</var> <var>logfile</var> [<var>options</var>]
</pre></div>
<p>Where:
</p><dl compact="compact">
<dt><var>target</var></dt>
<dd><p>The drive or partition if using a device (/dev/hda), or the name (and full path
if not in the current directory) of the image file (/media/mydrive/image.dd).
The target should be a copy or image of the original drive with bad sectors. It
should not be the actual drive with bad sectors! If you should so choose to run
it on the actual drive for some reason, note that FAT and HFS+ will not process
with actual bad sectors.
</p>
</dd>
<dt><var>logfile</var></dt>
<dd><p>The logfile from ddrescue. It can alternatively be a file containing a list of
the bad sectors, one sector number per line with no other text in the file. The
sector file can also contain bad sector ranges, with two sector numbers per line
separated by a space, being the first and last sector of the range. Note that
the sectors are in relation to either the whole disk or a single partition,
which depends on what the target is.
</p>
</dd>
</dl>
<p>ddru_findbad supports the following options:
</p>
<dl compact="compact">
<dt>‘<samp>-h</samp>’</dt>
<dt>‘<samp>--help</samp>’</dt>
<dd><p>Print an informative help message describing the options and exit.
</p>
</dd>
<dt>‘<samp>-v</samp>’</dt>
<dt>‘<samp>--version</samp>’</dt>
<dd><p>Print the version number and exit.
</p>
</dd>
<dt>‘<samp>-o <var>file</var></samp>’</dt>
<dt>‘<samp>--output <var>file</var></samp>’</dt>
<dd><p>The base name that will be at the beginning of the multiple results files. The
default is "results". The different output files will have extensions added to
them, for example results_summary, results_list, etc...
</p>
</dd>
<dt>‘<samp>-w <var>seconds</var></samp>’</dt>
<dt>‘<samp>--loopwait <var>seconds</var></samp>’</dt>
<dd><p>The number of seconds to wait before doing loop commands. You shouldn’t have to
change this. It is only used with image files. The default is 2. Increase this
if you get loop errors such as device busy.
</p>
</dd>
<dt>‘<samp>-s <var>bytes</var></samp>’</dt>
<dt>‘<samp>--sectorsize <var>bytes</var></samp>’</dt>
<dd><p>The sector size in bytes of the target drive or image. The default is 512. Note
that only a sector size of 512 has been tested, as I don’t have any drives of a
different sector size to test.
</p>
</dd>
<dt>‘<samp>-a</samp>’</dt>
<dt>‘<samp>--autooff</samp>’</dt>
<dd><p>Turns off automatic finding of partition types, and allows the user to manually
select what type the partition is for every partition. It also gives the option
to skip partitions. This could be useful if for some reason the program is
unable to properly find the partition type, or you have multiple partitions and
only want to process one of them. The user will be prompted for every partition
on what to do. This choice will follow the processing of the logfile, and if you
choose to process a partition and there are more after it, you will be prompted
again after the current partition is done processing.
</p>
</dd>
<dt>‘<samp>-m</samp>’</dt>
<dt>‘<samp>--moreinfo</samp>’</dt>
<dd><p>Will add what could be considered an insane amount of (mostly) useless data from
fsstat and fls to the results_info file. Note that at this time fls does not
work right on EXT4 (sleuthkit currently only supports ext2/3). If the file
system is large, moreinfo could cause the results_info file to get very big, and
could add a considerable (or insane) amount of processing time. Only for
advanced users, use this if you understand what output fsstat and fls give.
</p>
</dd>
<dt>‘<samp>-e</samp>’</dt>
<dt>‘<samp>--extraoutput</samp>’</dt>
<dd><p>Will produce more types of output files. The processing for this is not very
efficient at this time (it is actually horrible). If there are a lot of bad
sectors, this could take a considerable (or insane) amount of processing time.
If the quick or quickntfs option is enabled then extraout will process much
faster. Currently available with the EXTRAOUT option: Results_bysector lists the
bad sector groups with the files in each group.
</p>
</dd>
<dt>‘<samp>-q</samp>’</dt>
<dt>‘<samp>--quick</samp>’</dt>
<dd><p>Only processes the first and last sector of each group. This allows for a much
faster first run so you can get an idea of what files are involved. May provide
more useful output with the EXTRAOUT option to get the results_bysector output.
If the first and last sector of a group show the same file then it could be
assumed that all the sectors in between are the same (assume at your own risk).
This is most efficient if there are large sized groups of bad sectors. If most
of the bad sectors are in very small groups or individual sectors then this is
not efficient and will take nearly as long as a normal run.
</p>
</dd>
<dt>‘<samp>-Q</samp>’</dt>
<dt>‘<samp>--quickntfs</samp>’</dt>
<dd><p>The same as quick, except it processes NTFS partitions extra special. It uses
the ability of ntfscluster to rapidly check groups of sectors at once. This can
very quickly produce a FULL list of files related to bad sectors for NTFS
partitions, instead of of just checking the first and last sector of a group. As
with quick, it is still most efficient with large sector groups. Results for
NTFS partitions will not end up in the results_list file, only in
results_summary (and in results_bysector if the extra option is used).
</p>
</dd>
</dl>
<p>EXAMPLES:
</p>
<p>If your ddrescue command was:
</p><div class="example">
<pre class="example">ddrescue /dev/sda1 rescued_image rescued_logfile
</pre></div>
<p>Then the ddru_findbad command would be:
</p><div class="example">
<pre class="example">ddru_findbad rescued_image rescued_logfile
</pre></div>
<p>If your ddrescue command was:
</p><div class="example">
<pre class="example">ddrescue /dev/sda /dev/sdb rescued_logfile
</pre></div>
<p>Then the ddru_findbad command would be:
</p><div class="example">
<pre class="example">ddru_findbad /dev/sdb rescued_logfile
</pre></div>
<p>NOTE: It is important that the source for ddru_findbad is the same as the
ddrescue outfile. Do not use /dev/sdb in the ddrescue command and then /dev/sdb1
in the ddru_findbad command. This would cause very inaccurate results.
</p>
<p>It does not matter if the source for ddru_findbad is a disk or image, a
partition or a whole disk, as ddru_findbad will automatically process it as long
as it matches the format used to describe the ddrescue outfile.
</p>
<hr>
<a name="ddru_005fntfsbitmap"></a>
<div class="header">
<p>
Next: <a href="#ddru_005fntfsfindbad" accesskey="n" rel="next">ddru_ntfsfindbad</a>, Previous: <a href="#ddru_005ffindbad" accesskey="p" rel="prev">ddru_findbad</a>, Up: <a href="#Top" accesskey="u" rel="up">Top</a> [<a href="#Index" title="Index" rel="index">Index</a>]</p>
</div>
<a name="ddru_005fntfsbitmap-1"></a>
<h2 class="chapter">3 ddru_ntfsbitmap</h2>
<a name="index-ddru_005fntfsbitmap"></a>
<a name="index-ddru_005fntfsbitmap-1"></a>
<p>Ddru_ntfsbitmap is a utility that will extract the bitmap file from an NTFS
partition, and then create a rescue domain file to use with ddrescue. This will
allow recovering only the used portion of an NTFS partition. Other normal
cloning utilities (such as clonezilla, or at least I think clonezilla uses
something similar) use a similar method to speed up the cloning process.
</p>
<p>Ddru_ntfsbitmap requires that a version of ddrescue that includes ddrescuelog is
installed (ddrescue version 1.15 and up). It does not make any other calls to
3rd party utilities.
</p>
<p>The bitmap file is just a map of what clusters are used and free on the
partition. Consider the map as 0’s and 1’s, the 0’s mean unused clusters and the
1’s mean used clusters. If any sectors of the bitmap file are not readable by
ddrescue (or were not tried), then they will be filled with ones (FF) in the
recovered bitmap output file. A section that is all ones (FF) is considered as
used clusters, and therefore the corresponding data will be copied.
Ddru_ntfsbitmap fills all bad (or untried) bitmap sector(s) in the output file
with ones to insure that no needed data is missed during the recovery process,
although it could cause extra data to be copied (better safe than sorry).
</p>
<p>Since the domain logfile that is created relies on the bitmap file from the NFTS
partition, it would be affected by any sort of corruption that could have
happened to the bitmap file caused when the filesystem was running. So I can
offer no guarantee that the results will be accurate. All I can say is that the
idea works, and the results SHOULD be good. The safest way to make sure of the
best possible data recovery would be to continue on without the domain file
after you got as far as you could with it.
</p>
<p>However, in addition to saving time, there COULD be another benefit to not
continuing on without the domain file in certain cases. If you zero fill all the
bad and untried areas of the target, then that could possibly get rid of
"garbage" data in the free space. This could possibly make file recovery easier
for programs that scan the whole disk looking for files (such as photorec).
</p>
<p>Ddru_ntfsbitmap will show the percentage of used vs free space of the partition
after processing the bitmap file, so you can get an idea of how much time and
effort you may be saving. You can also get this number again later on by running
ddrecuelog against the domain_logfile.
</p><div class="example">
<pre class="example">ddrescuelog -t domain_logfile
</pre></div>
<p>In the results, "rescued" will = used space that you are trying to recover, and
"non-tried" will = free space that you are ignoring. When your rescue percentage
reaches the percentage of used space, then you should have recovered the needed
data, except for any errors of course. But you must have used the domain_logfile
in all of the ddrescue commands up to this point for this percentage match to be
accurate. After you reach this point and ddrescue exits, and you have done all
the rescuing of the used portion that you can or wish to (retries, no-split,
ect...), you could leave out the domain_logfile from the command and continue to
recover all of the remaining partition/drive if desired.
</p>
<p>Ddru_ntfsbitmap uses ddrescue for all the reads and also creates logfiles, so
that you can run it as many times as you wish/need with different ddrescue
options on the same recovery attempt without unneeded disk reads. However, you
may need to use the –restart option to delete all of the important files at the
beginning of a new run so that there are no issues caused by leftover files. If
you used an incorrect option, or there are leftover files from a previous rescue
that you do not realize, either case can cause weird results or errors, and this
option should clear that up and give you a fresh start without having to
manually delete the files. If you are getting an error or result that doesn’t
make sense, try the –restart option.
</p>
<p>While ddru_ntfsbitmap will only try to read any area once while reading the
bitmap file, the downside is that when you start the actual rescue attempt,
those areas will be read again. But this should be a fairly small portion of the
disk. For instance, at a standard 4k cluster size, a 500GB drive bitmap file
would be approximately 16MB (0.003%).
</p>
<p>Ddru_ntfsbitmap will create several output files in the directory where it is
ran. They are required if you need to run ddru_ntfsbitmap again on the same
drive with different ddrescue options to get the best bitmap file recovery. They
can be deleted if you aquired a successful domain_logfile (but don’t delete the
domain_logfile until you have your successful data recovery). They NEED TO BE
DELETED OR SWITCHED TO A DIFFERENT DIRECTORY if you are attempting a new rescue
of a different partition or a different disk. Also, if you do a command with the
wrong options that causes some error, you may want to also delete these files
and start over. The output files are as follows:
</p>
<dl compact="compact">
<dt><var>__bootsec</var></dt>
<dd><p>This is the recovered partition boot sector (512 bytes). It is needed to find
the location of the MFT, along with the sector and cluster size.
</p>
</dd>
<dt><var>__bootsec.log</var></dt>
<dd><p>This is the ddrescue logfile for the __bootsec file.
</p>
</dd>
<dt><var>__mftshort</var></dt>
<dd><p>This is the first 16 entries of the MFT (16KB). It is needed to find where the
bitmap file is located on the disk.
</p>
</dd>
<dt><var>__mftshort.log</var></dt>
<dd><p>This is the ddrescue logfile for the __mftshort file.
</p>
</dd>
<dt><var>__bitmapfile</var></dt>
<dd><p>This is the recovered NTFS bitmap file.
</p>
</dd>
<dt><var>_partX__bitmapfile.log</var></dt>
<dd><p>This is the ddrescue logfile for the NTFS bitmap file. There could be multiple
logfiles, each with its own part# (part0, part1...). Normally there should only
be one logfile, but if for some reason the NTFS bitmap file is fragmented on the
disk, there will be a separate logfile for every fragment.
</p>
</dd>
<dt><var>ntfsbitmap_rescue_report.log</var></dt>
<dd><p>This file contains all the results from ddrescuelog –show-status for all the
ddrescue reads used by ddru_ntfsbitmap, and also for the domain logfile(s).
</p>
</dd>
</dl>
<p>The format for running ddru_ntfsbitmap is:
</p>
<div class="example">
<pre class="example">ddru_ntfsbitmap <var>source_disk</var> <var>logfile</var> [<var>options</var>]
</pre></div>
<p>Where:
</p><dl compact="compact">
<dt><var>source_disk</var></dt>
<dd><p>The drive or partition that you are trying to recover. This needs to be the
EXACT same source as the ddrescue input file that you will be using for the
recovery.
</p>
</dd>
<dt><var>logfile</var></dt>
<dd><p>The name of the domain logfile that you wish to create to use with ddrescue.
</p>
</dd>
</dl>
<p>ddru_ntfsbitmap supports the following options:
</p>
<dl compact="compact">
<dt>‘<samp>-h</samp>’</dt>
<dt>‘<samp>--help</samp>’</dt>
<dd><p>Print an informative help message describing the options and exit.
</p>
</dd>
<dt>‘<samp>-v</samp>’</dt>
<dt>‘<samp>--version</samp>’</dt>
<dd><p>Print the version number and exit.
</p>
</dd>
<dt>‘<samp>-D</samp>’</dt>
<dt>‘<samp>--debug</samp>’</dt>
<dd><p>Turn on debugging and create a debug file. The name of this file is
<code>ntfsbitmap_debug.log</code>. It is mostly for my use in troubleshooting bugs. I
may ask for this file if someone reports a problem that I am unable to identify
from their description.
</p>
</dd>
<dt>‘<samp>-V</samp>’</dt>
<dt>‘<samp>--verbose</samp>’</dt>
<dd><p>Show additional information. Right now all this shows is the commands sent to
ddrescue. This could help if you are trying to pass options to ddrescue and it
is not working correctly.
</p>
</dd>
<dt>‘<samp>-g <var>clusters</var></samp>’</dt>
<dt>‘<samp>--mingap <var>clusters</var></samp>’</dt>
<dd><p>The minimum number of unused NTFS clusters between the used clusters. The
default is 0 (allow all gaps), and the maximum allowed value is 4096. Any number
higher than the maximum will be lowered to the maximum. The purpose of this
option is to bridge small gaps of unused space, which will make the output
domain logfile smaller, and possibly speed up reads a little bit, although the
speed increase may not be significant (if at all). This will, however, add some
extra reported used space, and cause more data to be read than needed. How much
data will depend on how many gaps there are of the size chosen. The benefit of
using this option would vary for every situation, and is not yet proven. A
typical NTFS cluster is 8 sectors (but can vary), so with a sector size of 512,
a value of 16 would be 64KiB. A value of 256 would be 1MiB. A value of 4096
would be 16MiB. The idea is to use the lowest number that may give some benefit.
</p>
<p>If you are considering using this option, I would recommend running it with
different output domain logfile names to see how it is going to affect it. Once
ddru_ntfsbitmap has completed the first time, and you have not deleted any of
the output files, you can run it multiple times afterwards and it will not
perform any additional reads (unless you specify retries in the ddrescue
options). For instance:
</p>
<div class="example">
<pre class="example">ddru_ntfsbitmap /dev/sda1 domain_logfile
ddru_ntfsbitmap /dev/sda1 -g 16 domain_logfile16
ddru_ntfsbitmap /dev/sda1 -g 256 domain_logfile256
ddru_ntfsbitmap /dev/sda1 -g 4096 domain_logfile4096
</pre></div>
<p>You can then examine the output files to see the differences, and most notably
see the size difference of the files. You can also use the 3rd party tool
ddrescueview to view the output domain logfiles to help see a visual difference.
Also, PAY ATTENTION to the used percentage reported at the end of each run. If
the used percentage jumps up too much, then any benefit is completely lost and
you should use a lower value. I would like to restate that any benefit of using
this option is not yet proven, and using a number too high will have the
opposite effect.
</p>
</dd>
<dt>‘<samp>-i <var>bytes</var></samp>’</dt>
<dt>‘<samp>--inputoffset <var>bytes</var></samp>’</dt>
<dd><p>Set input offset (partition offset). This is needed if doing a whole drive
recovery, to specify the offset of the NTFS partition. You need to specify this
offset if you will be using an input such as "/dev/sda". You can get this offset
by doing a little math on an "fdisk -lu" command (the "u" gives the results in
sectors, which is needed for this to work). Let’s look at the following results
from "fdisk -lu /dev/sda", where /dev/sda is the source disk you wish to
recover.
</p>
<div class="example">
<pre class="example">Disk /dev/sda: 5 GB, 5362882560 bytes
255 heads, 63 sectors/track, 652 cylinders, total 10474380 sectors
Units = sectors of 1 * 512 = 512 bytes
Device Boot Start End Blocks Id System
/dev/sda1 2048 10485759 5245191 7 HPFS/NTFS
Warning: Partition 1 does not end on cylinder boundary.
</pre></div>
<p>This tells us that the NTFS partition /dev/sda1 starts at sector 2048. The units
tells the sector size, which is 512 bytes. So multiply the unit size (512) by
the start (2048), which gives us 1048576. This number is the offset in bytes,
which is what you supply to this option. So your ddru_ntfsbitmap command would
look something like this:
</p>
<div class="example">
<pre class="example">ddru_ntfsbitmap /dev/sda -i 1048576 domain_logfile
</pre></div>
<p>If you do not supply the correct offset, you will get an error stating the boot
sector ID is not NTFS, and the program will exit. The boot sector file and the
corresponding logfile will also be deleted (files will not be deleted if using
the –debug option).
</p>
</dd>
<dt>‘<samp>-o <var>"options"</var></samp>’</dt>
<dt>‘<samp>--options <var>"options"</var></samp>’</dt>
<dd><p>Ddrescue options to pass directly to ddrescue. Use quotes around the whole
string of options. For example:
</p>
<div class="example">
<pre class="example">ddru_ntfsbitmap /dev/sda1 domainfile --options "--direct --no-split"
</pre></div>
<p>These options will be passed to all calls to ddrescue. Note that you cannot use
the options <code>--input-position</code>, <code>--output-position</code>, or <code>--size</code>,
as these are used by ddru_ntfsbitmap for control. If you try to pass one of
these options, you will likely get an error message from ddrescue.
</p>
</dd>
<dt>‘<samp>-m <var>file</var></samp>’</dt>
<dt>‘<samp>--mftdomain <var>file</var></samp>’</dt>
<dd><p>Creates a separate additional domain file for the MFT (master file table). This
mft_domain_file can be used the same way as the examples below, just insert
mft_domain_file in place of the regular domain_logfile. The purpose of the
mft_domain_file is to allow recovering of the most important part of the
filesystem. You can use this before using the regular domain_logfile to attempt
to recover the MFT first, and then use the regular domain_logfile to then
recover the rest of the data. You could also use it later on to just focus on
the MFT. It could also be useful to see if the filesystem has errors, and how
many, which could help with your decision on how to proceed.
</p>
<p>To create both a regular domain and also a MFT domain file:
</p>
<div class="example">
<pre class="example">ddru_ntfsbitmap /dev/sda1 domain_logfile -m mft_logfile
</pre></div>
<p>Then to focus on the MFT your ddrescue command would be:
</p><div class="example">
<pre class="example">ddrescue -m mft_logfile /dev/sda1 recovered_ntfs_image rescue_logfile
</pre></div>
</dd>
<dt>‘<samp>-r</samp>’</dt>
<dt>‘<samp>--restart</samp>’</dt>
<dd><p>Delete all output files and start over. The default is for ddru_ntfsbitmap to
resume an attempt where one or more of the ddrescue reads had errors and you
wish to continue trying to get the most data (possibly using different ddrescue
options). However if you did a wrong option once, or had something left over
from a previous rescue you could get weird results or errors. This allows you to
start over without having to manually delete the previous files.
</p></dd>
</dl>
<br>
<br>
<p>EXAMPLES:
</p>
<p>PARTITION TO IMAGE-
</p>
<p>The simplest example is if recovering only the partition to an image file.
</p>
<p>Let’s start with the following fdisk -lu result:
</p>
<div class="example">
<pre class="example">Disk /dev/sda: 5 GB, 5362882560 bytes
255 heads, 63 sectors/track, 652 cylinders, total 10474380 sectors
Units = sectors of 1 * 512 = 512 bytes
Device Boot Start End Blocks Id System
/dev/sda1 2048 10485759 5245191 7 HPFS/NTFS
Warning: Partition 1 does not end on cylinder boundary.
</pre></div>
<p>The ddru_ntfsbitmap command would be something like:
</p>
<div class="example">
<pre class="example">ddru_ntfsbitmap /dev/sda1 domain_logfile
</pre></div>
<p>Your ddrescue command would be something like:
</p>
<div class="example">
<pre class="example">ddrescue -m domain_logfile /dev/sda1 recovered_ntfs_image rescue_logfile
</pre></div>
<br>
<br>
<p>WHOLE DISK TO DISK OR IMAGE SIMPLE-
</p>
<p>Let’s start with the following fdisk -lu result:
</p>
<div class="example">
<pre class="example">Disk /dev/sda: 5 GB, 5362882560 bytes
255 heads, 63 sectors/track, 652 cylinders, total 10474380 sectors
Units = sectors of 1 * 512 = 512 bytes
Device Boot Start End Blocks Id System
/dev/sda1 2048 10485759 5245191 7 HPFS/NTFS
Warning: Partition 1 does not end on cylinder boundary.
</pre></div>
<p>You will need to use the -i (–inputoffset) option, and you will need to do some
math (see the inputoffset option description for more detail). Multiply the
sector size (512) by the partition Start (2048) to get 1048576, which is the
input offset for the NTFS partition.
</p>
<p>Your ddru_ntfsbitmap command would be something like:
</p>
<div class="example">
<pre class="example">ddru_ntfsbitmap /dev/sda -i 1048576 domain_logfile
</pre></div>
<p>Your ddrescue command would be something like this respectively:
</p><div class="example">
<pre class="example">ddrescue -f -m domain_logfile /dev/sda /dev/sdb rescue_logfile
</pre></div>
<p>Or:
</p><div class="example">
<pre class="example">ddrescue -m domain_logfile /dev/sda recovered_disk_image rescue_logfile
</pre></div>
<p>If there is more than one NTFS partition on the drive, you would just repeat the
above process for each of them, with the proper input offset for each. You would
use the same rescue_logfile in the ddrescue command, but you would use a
separate domain_logfile for each separate NTFS partition accordingly.
</p>
<p>Important Note: When using the -i (–inputoffset) option, the first "track"
(32256 bytes or 63 * 512 byte sectors) of the disk is automatically included in
the created domain file. This first "track" contains the MBR, partition table,
and possibly more needed boot code. The reason this is included automatically is
so you shouldn’t have to worry about making a rescue copy that won’t boot due to
missing important stuff.
</p>
<br>
<br>
<p>WHOLE DISK TO DISK OR IMAGE WITH EXTRA PARTITIONS-
</p>
<p>If you are planning on recovering the entire disk structure including other
partitions, it starts to get a bit more tricky. But you may need to do this with
some Windows installations, as there may also be a smaller active boot partition
that contains the boot information for Windows, and this partition would need to
be copied for the OS to boot.
</p>
<p>Let’s start with the following fdisk -lu result:
</p>
<div class="example">
<pre class="example">Disk /dev/sda: 120 GB, 120031511040 bytes
255 heads, 63 sectors/track, 14593 cylinders, total 234436545 sectors
Units = sectors of 1 * 512 = 512 bytes
Device Boot Start End Blocks Id System
/dev/sda1 63 20466809 10233373 b FAT32
/dev/sda2 * 20466810 143331929 61424527 7 HPFS/NTFS
/dev/sda3 143331930 225247364 40949685 83 Linux
/dev/sda4 225247365 234436544 4586557 f Extended LBA
/dev/sda5 225247428 234436544 4586557 82 Linux swap
Warning: Partition 5 does not end on cylinder boundary.
</pre></div>
<p>The first step is to get the NTFS partition (sda2) offset, multiplying the Start
by the sector size (20466810 * 512 = 10479006720). So then your ddru_ntfsbitmap
command would be something like:
</p>
<div class="example">
<pre class="example">ddru_ntfsbitmap /dev/sda -i 10479006720 domain_logfile
</pre></div>
<p>Your ddrescue command would be something like this:
</p><div class="example">
<pre class="example">ddrescue -f -m domain_logfile /dev/sda /dev/sdb rescue_logfile
</pre></div>
<p>Now you want to also recover the FAT32 and Linux partitions. You need to do some
math again. For the FAT32 partition (sda1) multiply the start by the sector size
(63 * 512 = 32256). This is the input position you provide ddrescue. Next
subtract the start from the end, and then multiply that by the sector size
(20466809 - 63 = 20466746, * 512 = 10478973952). This is the size you provide
ddrescue.
</p>
<p>So now your next ddrescue command would be something like this:
</p><div class="example">
<pre class="example">ddrescue -f -i 32256 -s 10478973952 /dev/sda /dev/sdb rescue_logfile
</pre></div>
<p>And we do the same for the Linux partition. Input position = (143331930 * 512) =
73385948160, and size = ( (225247364 - 143331930) * 512) = 41940702208.
</p>
<p>Ddrescue command:
</p><div class="example">
<pre class="example">ddrescue -f -i 73385948160 -s 41940702208 /dev/sda /dev/sdb rescue_logfile
</pre></div>
<p>I am not going to get into the Extended partition, except to say that I am
pretty sure that you must copy the first part of it (starting at sda4 in this
case). I have probably covered what the average person will ever do with this
already.
</p>
<hr>
<a name="ddru_005fntfsfindbad"></a>
<div class="header">
<p>
Next: <a href="#ddru_005fdiskutility" accesskey="n" rel="next">ddru_diskutility</a>, Previous: <a href="#ddru_005fntfsbitmap" accesskey="p" rel="prev">ddru_ntfsbitmap</a>, Up: <a href="#Top" accesskey="u" rel="up">Top</a> [<a href="#Index" title="Index" rel="index">Index</a>]</p>
</div>
<a name="ddru_005fntfsfindbad-1"></a>
<h2 class="chapter">4 ddru_ntfsfindbad</h2>
<a name="index-ddru_005fntfsfindbad"></a>
<a name="index-ddru_005fntfsfindbad-1"></a>
<p>Ddru_ntfsfindbad is a utility for NTFS partitions to find which files are
related to bad sectors in a ddrescue log file. While it only works for NTFS
partitions, it is MUCH faster then the original ddru_findbad. It also gives more
useful output. And it does NOT require any 3rd party utilities. It will also do
the best it can to work with a damaged file system (and even give you an idea of
how damaged). While it may keep going if physical read errors are encountered,
it is designed to work using the recovered disk or image file, NOT the original
failing drive.
</p>
<p>While ddru_ntfsfindbad will process a damaged filesystem, it does require a few
things. It needs to know where the ntfs partition starts (not needed for
partition only image, as the location will be 0). It needs to be able to read
the partition boot sector (512 bytes). It needs to be able to read the first
entry of the MFT, or the first entry of the MFTMIRROR (1024 bytes). If it has
that information, then it will proceed as best it can. If there are no errors in
the MFT, the output results should be accurate. If there are errors in the MFT,
you may be in for a rough recovery as the MFT is very important to recovering
files.
</p>
<p>Ddru_ntfsfindbad does not process deleted MFT entries, as its purpose is not to
find deleted files. It will however process entries in the recycle bin, as they
are not truly deleted, although you will clearly see in the name that they are
in the recycle bin.
</p>
<p>The output file will tell you if the error was in a file or folder. If it was a
file, then most likely that means actual file damage. If the error was in a
folder, that is a bit different. That means that the folder is damaged and
likely has lost some of the files/folders that were in it, and by that I mean it
lost the link to them, not the files themselves. That means that when exploring
the filesystem they will not show up. As an example of what this could mean, I
have found that the recovery tool testdisk appears to need the folders to be
intact to find and recover files, while more advanced (and likely not free)
tools such as R-Studio will find them. Ddru_ntfsfindbad acts more like R-Studio,
as it doesn’t even look at the data contained in the folders. It builds the
folder paths from the inodes themselves (every inode has the number of it’s
parent inode, so a map can be built without needing any extra data from the
folder except the parent inode number listed in the actual MFT entry). Please
note that I am not endorsing or condemning any particular software here, only
making reference to examples that I have personally observed.
</p>
<p>As the output file shows what files have errors, any errors to the file $MFT
means that your filesystem is damaged (this will be at the very top of the list
if it has errors). As the MFT is critical in recovering the files, there is no
guarantee for recovery if it is damaged. Errors mean missing inode entries, and
if the entry was in use then you are missing something important. If the entry
was a file, then how to find the file on the disk is lost. The only way to
recover from a missing file entry is to scan the whole disk with a recovery
utility such as photorec, and these utilities can be hindered by file
fragmentation and by the fact that there could be error sections in the files
themselves (good luck). If the entry was a small file (about 800 bytes or less),
then the file was likely contained within the inode record itself, and will be
lost. If the missing entry was a folder, then the files and sub folders may
still exist, but they will be orphaned, and will not show up when normally
exploring the filesystem, although they may still be able to be recovered (and
the windows checkdisk utility might be able to fix the links). Errors in the MFT
can mean an uncertain recovery, and you will have to work for it to get all you
can.
</p>
<p>The normal output file is:
</p>
<dl compact="compact">
<dt><var>ntfsfindbad.log</var></dt>
<dd><p>This is a list of the files/folders that are found to have errors. Inode= the
NTFS inode number of the file/folder. Errors= how many separate contiguous error
sections there are. Errorsize= the total size of all the combined errors in
bytes. Note that while this number would normally be a multiple of the sector
size, if an error was in the last sector and the file did not fill the whole
sector, only the used portion would be included in the errorsize. FILE or FOLDER
tells if it is a file or a directory. Name= the full path file/folder name. It
should normally start with "./" which indicates the path makes it to the top
level. If it does not start with "./", then it is considered to be orphaned,
meaning that the path does not make it to the top level directory. Errors in the
MFT can cause this.
</p>
</dd>
</dl>
<p>The format for running ddru_ntfsfindbad is:
</p>
<div class="example">
<pre class="example">ddru_ntfsbitmap <var>source</var> <var>logfile</var> [<var>options</var>]
</pre></div>
<p>Where:
</p><dl compact="compact">
<dt><var>source</var></dt>
<dd><p>The drive, partition, or image file that you have recovered. This needs to be
the EXACT SAME DESTINATION as the ddrescue output file that you used for the
recovery. If you copied /dev/sda to /dev/sdb, then use /dev/sdb as the source,
DO NOT USE a partition (/dev/sdb1)! If you do not use the exact same
destination, then it will not match the logfile and your results will be totally
inaccurate. If you only recovered the partition (/dev/sda1) to an image, then
you can simply supply that image file with no partition offset. If you are
supplying a drive or an image created from a whole drive, then you must supply
the correct partition offset (see –inputoffset for more info).
</p>
</dd>
<dt><var>logfile</var></dt>
<dd><p>The name of the logfile from ddrescue.
</p>
</dd>
</dl>
<p>ddru_ntfsfindbad supports the following options:
</p>
<dl compact="compact">
<dt>‘<samp>-h</samp>’</dt>
<dt>‘<samp>--help</samp>’</dt>
<dd><p>Print an informative help message describing the options and exit.
</p>
</dd>
<dt>‘<samp>-v</samp>’</dt>
<dt>‘<samp>--version</samp>’</dt>
<dd><p>Print the version number and exit.
</p>
</dd>
<dt>‘<samp>-D</samp>’</dt>
<dt>‘<samp>--debug</samp>’</dt>
<dd><p>Turn on debugging and create a debug file. The name of this file is
<code>ntfsfindbad_debug.log</code>. It is multi-level, meaning -D is level 1, -DD is
level 2 and so on. Please note that anything higher than level 2 can produce a
stupidly large debug file that you probably won’t know what to do with. This
file would normally be for my use in troubleshooting bugs. However, I have made
level 1 to provide some useful output to an advanced end user. Inode= the NTFS
inode number of the file/folder. Part= is the number of the file fragment,
starting with 0. If the file is not fragmented then there will only be a part0.
Offset= is the fragment start offset in bytes in relation to the start of the
partition. Fulloffset= is the fragment start offset in bytes as seen from the
beginning of the disk (will be the same as offset if only a partition recovery).
Size= is the length of the fragment in bytes. Type= is the data type for the
fragment (we are most interested in type=0x80, as this means actual file data.
If you want to know about the other types, I suggest you do a search for "ntfs
mft entry attribute types"). Errors= how many separate contiguous error sections
there are in the fragment. Errorsize= the total size of all the combined errors
in bytes for the fragment. There is no file name in this output, as that would
be listed in the main output file, you can reference that inode number. Any
inodes that were not able to be processed (hard errors) will also be listed here
with a warning message. Fulloffset= and size= are what you would use to compare
the fragment location to the rescue logfile, so that you could customize a
ddrescue command to make further attempts at recovering specific data.
</p>
</dd>
<dt>‘<samp>-V</samp>’</dt>
<dt>‘<samp>--verbose</samp>’</dt>
<dd><p>Show additional information. It is multi-level, meaning -V is level 1, -VV is
level 2 and so on. At this time I am only going to provide some info for level
1, as higher levels are more for my personal use, and anything above level 2
will probably not be useful to you. Most of the level 1 verbose info is self
explanatory, except for "MFT hard errors". This is the number of MFT entries
that are corrupt in some way, and were not able to be processed (likely due to
bad sectors, but could be for other reasons beyond my control or knowledge).
This could give an idea of how damaged the filesystem is. If you use level 2,
then you will see a soft error count (they will also show as warnings in level 2
of debug). All I can say about soft errors is that it means the inode entry
passed the normal sanity checks for corruption, but then something stupid