.\" Automatically generated by Pandoc 3.10.2
.\"
.TH "bup\-fsck" "1" "2026\-09\-01" "Bup 0.34+"
.SH "نام (NAME)"
bup\-fsck \- بررسی صحت یا تعمیر یک مخزن bup
.SH "خلاصه دستور (SYNOPSIS)"
bup fsck [\-r] [\-g] [\-v] [\-\-quick] [\-j \f[I]jobs\f[R]]
[\-\-par2\-ok] [\-\-disable\-par2] [packfile\&...]
.SH "توضیحات (DESCRIPTION)"
هنگامی که \f[I]packfile\f[R]ها (که باید پسوند .pack داشته باشند) مشخص شوند، عملیات مربوط به بسته‌ها به همان فایل‌ها محدود می‌شود؛ در غیر این صورت تمامی فایل‌های بسته در مخزن فعلی در نظر گرفته می‌شوند.
.PP
در حال حاضر \f[CR]bup fsck\f[R] داده‌های درون مخزن را از نظر خرابی بررسی می‌کند.
به طور دقیق‌تر، یکپارچگی داده‌های \f[I]packfile\f[R]ها و نمایه‌های متناظر آن‌ها را بررسی می‌کند تا اطمینان حاصل کند از زمان نوشته شدن تغییر نیافته‌اند.
این دستور مسائل سطح بالاتر مانند پیوستگی (اشیاء مفقود)، به عنوان مثال این که آیا تمام داده‌های ارجاع‌شده توسط یک ذخیره واقعاً در مخزن موجود است یا خیر را بررسی نمی‌کند.
برای برخی بررسی‌های سطح بالاتر، \f[CR]bup\-validate\-object\-links\f[R](1) و \f[CR]bup\-validate\-refs\f[R](1) را ببینید.
بررسی‌هایی که \f[CR]bup fsck\f[R] انجام می‌دهد بر تشخیص و احتمالاً تعمیر خرابی فایل‌ها متمرکز است، در حالی که مشکلات سطح بالاتر بیشتر ناشی از باگ‌ها (که امید است نادرتر باشند) هستند.
.PP
هنگام بررسی فایل‌های بسته و نمایه‌ها، در حال حاضر fsck معمولاً به \f[CR]git\-verify\-pack\f[R](1) متکی است، اما با گزینه \f[CR]\-\-quick\f[R] (توضیحات بیشتر در زیر)، bup فقط چک‌سام‌های نمایه و بسته را خودش بررسی می‌کند.
.PP
جهت امکان‌پذیر ساختن تعمیرات، باید از طریق \f[CR]\-\-generate\f[R] از fsck خواسته شود تا «بلوک‌های بازیابی» \f[CR]par2\f[R](1) را تولید کند (در صورتی که نصب باشد).
این بلوک‌ها به شما اجازه می‌دهند تا از آسیب‌هایی که تا ۵٪ از فایل‌های \f[CR].pack\f[R] شما را تحت تأثیر قرار داده است، بازیابی انجام دهید.
.PP
در یک سامانه پشتیبان‌گیری معمولی، بلوک‌های آسیب‌دیده اهمیت کمتری دارند، زیرا معمولاً داده‌های تکراری کافی بین مجموعه‌های پشتیبان وجود دارد به طوری که آسیب دیدن یک مجموعه تکی بحرانی نیست.
اما در یک سامانه پشتیبان‌گیری با حذف داده‌های تکراری (deduplicating) مانند bup، هیچ بلوکی بیش از یک بار ذخیره نمی‌شود، حتی اگر در تک‌تک پشتیبان‌ها استفاده شده باشد.
اگر آن بلوک غیرقابل بازیابی شود، \f[I]تمام\f[R] مجموعه‌های پشتیبان شما به طور همزمان آسیب می‌بینند.
بنابراین، توانایی بررسی یکپارچگی پشتیبان‌ها و بازیابی از خطاهای دیسک در صورت وقوع بسیار حائز اهمیت است.
.PP
هنگام اقدام به \f[CR]\-\-repair\f[R]، برنامه bup با وضعیت ۱ خارج می‌شود اگر و تنها اگر تعمیرات مورد نیاز بوده و موفقیت‌آمیز باشد، و هیچ خطای دیگری رخ نداده باشد.
.PP
\f[I]هشدار\f[R]: مسلماً bup fsck نمی‌تواند خرابی کامل دیسک را بازیابی کند.
اگر پشتیبان‌های شما مهم هستند، باید با دقت افزونگی را در نظر بگیرید (مانند استفاده از RAID برای افزونگی چند دیسک، یا ایجاد پشتیبان‌های خارج از محل برای افزونگی مکانی).
.PP
هنگامی که درخواست بررسی تمام فایل‌های بسته داده می‌شود (یعنی زمانی که هیچ \f[I]packfile\f[R]ی مشخص نشده است)، fsck هر فایلی را که به نظر می‌رسد مربوط به یک فایل بسته ناموجود باشد گزارش می‌دهد.
نسخه‌های قبلی \f[CR]bup gc\f[R] می‌توانند باعث این اتفاق شوند زیرا هنگام حذف یک فایل بسته، تمام فایل‌های مربوط به آن را حذف نمی‌کردند.
.SH "گزینه‌ها (OPTIONS)"
.TP
\-r, \-\-repair
تلاش برای تعمیر بسته‌های آسیب‌دیده با استفاده از بلوک‌های بازیابی موجود.
(نیازمند \f[CR]par2\f[R](1).)
.TP
\-g, \-\-generate
تولید بلوک‌های بازیابی برای هر بسته‌ای که در حال حاضر فاقد آن‌ها است.
(نیازمند \f[CR]par2\f[R](1).)
.TP
\-v, \-\-verbose
افزایش پرگویی (می‌تواند بیش از یک بار استفاده شود).
.TP
\-\-quick
اجرا نکردن \f[CR]git verify\-pack\f[R] کامل روی هر فایل بسته؛ در عوض فقط بررسی چک‌سام نهایی.
این امر می‌تواند باعث افزایش چشمگیر سرعت بدون کاهش محسوس قابلیت اطمینان شود.
با این حال، اگر بسیار محتاط و وسواسی هستید ممکن است بخواهید از این گزینه اجتناب کنید.
بر روی بسته‌هایی که از قبل اطلاعات بازیابی دارند تأثیری ندارد.
.TP
\-j, \-\-jobs=\f[I]numjobs\f[R]
حداکثر تعداد اعتبارسنجی‌های بسته که به طور همزمان اجرا می‌شوند.
مقدار بهینه برای این گزینه بستگی به سرعت پردازنده شما در اعتبارسنجی بسته‌ها در مقایسه با پهنای باند دیسک دارد.
اگر کارهای زیادی را به طور همزمان اجرا کنید، دیسک شما به دلیل جستجو و جابجایی مداوم بین فایل‌ها اشباع می‌شود و عملکرد کاهش می‌یابد، حتی اگر \f[I]numjobs\f[R] کمتر از تعداد هسته‌های CPU در سیستم شما باشد.
می‌توانید با این گزینه آزمایش کنید تا مقدار بهینه را بیابید.
.TP
\-\-par2\-ok
در صورتی که \f[CR]par2\f[R](1) نصب باشد و کار کند، بلافاصله مقدار ۰ را برمی‌گرداند، و در غیر این صورت مقدار ۱.
در واقع هیچ چیزی را بررسی نمی‌کند.
.TP
\-\-disable\-par2
فرض می‌کند که \f[CR]par2\f[R](1) نصب نیست، و تمام بلوک‌های بازیابی را نادیده می‌گیرد.
.SH "مثال‌ها (EXAMPLES)"
.IP
.EX
# تولید بلوک‌های بازیابی برای تمام بسته‌هایی که فاقد آن هستند
bup fsck \-g

# تولید بلوک‌های بازیابی برای یک بسته خاص
bup fsck \-g \(ti/.bup/objects/pack/153a1420cb1c8*.pack

# بررسی صحت تمام بسته‌ها (می‌تواند بسیار کند باشد!)
bup fsck

# بررسی صحت تمام بسته‌ها و بازیابی موارد آسیب‌دیده
bup fsck \-r

# بررسی صحت یک بسته خاص و بازیابی آن در صورت آسیب
bup fsck \-r \(ti/.bup/objects/pack/153a1420cb1c8*.pack

# بررسی در دسترس بودن بلوک‌های بازیابی روی این سیستم
if bup fsck \-\-par2\-ok; then
    echo \(dqpar2 is ok\(dq
fi
.EE
.SH "وضعیت خروج (EXIT STATUS)"
با مقدار ۱ خارج می‌شود اگر \f[CR]\-\-repair\f[R] درخواست شده باشد، لازم بوده باشد، موفقیت‌آمیز باشد و خطای دیگری وجود نداشته باشد.
در غیر این صورت اگر خطایی رخ نداده باشد با ۰، و در صورت بروز خطا با مقداری غیر از صفر یا یک خارج می‌شود.
.SH "همچنین ببینید (SEE ALSO)"
\f[CR]bup\-damage\f[R](1), \f[CR]fsck\f[R](1), \f[CR]git\-fsck\f[R](1),
\f[CR]bup\-validate\-object\-links\f[R](1), and
\f[CR]bup\-validate\-refs\f[R](1)
.SH BUP
بخشی از مجموعه \f[CR]bup\f[R](1).
.SH "نویسندگان (AUTHORS)"
Avery Pennarun \c
.MT apenwarr@gmail.com
.ME \c.