General options (گزینه‌های عمومی)

-h, --help

این گزینه به dd_rescue می‌گوید که فهرستی از گزینه‌ها را چاپ کرده و خارج شود.

-V, --version

نمایش شماره نسخه و خروج.

-q, --quiet

به dd_rescue می‌گوید که خروجی کمتری تولید کند.

-v, --verbose

خروجی dd_rescue را پرحرف‌تر (مشروح‌تر) می‌کند.

-c 0/1, --color=0/1

مشخص می‌کند که آیا dd_rescue از رنگ‌ها استفاده کند یا خیر. به‌طور پیش‌فرض استفاده می‌کند، مگر اینکه نوع پایانه از TERM ناشناخته یا dumb باشد یا به -m یا -mono ختم شود.

-f, --force

موجب می‌شود dd_rescue برخی از بررسی‌های اولیه سلامت (sanity checks) را نادیده بگیرد (مثلاً فعال کردن خودکار جهت معکوس هنگامی که پرونده ورودی و خروجی یکی هستند و ipos < opos).

-i, --interactive

به dd_rescue می‌گوید که پیش از بازنویسی پرونده‌های موجود تأیید بخواهد.

Block sizes (اندازه‌های بلوک)

-b softbs, --softbs=softbs, --bs=softbs

اندازه بلوک (بزرگ‌تر) را به softbs بایت تنظیم می‌کند. dd_rescue داده‌ها را در بسته‌هایی با این اندازه منتقل می‌کند مگر اینکه خطای خواندن رخ دهد (یا به پایان پرونده ورودی یا حداکثر اندازه انتقال رسیده باشد). مقدار پیش‌فرض برای این گزینه 64k برای buffered I/O و 1M برای direct I/O است.

-B hardbs, --hardbs=hardbs, --block-size=hardbs

اندازه بلوک جایگزین (کوچک‌تر) را به hardbs بایت تنظیم می‌کند. هنگامی که dd_rescue با خطاهای خواندن مواجه شود، به رونوشت داده‌ها در بسته‌هایی با این اندازه بازمی‌گردد. مقدار پیش‌فرض 4k برای buffered I/O و ۵۱۲ بایت برای direct I/O است.
hardbs باید مساوی یا کوچک‌تر از softbs باشد. اگر هر دو اندازه بلوک یکسان باشند، هیچ سازوکار بازگشتی (و در نتیجه تلاش مجددی) هنگام خطاهای خواندن انجام نخواهد شد.

-y syncsize, --syncfreq=syncsize

به dd_rescue می‌گوید که روی پرونده خروجی به‌ازای هر syncsize بایت، fsync() را فراخوانی کند (به مضربی از بلوک‌های با اندازه softbs گرد خواهد شد). همچنین نشانگر پیشرفت را حداقل با همین تناوب به‌روزرسانی می‌کند. به‌طور پیش‌فرض، syncsize روی ۰ تنظیم شده است، به این معنی که fsync() تنها در پایان عملیات رونوشت فراخوانی می‌شود.

موقعیت‌ها و طول (Positions and length)

-s ipos, --ipos=ipos, --input-position=ipos

موقعیت شروع infile را روی ipos تنظیم می‌کند. توجه داشته باشید که ipos بر حسب بایت مشخص می‌شود (اما پسوندها نیز قابل استفاده‌اند، بالا را ببینید)، نه بر اساس بلوک‌هایی با اندازه softbs یا hardbs. مقدار پیش‌فرض برای این گزینه 0 است. هنگام استفاده از رونوشت‌برداری در جهت معکوس، ipos با مقدار 0 به صورت ویژه در نظر گرفته شده و به معنای انتهای پرونده است.
موقعیت‌های منفی به پیام خطا منجر می‌شوند.

-S opos, --opos=opos, --output-position=opos

موقعیت شروع outfile را روی opos تنظیم می‌کند. در صورت عدم تعیین، opos روی ipos تنظیم می‌شود، بنابراین آفست‌های پرونده در پرونده ورودی و خروجی یکسان خواهند بود. برای رونوشت‌برداری در جهت معکوس، تعیین صریح opos برابر با 0، موقعیت را در انتهای پرونده خروجی قرار می‌دهد.

-x, --extend, --append

تفسیر موقعیت خروجی را طوری تغییر می‌دهد که از انتهای پرونده خروجی موجود شروع شود، و الحاق به پرونده را تسهیل می‌کند. اگر پرونده خروجی وجود نداشته باشد، خطا گزارش شده و اجرای dd_rescue متوقف خواهد شد.

-m maxxfer, --maxxfer=maxxfer, --max-size=maxxfer

حداکثر تعداد بایت‌هایی را مشخص می‌کند (پسوندها اعمال می‌شوند، اما بر حسب بلوک شمارش نمی‌شود) که dd_rescue رونوشت می‌کند. اگر پیش از انتقال maxxfer بایت، انتهای پرونده (EOF) فرا برسد، این گزینه بدون هشدار نادیده گرفته خواهد شد.

-M, --noextend

به dd_rescue می‌گوید که پرونده خروجی را گسترش ندهد. این گزینه به‌ویژه هنگام بازنویسی پرونده با داده‌های تصادفی یا صفرها برای امحای امن داده‌ها مفید است. اگر پرونده خروجی وجود نداشته باشد، یک پیام خطا تولید شده و برنامه متوقف می‌شود.

مدیریت خطا (Error handling)

-e maxerr, --maxerr=maxerr

به dd_rescue می‌گوید که پس از مواجهه با maxerr خطای خواندن، خارج شود. به طور پیش‌فرض، این مقدار روی 0 تنظیم شده است که باعث می‌شود dd_rescue تلاش کند تا رسیدن به EOF (یا انتقال maxxfer بایت) به پیشروی ادامه دهد.

-w, --abort_we

باعث می‌شود dd_rescue با هر خطای نوشتن متوقف شود. به طور پیش‌فرض، هنگام خطاهای گزارش‌شده در نوشتن، dd_rescue تلاش می‌کند بلوک‌ها را با نوشتن در اندازه‌های کوچکتر بازنویسی کند، تا یک خرابی کوچک در بلوکی بزرگتر باعث نوشته نشدن کل بلوک نشود. توجه داشته باشید که این موضوع ممکن است به طور مشابه توسط هسته سیستم‌عامل شما در نوشتن‌های بافری مدیریت شود بدون آنکه کاربر یا dd_rescue متوجه شوند؛ منطق تلاش مجدد در نوشتن در dd_rescue بیشتر برای ورودی/خروجی مستقیم (direct I/O) سودمند است که در آن خطاهای نوشتن را می‌توان به طور قابل اتکا شناسایی کرد.
تشخیص خطای نوشتن در حالت نوشتن بافری نامطمئن است؛ هسته وضعیت موفقیت را گزارش می‌کند و ردپای عملیات ناموفق writeback ممکن است بعداً فقط در syslog شما ظاهر شود. dd_rescue با فراخوانی fsync() و بررسی دقیق مقادیر بازگشتی فراخوانی‌های fsync() و close() تلاش می‌کند متوجه این امر شود.
توجه داشته باشید که dd_rescue در صورتی که نوشتن در پرونده خروجی به گزارش نبود فضای کافی توسط سیستم‌عامل منجر شود، خارج می‌شود.

پرونده‌های پراکنده و پرهیز از نوشتن (Sparse files and write avoidance)

-A, --alwayswrite

رفتار dd_rescue را تغییر می‌دهد تا در صورت عدم امکان خواندن پرونده ورودی، صفرها را در پرونده خروجی بنویسد. به طور پیش‌فرض، برنامه تنها از آن رد می‌شود و هر محتوایی را که قبلاً در آن موقعیت در پرونده خروجی بوده باقی می‌گذارد. رفتار پیش‌فرض ممکن است مطلوب باشد، اگر مثلاً عملیات پیشین رونوشت‌برداری داده‌های سالمی را در جای خود قرار داده باشد؛ اما اگر پرونده خروجی حاوی اطلاعات زائد (یا اطلاعات حساس) باشد که بهتر است با صفر بازنویسی شوند، ممکن است نامطلوب باشد.

-a, --sparse

باعث می‌شود dd_rescue به دنبال بلوک‌های خالی (حداقل به اندازه نصف softbs) یعنی بلوک‌های پر از صفر بگردد. به جای نوشتن آن صفرها در پرونده خروجی، به سمت جلو در پرونده خروجی جهش می‌کند، که به ایجاد یک پرونده پراکنده (sparse file) و صرفه‌جویی در فضای سیستم پرونده خروجی (در صورت پشتیبانی از پرونده‌های پراکنده) می‌انجامد. توجه داشته باشید که اگر پرونده خروجی از قبل موجود باشد و در مکانی که صفرها نادیده گرفته می‌شوند داده ذخیره شده باشد، این امر منجر به یک رونوشت ناکامل خواهد شد به طوری که پرونده خروجی در مکان‌هایی که بلوک‌های صفر جهش شده‌اند با پرونده ورودی تفاوت خواهد داشت. dd_rescue تلاش می‌کند این موضوع را تشخیص دهد و هشدار صادر کند، اما مانع از رخ دادن آن نمی‌شود. هنگام کار با پرونده‌های پراکنده، succxfer داده‌های واقعاً نوشته‌شده را گزارش می‌دهد، نه بخش‌هایی که در حین نوشتن نادیده گرفته شده‌اند.

-W, --avoidwrite

باعث می‌شود dd_rescue پیش از نوشتن، یک بلوک (به اندازه softbs) را از پرونده خروجی بخواند. اگر این بلوک از قبل با داده‌ای که قرار است روی آن نوشته شود یکسان باشد، عملاً از نوشتن آن صرف‌نظر می‌شود. این گزینه می‌تواند برای دستگاه‌هایی مفید باشد که برای نمونه نوشتن روی آنها باید محدود شود (مثلاً چون ممکن است بر طول عمر باقی‌مانده تأثیر بگذارد یا بسیار کندتر از خواندن است).

-@ readtime, --sparse_nonslow=readtime

بهینه‌سازی برای رونوشت‌های پراکنده است. هنگامی که برای پاکسازی یک دستگاه (یا پارتیشن) با بازنویسی روی خودش استفاده می‌شود، گزینه -a (--sparse) به خوبی می‌تواند برای جلوگیری از نوشتن صفرها روی فضای تخصیص‌نیافته (مثلاً در SSDها) استفاده شود. اما اگر بلوک‌ها از قبل تخصیص یافته باشند و کاملاً صفر باشند، و خواندن آنها بسیار کند باشد، ممکن است بخواهیم استثنا قائل شویم و آنها را دوباره با صفر بازنویسی کنیم. می‌تواند این حالت را از طریق کند بودن خواندن تشخیص دهد. بنابراین با استفاده از این گزینه، می‌توان یک حد (به ثانیه) برای زمانی که خواندن ممکن است طول بکشد پیش از اینکه نوشتن صفر در حالت sparse انجام شود، تعیین کرد. ممکن است بخواهید هنگام احیای SSDها این مقدار را روی حدود ۳ تنظیم کنید.

بهینه‌سازی‌های دیگر (Other optimization)

-R, --repeat

به dd_rescue می‌گوید تنها یک بلوک (به اندازه softbs) را بخواند و سپس آن را مکرراً در پرونده خروجی بنویسد. توجه داشته باشید که این کار منجر به عدم رسیدن به EOF در پرونده ورودی می‌شود و باید همراه با یک حد برای اندازه انتقال (گزینه‌های -m یا -M) یا هنگام پر کردن کامل یک دستگاه خروجی استفاده شود.
اگر نام پرونده ورودی برابر با "/dev/zero" باشد، این گزینه به طور خودکار فعال می‌شود.

-u, --rmvtrim

به dd_rescue دستور می‌دهد پرونده خروجی را پس از اتمام نوشتن حذف کرده و دستور FITRIM را روی سیستم پرونده‌ای که حاوی پرونده خروجی است اجرا کند. این کار تنها زمانی منطقی است که نوشتن صفرها (یا اعداد تصادفی) مد نظر باشد، بر خلاف انتقال محتوای مفید از یک پرونده دیگر. (اگر این گزینه همراه با یک پرونده ورودی معمولی و بدون استفاده از -f (--force) مشخص شود، dd_rescue درخواست تأیید خواهد کرد.) این گزینه می‌تواند برای اطمینان از اینکه تمام بلوک‌های خالی یک سیستم پرونده با صفر پر شده‌اند (به جای اینکه حاوی قطعات پرونده‌های حذف‌شده با اطلاعات بالقوه حساس باشند) استفاده شود.
فراخوانی ioctl مربوط به FITRIM (در لینوکس) به فضای ذخیره‌سازی اعلام می‌کند که فضای آزادشده را استفاده‌نشده در نظر بگیرد (مشابه ابزار fstrim یا گزینه discard) با صدور دستورهای ATA TRIM یا SCSI DISCARD/WRITE_SAME. این کار تنها با دسترسی مدیر سیستم (superuser) موفق خواهد بود (اما در غیر این صورت می‌توان این خطا را با خیال راحت نادیده گرفت). این ویژگی برای اطمینان از عملکرد کامل حافظه‌های فلش / SSD یا آزادسازی فضا در فضاهای ذخیره‌سازی thinly provisioned مفید است. توجه داشته باشید که FITRIM ممکن است روی سیستم‌های پرونده بزرگ طول بکشد، به‌ویژه اگر سیستم‌های پرونده با گزینه discard متصل نشده باشند و مدتی (مثلاً با fstrim) تریم نشده باشند. همه سیستم‌های پرونده و همه فضاهای ذخیره‌سازی مبتنی بر فلش از این قابلیت پشتیبانی نمی‌کنند.

-k, --splice

به dd_rescue می‌گوید به جای خواندن بلوک‌ها در بافر فضای کاربر، از عملیات رونوشت درون هسته‌ای لینوکس به صورت zerocopy یعنی splice() استفاده کند. توجه داشته باشید که این حالت عملیاتی مانع از پشتیبانی از شماری از قابلیت‌های dd_rescue می‌شود که به طور معمول قابل استفاده هستند، مانند عقب‌نشینی به اندازه‌های بلوک کوچکتر، پرهیز از نوشتن، حالت پراکنده، بهینه‌سازی تکرار، و رونوشت در جهت معکوس. هشداری برای آگاه کردن کاربر صادر می‌شود.

-P, --fallocate

باعث می‌شود dd_rescue تابع fallocate() را روی پرونده خروجی فراخوانی کند، و به سیستم پرونده بگوید چه میزان فضا را برای پرونده خروجی از پیش تخصیص دهد. (اندازه بر اساس موقعیت پایانی مورد انتظار، که از طول پرونده ورودی و maxxfer استنباط می‌شود، تعیین می‌گردد). در سیستم‌های پرونده‌ای که پشتیبانی می‌کنند، این امر منجر به تصمیم‌گیری‌های بهتر در تخصیص فضا شده و از تکه‌تکه شدن (fragmentation) جلوگیری می‌کند. (توجه داشته باشید که استفاده هم‌زمان از sparse به همراه fallocate() منطقی نیست.)
این گزینه تنها در صورتی در دسترس است که dd_rescue با پشتیبانی از fallocate() کامپایل شده باشد. برای پشتیبانی بهینه، باید با کتابخانه libfallocate کامپایل شده باشد.

-C rate,  --ratecontrol=rate

سرعت انتقال dd_rescue را به rate (در ثانیه) محدود می‌کند. پسوندهای معمول مجاز هستند. توجه داشته باشید که این گزینه میانگین سرعت را محدود می‌کند؛ سرعت لحظه‌ای ممکن است تا دو برابر این حد باشد. حالت پیش‌فرض نامحدود است. توجه داشته باشید که اگر می‌خواهید به کمتر از 32k (kB/s) بروید، باید از softblocksizeهای کوچک‌تر استفاده کنید.

Misc options (گزینه‌های گوناگون)

-r, --reverse

به dd_rescue دستور می‌دهد که رونوشت را در جهت معکوس، با شروع از ipos (که مقدار ویژه 0 در آن به معنای EOF یا انتهای پرونده است) و به سوی آغاز پرونده انجام دهد. این کار به‌ویژه زمانی سودمند است که پرونده ورودی دارای یک نقطه خراب (bad spot) باشد که پرش از روی آن ممکن است بسیار زمان‌بر باشد، بنابراین نزدیک شدن به آن از هر دو جهت زمان زیادی را ذخیره می‌کند (و ممکن است از آسیب بیشتر جلوگیری کند).
توجه داشته باشید که اگر پرونده ورودی و خروجی یکسان باشند و موقعیت ورودی کوچک‌تر از موقعیت خروجی باشد، dd_rescue به‌طور خودکار به رونوشت در جهت معکوس جابه‌جا می‌شود، مشابه هوشمندی‌ای که memmove() برای جلوگیری از دست رفتن داده هنگام رونوشت بخش‌های هم‌پوشان به کار می‌گیرد. گزینه -f / --force مانع از اجرای این هوشمندی می‌شود.

-p, --preserve

هنگام رونوشت پرونده‌ها، این گزینه موجب می‌شود فراداده‌های پرونده (مهر زمانی، مالکیت، حقوق دسترسی، xattrها) رونوشت شوند، مشابه گزینه‌ای به همین نام در برنامه cp.
توجه داشته باشید که ACLها و xattrها تنها در صورتی رونوشت خواهند شد که dd_rescue با پشتیبانی از libxattr همگردانی شده باشد و این کتابخانه بتواند به‌صورت پویا روی سامانه بارگذاری شود. همچنین توجه داشته باشید که ناتوانی در رونوشت ویژگی‌ها با -p یک شکست به شمار نمی‌رود و در نتیجه تأثیر منفی بر کد خروج dd_rescue نخواهد داشت. این رفتار را می‌توان با یک -p دوم تغییر داد، که منجر به خروج زودهنگام (کد ۲۶) برای خطاهای مالکیت و مجوز و کد خروج غیرصفر برای خطاهای رونوشت زمان‌ها و xattr می‌شود.

-t, --truncate

به dd_rescue دستور می‌دهد پرونده خروجی را با O_TRUNC باز کند، که باعث می‌شود پرونده خروجی (در صورتی که یک پرونده معمولی باشد) پیش از نوشتن به 0 بایت بریده (truncate) شود و تمام محتوای پیشین آن پاک گردد. به‌طور پیش‌فرض، dd_rescue محتوای قبلی را حذف نمی‌کند.

-T, --trunclast

به dd_rescue دستور می‌دهد پس از پایان عملیات رونوشت، اندازه پرونده خروجی را تا بالاترین موقعیت رونوشت‌شده کوتاه کند، و بدین ترتیب اطمینان حاصل شود داده‌ای فراتر از پایان داده‌های رونوشت‌شده در این اجرا وجود ندارد.

-d, --odir_in

به dd_rescue دستور می‌دهد infile را با O_DIRECT باز کند و بافرهای هسته را دور بزند. اگرچه این گزینه اثر منفی بر کارایی دارد (هسته برای ورودی/خروجی بافرشده پیش‌خوانی انجام می‌دهد)، اما موجب می‌شود خطاها سریع‌تر شناسایی شوند (هسته تلاش دوباره نمی‌کند) و واحدهای کوچک‌تر ورودی/خروجی (اندازه سکتور سخت‌افزاری، ۵۱۲ بایت برای بیشتر دیسک‌های سخت) را امکان‌پذیر می‌سازد.
ممکن است O_DIRECT در همه پلتفرم‌ها در دسترس نباشد.

-D, --odir_out

به dd_rescue دستور می‌دهد outfile را با O_DIRECT باز کند و بافرهای هسته را دور بزند. این کار تأثیر منفی چشمگیری بر کارایی دارد، زیرا برنامه بر خلاف ماهیت ناهمگام بازنویسی بافرشده، باید منتظر بنشیند تا عملیات نوشتن روی دیسک‌ها ثبت شود. در مقابل، وضعیت بازگشتی نوشتن از این طریق مطمئن است و قطعات کوچک‌تر ورودی/خروجی (اندازه سکتور سخت‌افزاری، ۵۱۲ بایت) امکان‌پذیر خواهند بود.

Logging (ثبت وقایع)

-l logfile, --logfile=logfile

مگر در حالت بی‌صدا، dd_rescue به‌طور پیوسته وضعیت عملیات رونوشت را در stderr به‌روزرسانی می‌کند. با این گزینه، این گزارش‌ها در logfile مشخص‌شده نیز نوشته می‌شوند. نویسه‌های کنترلی (برای بردن مکان‌نما به بالا جهت بازنویسی روی خطوط وضعیت موجود) در پرونده وقایع نوشته نمی‌شوند.

-o bbfile, --bbfile=bbfile

به dd_rescue دستور می‌دهد فهرستی از بلوک‌های خراب را در bbfile بنویسد. این پرونده شامل فهرستی از اعداد (ASCII) خواهد بود، یکی در هر سطر، که در آن اعداد آفست را بر حسب بلوک‌هایی با اندازه hardbs مشخص می‌کنند. قالب این پرونده با خروجی badblocks سازگار است. با استفاده از dd_rescue روی یک دستگاه بلوکی (پارتیشن) و تنظیم hardbs به اندازه بلوک سیستم‌پرونده‌ای که می‌خواهید بسازید، باید بتوانید bbfile را همراه با گزینه -l به mke2fs بدهید.

Multiple output files (چندین پرونده خروجی)

-Y ofileX, --outfile=ofileX, --of=ofileX

اگر می‌خواهید داده‌ها را به‌طور هم‌زمان در چندین پرونده رونوشت کنید، می‌توانید این گزینه را مشخص کنید. این گزینه می‌تواند چندین بار مشخص شود، بنابراین رونوشت‌های متعددی می‌توانند ایجاد شوند. توجه داشته باشید که این‌ها پرونده‌های خروجی ثانویه هستند؛ موقعیت پرونده آن‌ها با پرونده خروجی اصلی یعنی outfile مشترک است. خطاها هنگام نوشتن در یک پرونده خروجی ثانویه نادیده گرفته می‌شوند.

Data protection by overwriting with random numbers (محافظت از داده با بازنویسی با اعداد تصادفی)

-z RANDSEED, --random=RANDSEED

-Z RANDSEED, --frandom=RANDSEED

-2 RANDSEED, --shred2=RANDSEED

-3 RANDSEED, --shred3=RANDSEED

-4 RANDSEED, --shred4=RANDSEED

هنگامی که می‌خواهید یک پرونده، پارتیشن یا دیسک را با داده‌های تصادفی بازنویسی کنید، استفاده از /dev/urandom (در لینوکس) به عنوان ورودی ایده چندان خوبی نیست؛ این رابط برای فراهم آوردن پهنای باند بالا طراحی نشده است. بهتر است از یک مولد اعداد شبه‌تصادفی (PRNG) در فضای کاربری استفاده کنید. با گزینه -z / --random، از PRNG کتابخانه C استفاده می‌شود. با -Z / --frandom و گزینه‌های -2/-3/-4 / --shred2/3/4، یک PRNG مبتنی بر RC4 به کار گرفته می‌شود.
توجه داشته باشید که در این حالت، هیچ infile ای وجود ندارد، بنابراین نخستین آرگومان غیرگزینه‌ای همان پرونده خروجی است.
مولد PRNG به مقدار بذر (seed) نیاز دارد؛ مولد PRNG کتابخانه C یک عدد صحیح ۳۲ بیتی (۴ بایت) می‌گیرد؛ مولد PRNG مبتنی بر RC4 مقدار ۲۵۶ بایت می‌گیرد. اگر RANDSEED یک عدد صحیح باشد، آن عدد صحیح برای بذردهی به PRNG کتابخانه C استفاده خواهد شد. برای روش RC4، مولد PRNG کتابخانه C سپس ۲۵۶ بایت را برای بذردهی به آن تولید می‌کند. این کار داده‌های PRNG تکرارپذیر ایجاد می‌کند. مقدار RANDSEED برابر 0 استثنایی است؛ این مقدار مقداری بر پایه زمان کنونی و PID فرایند به همراه تصادفی‌سازی پردازنده (در صورت دسترسی) می‌سازد و برای چندین بار اجرای dd_rescue متفاوت خواهد بود.
اگر RANDSEED یک عدد صحیح نباشد، نام پرونده‌ای در نظر گرفته می‌شود که مقادیر بذر را می‌توان از آن خواند. dd_rescue مقدار ۴ یا ۲۵۶ بایت را از پرونده می‌خواند تا به PRNG کتابخانه C یا RC4 بذر بدهد. برای به دست آوردن اعداد شبه‌تصادفی خوب، استفاده از /dev/urandom برای بذردهی ایده مناسبی است.
حالت‌های -2/-3/-4 یا به عبارت دیگر --shred2/--shred3/--shred4 پرونده خروجی را چندین بار بازنویسی می‌کنند؛ پس از هر گذر، fsync() اطمینان می‌دهد که داده‌ها حتماً در پرونده ثبت شده‌اند. آخرین گذر در این حالت‌ها پرونده را با صفر بازنویسی می‌کند. دلیل انجام این کار پنهان کردن آسان‌تر بازنویسی داده‌های مهم، تسهیل بازیافت بلوک‌های خالی در سامانه‌های ذخیره‌سازی هوشمند (مانند SSDها) و فشرده‌سازی بهتر تصویر سیستم‌پرونده حاوی چنین داده‌هایی است.
با -2 / --shred2، یک گذر با PRNG تولیدشده با RC4 انجام می‌شود و سپس صفرها نوشته می‌شوند. با -3 / --shred3، دو گذر با اعداد تصادفی تولیدشده با RC4 PRNG و یک گذر صفر وجود دارد؛ دومین گذر PRNG اعداد معکوس (وارون بیتی) گذر نخست را می‌نویسد. گزینه -4 / --shred4 مانند -3 / --shred3 عمل می‌کند، همراه با یک گذر اضافی با اعداد تصادفی مستقل به عنوان گذر سوم.

Plugins (پلاگین‌ها)

از نسخهٔ 1.42 به بعد، dd_rescue دارای یک رابط برای پلاگین‌ها است. پلاگین‌ها توانایی تحلیل داده‌های رونوشت‌شده یا دگرگون ساختن آن‌ها را پیش از نوشته‌شدن دارند.

-L plugin1[=param1[:param2[:..]]][,plugin2[=..][,..]]

--plugins=plugin1[=param1[:param2[:..]]][,plugin2[=..][,..]]

پلاگین‌های plugin1 و... را بارگذاری کرده و پارامترها را به آن‌ها منتقل می‌کند. تمام پلاگین‌ها باید دست‌کم از پارامتر help پشتیبانی کنند و اطلاعاتی دربارهٔ نحوهٔ استفادهٔ خود ارائه دهند.
پلاگین‌ها ممکن است محدودیت‌هایی را بر dd_rescue تحمیل کنند. پلاگین‌هایی که داده‌ها را بررسی می‌کنند نمی‌توانند با splice کار کنند، زیرا splice از رونوشت داده‌ها به فضای کاربری جلوگیری می‌کند. همچنین این رابط در حال حاضر امکان رونوشت در جهت معکوس را فراهم نمی‌کند. برخی پلاگین‌ها ممکن است محدودیت‌های بیشتری در رابطه با تراز بودن داده‌ها در پرونده یا عدم استفاده از تشخیص بخش‌های خالی (sparse detection) اعمال کنند.
بخش PLUGINS را برای مرور کلی پلاگین‌های موجود مشاهده کنید.

null

پلاگین null (به نام ddr_null) کاری انجام نمی‌دهد، مگر اینکه گزینه‌های [no]lnchange یا [no]change را تعیین کنید که در این صورت پلاگین به سایر بخش‌ها اعلام می‌کند که طول خروجی یا داده‌های جریان را دگرگون می‌سازد. (با پیشوند no، دوباره به وضعیت پیش‌فرض عدم تغییر بازنشانی می‌شود.) این قابلیت ممکن است برای آزمایش یا برای تأثیرگذاری بر اینکه پلاگین hash کدام پرونده را برای خواندن/نوشتن ویژگی‌های گسترش‌یافته (extended attributes) در نظر بگیرد و همچنین تغییر رفتار پلاگین‌ها در زمینهٔ تشخیص حفره‌ها (hole detection) مفید باشد.
همچنین ddr_null_ddr به شما امکان می‌دهد debug را تعیین کنید که در این حالت صرفاً بلوک‌هایی را که از خود عبور می‌دهد گزارش می‌کند.

hash

هنگامی که پلاگین hash (که از این پس به عنوان ddr_hash یاد می‌شود) بارگذاری شود، یک هش رمزنگاری و در صورت تمایل یک HMAC بر روی داده‌های رونوشت‌شده محاسبه می‌کند و نتیجه را در پایان عملیات رونوشت نمایش می‌دهد. الگوریتم هش را می‌توان با تعیین alg[o[rithm]]=ALG انتخاب کرد که در آن ALG یکی از گزینه‌های md5، sha1، sha256، sha224، sha512، sha384 است. (برای دریافت فهرست، alg=help را مشخص کنید.) برای کوتاه‌سازی نحو دستور، می‌توان بخش =alg را حذف کرد.
برای سازگاری با نسخه‌های پیشین، به پلاگین hash می‌توان با نام قدیمی MD5 نیز اشاره کرد؛ در این حالت به‌طور پیش‌فرض از الگوریتم md5 استفاده می‌شود.
مقدار محاسبه‌شده باید با اجرای md5sum/sha256sum/... بر روی پرونده مقصد یکسان باشد (مگر اینکه تنها بخشی از پرونده را بنویسید)، اما با عدم دسترسی دوباره به پرونده (که احتمالاً حجیم است)، در زمان صرفه‌جویی می‌کند. پلاگین hash عملیات نوشتن متناوب (sparse) و آفست‌های دلخواه را به خوبی مدیریت می‌کند.

multipart=CHUNKSIZE به ddr_hash اعلام می‌کند که چندین چِک‌سام برای قطعاتی از پرونده به اندازه CHUNKSIZE محاسبه کند و سپس با ایجاد یک چِک‌سام از روی چِک‌سام‌های قطعات، آن‌ها را به یک چِک‌سام ترکیبی تبدیل نماید. این همان روشی است که چِک‌سام برای اشیاء چندبخشی S3 محاسبه می‌شود (با استفاده از هش md5)؛ خروجی در آنجا چِک‌سام ترکیبی به همراه یک خط تیره و تعداد بخش‌های ضمیمه‌شده است.
توجه داشته باشید که این ویژگی در نسخه 1.99.6 جدید است و هنوز شرایطی را که در آن آفست‌ها به همراه اندازه بلوک‌ها دقیقاً با CHUNKSIZE هم‌تراز نمی‌شوند، به طور کامل مدیریت نمی‌کند. پیاده‌سازی این بخش بعداً تکمیل خواهد شد. سایر ویژگی‌ها مانند بخش‌های append/prepend/hmac نیز به خوبی با محاسبه چِک‌سام چندبخشی کار نمی‌کنند.

پلاگین ddr_hash همچنین از پارامتر append=STRING پشتیبانی می‌کند که رشته مشخص‌شده STRING را پیش از محاسبه هش رمزنگاری به خروجی پیوست می‌نماید. با فرض اینکه STRING یک راز مشترک (shared secret) است، این قابلیت عملاً می‌تواند برای محافظت در برابر کسی که بدون آگاهی از راز، محتوا را تغییر می‌دهد (و هش را دوباره محاسبه می‌کند) بدون اینکه کسی متوجه شود، به کار رود. بنابراین این روش، راهکاری ارزان برای امضای رمزنگاری است (اما با رازهای مشترک در مقایسه با رمزنگاری کلید عمومی). از HMAC برای راهکاری تا حدی بهتر جهت امضای داده‌ها با راز مشترک استفاده کنید.
همچنین ddr_hash از prepend=STRING پشتیبانی می‌کند که احتمالاً حمله با جستجوی فراگیر (brute force) به آن نسبت به رشته پیوست‌شده سخت‌تر است. توجه داشته باشید که ddr_hash همواره مضاربی از اندازه بلوک الگوریتم هش را در ابتدا قرار می‌دهد و رشته STRING را با 0 تکمیل (pad) می‌کند تا مطابقت داشته باشد.

می‌توان از ddr_hash برای محاسبه یک HMAC (کُد احراز اصالت پیام مبتنی بر هش) به جای هش ساده استفاده کرد. HMAC از یک گذرواژه استفاده می‌کند که دو بار به داده‌ها اضافه و تبدیل شده و سپس دو بار هش می‌شود. تصور می‌شود که HMAC تا حدی بهتر از هش ساده (با یک راز ساده پیشوند شده) در برابر حملات گسترش طول (extension) یا برخورد (collision) محافظت می‌کند، بنابراین روش بهتری برای احراز اصالت داده‌ها با یک راز مشترک است. (در صورتی که به طرحی با بیش از یک راز نیاز داشته باشید، می‌توانید علاوه بر HMAC از append/prepend نیز استفاده کنید.)
هنگامی که HMAC با یکی از پارامترهای زیر فعال شود، هم هش ساده و هم HMAC توسط ddr_hash محاسبه می‌شوند. هر دو در کنسول/گزارش نمایش داده می‌شوند، اما HMAC به جای مقدار هش جهت نوشتن در پرونده CHECKSUMS یا در یک ویژگی گسترش‌یافته (extended attribute) یا برای بررسی اعتبار استفاده می‌شود (پایین را ببینید). hmacpwd=STRING راز مشترک (گذرواژه) را برای محاسبه HMAC تعیین می‌کند. ارسال رمز در خط فرمان این عیب را دارد که شل ممکن است برخی بایت‌ها را به عنوان نویسه‌های ویژه تفسیر کند و اینکه خط فرمان ممکن است برای همهٔ کاربران واردشده به سیستم قابل مشاهده باشد. hmacpwdfd=INT یک توصیف‌گر پرونده را تعیین می‌کند که رمز (گذرواژه) برای محاسبه HMAC از آن خوانده خواهد شد. تعیین 0 به معنای ورودی استاندارد (stdin) است که در این صورت ddr_hash حتی یک اعلان (prompt) برای شما نمایش می‌دهد... سایر اعداد ممکن است در حالتی مفید باشند که dd_rescue از برنامه دیگری فراخوانی شود که لوله‌ای را برای انتقال رمز باز می‌کند. hmacpwdnm=INNAME پرونده‌ای را تعیین می‌کند که راز مشترک (گذرواژه) از آن خوانده می‌شود. توجه داشته باشید که تمام بایت‌ها (تا حداکثر 2048 بایت) خوانده شده و مورد استفاده قرار می‌گیرند، از جمله فاصله‌های خالی انتهایی، بایت‌های 0 یا خطوط جدید.
لطفاً توجه داشته باشید که پلاگین ddr_hash در این مقطع تمهیدات زیادی برای جلوگیری از باقی ماندن گذرواژه/راز پیشوند/پیوست‌شده در حافظه یا نشت آن به پرونده swap/page در نظر نمی‌گیرد. (این مورد زمانی که بر روی پلاگین‌های رمزنگاری کار کنم بهبود خواهد یافت.)

پلاگین ddr_hash پارامتر output را می‌پذیرد که باعث می‌شود ddr_hash هش رمزنگاری را با همان قالبی که md5sum/sha256sum/... استفاده می‌کنند به stdout ارسال کند. شما همچنین می‌توانید outfd=INT را تعیین کنید تا پلاگین هش را در توصیف‌گر پرونده متفاوتی که با عدد صحیح INT مشخص شده بنویسد. توجه داشته باشید که ddr_hash همواره داده‌ها را در حالت دودویی پردازش می‌کند و این موضوع را به درستی با یک ستاره (*) در خروجی تولیدشده توسط output/outfd= نشان می‌دهد.
چِک‌سام را می‌توان با ارائه پارامتر outnm=OUTNAME در یک پرونده نیز نوشت. سپس پرونده‌ای با نام OUTNAME ایجاد خواهد شد و خطی سازگار با md5sum/sha256sum/... در پرونده درج می‌شود. اگر پرونده وجود داشته باشد و حاوی مدخلی برای این پرونده باشد، به‌روزرسانی خواهد شد. اگر پرونده موجود باشد و حاوی مدخلی برای این پرونده نباشد، مدخلی به آن افزوده می‌شود. در صورت حذف OUTNAME، از نام پرونده CHECKSUMS.alg (یا در صورت فعال بودن HMAC، از HMACS.alg) استفاده خواهد شد (alg با الگوریتم انتخابی جایگزین می‌شود). اگر چِک‌سام قابل نوشتن نباشد، هشداری نمایش داده شده و کد خروج dd_rescue غیرصفر خواهد شد.

چِک‌سام را می‌توان با استفاده از chknm=CHKNAME . اعتبارسنجی کرد. پرونده خوانده خواهد شد و ddr_hash به دنبال خطی سازگار با md5sum/sha256sum/... با نام پرونده منطبق می‌گردد تا چِک‌سام را از آن بردارد و با چِک‌سام محاسبه‌شده مقایسه کند. در صورت حذف NAME، همان پیش‌فرض توضیح داده شده در بالا (در outnm=...) استفاده خواهد شد. همچنین در صورت تمایل می‌توانید با تعیین گزینهٔ check چِک‌سام را از ورودی استاندارد بخوانید.
توجه داشته باشید که در هر صورت، بررسی تنها پس از اتمام عملیات رونوشت انجام می‌شود -- بنابراین یک چِک‌سام نادرست مانع از انجام رونوشت نخواهد شد. با این حال، کد خروج dd_rescue خطا را نشان خواهد داد. (اگر می‌خواهید از رونوشت داده‌ها با چِک‌سام معیوب به مقصد نهایی جلوگیری کنید، از یک مقصد موقت استفاده کنید که در صورت بروز خطا آن را حذف کنید و تنها زمانی که مقدار خروج dd_rescue برابر 0 بود آن را به مکان نهایی منتقل کنید؛ البته می‌توانید پیش‌تر برای آزمایش در dev/null/ نیز رونوشت بگیرید، اما خواندن پرونده ورودی برای بار دوم ممکن است بسیار پرهزینه باشد.)
اگر علاوه بر chknm (یا chk_xattr ) گزینهٔ chkadd تعیین شود، آنگاه چِک‌سام ناموجود به عنوان خطا گزارش نخواهد شد، بلکه در عوض مدخلی به پرونده چِک‌سام (یا xattr) اضافه می‌شود. عدم تطابق همچنان به عنوان خطا گزارش شده و پرونده چِک‌سام به‌روزرسانی نخواهد شد.

می‌توانید با استفاده از گزینهٔ set_xattr هش رمزنگاری را درون پرونده‌ها ذخیره کنید. هش به‌طور پیش‌فرض در ویژگی گسترش‌یافته user.checksum.ALG ذخیره می‌شود (در صورت فعال بودن HMAC، در user.hmac.ALG)، اما می‌توانید با تعیین set_xattr=XATTR.NAME نام ویژگی را تغییر دهید. اگر xattr قابل نوشتن نباشد، خطایی گزارش خواهد شد، مگر اینکه گزینهٔ fallb[ack][=CHKNAME] را نیز مشخص کنید. در این حالت، ddr_hash تلاش می‌کند چِک‌سام را در پرونده چِک‌سام CHKNAME بنویسد. (برای پیش‌فرض CHKNAME، گزینه outnm= در بالا را ببینید.)
گزینهٔ chk_xattr بررسی خواهد کرد که آیا هش محاسبه‌شده با مقدار خوانده‌شده از ویژگی گسترش‌یافته مطابقت دارد یا خیر. همان نام پیش‌فرض ویژگی اعمال می‌شود و شما به همین ترتیب می‌توانید آن را با chk_xattr=XATTR.NAME . تغییر دهید. عدم وجود ویژگی به عنوان خطا تلقی می‌شود (اگرچه در صورت مشخص کردن گزینه fallback، همان راهکار جایگزین امتحان می‌شود). یک چِک‌سام خراب نیز مسلماً خطا در نظر گرفته می‌شود، اما دقیقاً مانند checknm=CHKNAME مانع از رونوشت نخواهد شد. توضیحات مربوطه در آن بخش را ببینید.

توجه داشته باشید که برای output، outfd، outnm=، set_xattr، پلاگین ddr_hash از نام پرونده خروجی برای پیوست کردن چِک‌سام به آن استفاده خواهد کرد (چه با تنظیم xattr یا نام پرونده استفاده‌شده در پرونده چِک‌سام)، مگر اینکه پلاگینی در زنجیره بعد از ddr_hash مشخص کند که داده‌ها را تغییر می‌دهد. در این صورت هشدار می‌دهد و چِک‌سام را به نام پرونده ورودی مرتبط می‌کند، مگر اینکه پلاگین دیگری قبل از ddr_hash در زنجیره وجود داشته باشد که آن هم تغییر داده‌ها را نشان دهد. در این حالت پرونده‌ای وجود ندارد که چِک‌سام بتواند به آن مرتبط شود و ddr_hash خطایی را گزارش خواهد کرد.
به همین ترتیب برای chknm=، check، chk_xattr، پلاگین ddr_hash از نام پرونده ورودی برای دریافت چِک‌سام استفاده می‌کند (چه با خواندن xattr یا با جستجوی نام پرونده ورودی در یک پرونده چِک‌سام)، مگر اینکه پلاگینی در زنجیره قبل از ddr_hash وجود داشته باشد که تغییر داده‌ها را اعلام کند. در این صورت از نام پرونده خروجی استفاده خواهد شد، مگر اینکه پلاگین دیگری بعد از ddr_hash نیز تغییر داده‌ها را نشان دهد که در این حالت پرونده‌ای وجود ندارد که بتوان چِک‌سام را از آن دریافت کرد و بنابراین خطایی گزارش می‌شود.

اگر سیستم شما از ویژگی‌های گسترش‌یافته (extended attributes) پشتیبانی می‌کند، این ویژگی‌ها این مزیت را دارند که همراه با پرونده‌ها منتقل می‌شوند؛ بنابراین تغییر نام یا رونوشت (با dd_rescue -p) چِک‌سام را حفظ خواهد کرد. از سوی دیگر پرونده‌های چِک‌سام در همه جا قابل پردازش هستند (از جمله انتقال از طریق ftp یا http) و می‌توان آن‌ها را با PGP/GnuPG به‌صورت رمزنگاری‌شده امضا کرد.

لطفاً توجه داشته باشید که الگوریتم md5 دیگر برای محافظت مناسب در برابر تلاش‌های مخرب جهت پنهان‌سازی تغییر داده‌ها توصیه نمی‌شود؛ دیگر برای جلوگیری از برخورد هش‌ها (hash collisions) به اندازه کافی امن تلقی نمی‌شود. الگوریتم sha1 اندکی بهتر است، اما تا سال 2017 آن نیز شکسته شده است. توصیه می‌شود از خانواده هش‌های SHA-2 استفاده کنید. روی رایانه‌های 32بیتی، استفاده از sha256 را توصیه می‌کنم، در حالی که در سیستم‌های 64بیتی، sha512 سریع‌تر و در نتیجه بهترین گزینه است. توجه داشته باشید که در برخی پردازنده‌های x86-64 و اغلب پردازنده‌های armv8/aarch64 شتاب‌دهنده سخت‌افزاری برای sha256 وجود دارد، بنابراین در آنجا از sha512 سریع‌تر عمل می‌کند. ابزار dd_rescue این شتاب‌دهنده را شناسایی کرده و مورد استفاده قرار می‌دهد (از نسخه 1.99.16 به بعد).

پلاگین ddr_hash همچنین از کد و هش‌های HMAC برای اشتقاق کلیدها از گذرواژه‌ها با استفاده از PKCS5 PBKDF2 (تابع اشتقاق کلید مبتنی بر گذرواژه) پشتیبانی می‌کند که به شما امکان می‌دهد با استفاده از یک سالت (salt) و یک عملیات نسبتاً سنگین کشش کلید (key stretching)، محافظت در برابر گذرواژه‌های متوسط را بهبود بخشید. این ویژگی صرفاً برای آزمایش در نظر گرفته شده و ممکن است در آینده حذف شود. بنابراین در این صفحه راهنما مستند نشده است. برای خلاصه‌ای کوتاه از نحوه استفاده، تابع راهنمای داخلی را ببینید.

crypt

پلاگین crypt امکان رمزگذاری و رمزگشایی بلادرنگ داده‌ها را فراهم می‌کند. در حال حاضر این افزونه از انواع رمزهای AES پشتیبانی می‌نماید. صفحهٔ راهنمای ddr_crypt(1) را برای جزئیات بیشتر ببینید.

lzo (پلاگین lzo)

پلاگین lzo امکان فشرده‌سازی و خارج کردن داده‌ها از فشردگی را با استفاده از liblzo2 فراهم می‌کند. lzo الگوریتمی است که نسبت به بیشتر الگوریتم‌های دیگر سریع‌تر عمل می‌کند اما داده‌ها را به آن اندازه فشرده نمی‌سازد. برای جزئیات بیشتر به صفحه راهنمای ddr_lzo(1) مراجعه کنید.

ddr_lzma (پلاگین ddr_lzma)

پلاگین فشرده‌سازی/خارج کردن از فشردگی xz با استفاده از liblzma. از بیشتر گزینه‌های رایج ابزارهای xz پشتیبانی می‌کند. lzma الگوریتمی است که پرونده‌هایی با فشردگی بالا تولید می‌کند به قیمت مصرف بالای پردازنده (CPU) و حافظه در حین فشرده‌سازی. خارج کردن از حالت فشرده سریع است. برای جزئیات بیشتر به صفحه راهنمای ddr_lzma(1) مراجعه کنید.

Data destruction considerations (ملاحظات تخریب داده‌ها)

حالت‌های بازنویسی داده‌ها با اعداد شبه‌تصادفی به منظور حذف امن داده‌های حساس، عمداً تنها تعداد محدودی بازنویسی انجام می‌دهند. در حالی که تحلیل کلاسیک پیتر گوتمن (Peter Gutmann) نتیجه می‌گیرد که فناوری دیسک‌های سخت آن زمان برای واقعاً امن بودن نیازمند تعداد بیشتری بازنویسی بوده است، نویسنده بر این باور است که فناوری دیسک‌های سخت امروزی اجازه بازیابی داده‌های سکتورهایی را که با حالت --shred4 بازنویسی شده‌اند نمی‌دهد. این امر مطابق با توصیه‌های BSI GSDS M7.15 است.
بازنویسی کل پارتیشن‌ها یا دیسک‌ها با اعداد تصادفی روشی نسبتاً امن برای نابودسازی داده‌ها است، مگر آنکه دستگاه ذخیره‌سازی زیرین رفتارهای پیچیده و پنهانی بیش از حدی داشته باشد. درایوهای SSD در لایه ترجمه فلش (FTL) خود کارهای پیچیده‌ای انجام می‌دهند، بنابراین ممکن است این ابزار برای رهایی کامل از داده‌ها ناکافی باشد. در چنین حالتی از SECURITY_ERASE (با استفاده از hdparm) استفاده کنید یا -- در صورت دسترسی -- داده‌ها را با AES256 رمزگذاری کرده و کلید را با امنیت نابود سازید. دیسک‌های سخت معمولی خطر کوچکی برای نشت چند سکتور به دلیل تخصیص مجدد سکتورهای ناپایدار دارند.
برای نابودسازی امن تک‌پرونده‌ها، نتایج ممکن است متفاوت باشد. هرچه سامانه پرونده شما پیشرفته‌تر باشد، احتمال مؤثر بودن تخریب dd_rescue کمتر خواهد بود. به‌ویژه سامانه‌های پرونده دارای ژورنال ممکن است داده‌های قدیمی را در ژورنال نگه دارند. سامانه‌های پرونده‌ای که کپی هنگام نوشتن (COW) انجام می‌دهند مانند btrfs، بسیار محتمل است که نسخه‌های قدیمی از پرونده به‌ظاهر پاک‌شده شما را داشته باشند. پر کردن سامانه پرونده با صفر (dd_rescue -u /dev/zero /path/to/fs/DUMMYNAME) ممکن است تا حدی کمک کند تا سامانه پرونده را پس از بازنویسی پرونده‌های حیاتی با اعداد تصادفی، به آزادسازی و بازنویسی داده‌های غیرجاری وادار کند. در صورت امکان، بهتر است کل یک پارتیشن یا دیسک را نابود کنید.