دقیقاً مشخص کنید به چه چیزی دسترسی خود را از دست دادهاید
افراد عبارت «دسترسیام قطع شده» را برای پنج وضعیت متفاوت به کار میبرند، و هر یک راهحل خودش را دارد:
| چه چیزی از بین رفته | آنچه اغلب همچنان کار میکند |
|---|---|
| فقط پنل کنترل | SSH، SFTP، پورت پایگاهداده، rsync |
| کل سرور، شبکه خاموش | یک تیکت پشتیبانی برای درخواست بوت نجات یا خروجیگیری |
| حساب بسته شده، سرویس همچنان فعال | هرچیزی که از قبل با آن متصل بودهاید |
| همهچیز، بدون پاسخ | ثبتکنندهٔ دامنهٔ شما، DNS شما، پشتیبان برونسایتی شما |
پیش از هر نتیجهگیری، هر یک را بررسی کنید. تعداد شگفتآوری از تعلیقها، پنل وب و سایت عمومی را غیرفعال میکنند در حالی که SSH همچنان پاسخگو میماند، زیرا اسکریپت تعلیق برای متوقف کردن شکایت نوشته شده، نه برای متوقف کردن شما.
ترتیب جمعآوری موارد
اگر زمان محدود یا اتصال ناپایداری دارید، ترتیب اهمیت دارد. به این ترتیب دریافت کنید، ابتدا کوچکترین و جبرانناپذیرترین موارد:
- خروجیهای دیتابیس (Database dumps). کوچکترین، باارزشترین و سختترین برای بازسازی.
mysqldumpیاpg_dump، فشردهشده، در اولویت اول. - پیکربندی. تنظیمات وبسرور، جدولهای cron، فایلهای محیطی، کلیدهای TLS. حجمی ناچیز، اما بازسازی آنها از حافظه روزها طول میکشد.
- محتوای بارگذاریشده توسط کاربر. غیرقابلجایگزینی و معمولاً بزرگترین بخش. آن را زود شروع کنید و بگذارید ادامه یابد.
- کد برنامه. فقط اگر در جای دیگری تحت کنترل نسخه نباشد. اگر هست، کاملاً از آن صرفنظر کنید.
- لاگها. در انتها، و تنها اگر ممکن است به مدرکی از رخداد نیاز داشته باشید.
بهجای آرشیوی که باید یکجا تمامش کنید، از rsync با --partial --append-verify استفاده کنید، چون اتصالی که در 90 درصد یک tarball قطع میشود چیزی به شما نداده، ولی یک rsync قطعشده، 90 درصد را به شما داده است.
وقتی اصلاً شِلی وجود ندارد
- درخواست بوت نجات (rescue boot) بدهید. اکثر میزبانها یکی دارند، این یک سیستم زنده با دیسک شما متصل بوت میکند، و بسیاری آن را برای یک سرویس معلقشده فعال میکنند چون سایت عمومی شما را بازیابی نمیکند.
- درخواست یک ایمیج بدهید. پیشنهاد پرداخت بدهید. ایمیج دیسک روی یک لینک برای آنها ارزانتر از یک بحث پشتیبانی است.
- درخواست فعالسازی مجدد فقطخواندنی برای یک بازهی زمانی مشخص کنید. آن را بهعنوان یک ساعت مطرح کنید، نه یک بازگردانی کامل.
- هر جای دیگری را که ممکن است یک نسخه از قبل در آن باشد بررسی کنید. یک سرور استیجینگ، لپتاپ یک توسعهدهنده، خروجی CI، کش موتور جستوجو، یا Wayback Machine برای صفحات عمومی.
ابتدا دامنه خود را با خود ببرید
گرانبهاترین چیزی که ممکن است از دست برود داده نیست، دامنه است، و همان چیزی است که افراد در میانه هراس درباره دیسک فراموش میکنند. اگر registrar شما همان شرکت میزبان شماست، ثبت دامنه را همین امروز خارج کنید، پیش از آنکه درباره هر چیز دیگری بحث کنید.
همان اولین کار در کل این فرآیند، کاهش TTL دیاناستان به چند دقیقه است. هیچ هزینهای ندارد و تفاوت میان انتقالی است که چند دقیقه طول میکشد و انتقالی که دو روز طول میکشد، در نقطهای که شما از قبل دو روز را از دست دادهاید.
قابل بقا کردن دفعه بعد
حقیقت ناخوشایند دربارهٔ هر مقالهای مثل این است که نتیجه پیش از رسیدن ایمیل تقریباً تعیین شده بود. چهار چیز، هیچکدام گران:
- پشتیبانهایی در جایی که میزبان شما به آن دسترسی ندارد. پشتیبانی روی همان حساب، پشتیبان نیست؛ فقط نسخهٔ دومی از یک نقطهٔ شکست واحد است.
- بازیابیای که واقعاً اجرا کردهاید. یک بار. روی یک سرور دیگر. در غیر این صورت شما فقط یک فایل آزمایشنشده دارید.
- ثبتکنندهی دامنه جدا از میزبان. شرکتی متفاوت، و در صورت اهمیت داشتن برای شما، حوزهی قضایی متفاوت.
- DNS تحت کنترل شما. بنابراین جابهجایی یک تغییر رکورد است، نه یک مذاکره.
این بیشتر معماری موجود در ساختن به شکلی که یک اخطار حذف نتواند شما را از بین ببرد است که بیشتر به جنبه ساختاری میپردازد.
انتقال به اینجا، اگر ماجرا به اینجا ختم شود
سرویس انتقال رایگان است و یک مهندس این کار را انجام میدهد، از جمله بازه همگامسازی و انتقال DNS. رایگان است زیرا انتقال همان لحظهای است که کسی تصمیم میگیرد آیا به یک تأمینکننده اعتماد میکند یا نه، و هزینه گرفتن بابت آن مانند هزینه گرفتن بابت مصاحبه است.
پرسشهایی که واقعاً پرسیده میشوند
میزبان من میگوید دادهها از قبل حذف شدهاند. آیا واقعاً چنین است؟
گاهی، و گاهی نیز به این معناست که ورودی پنل حذف شده است. مشخصاً بپرسید که آیا حجم زیرین پاک شده و آیا نسخه پشتیبانی از آن نزد آنها وجود دارد، بهعنوان دو پرسش جداگانه.
آیا میتوانم داده را از میزبانی که پاسخ نمیدهد بگیرم؟
بهندرت، و در آن صورت یک مسئلهٔ حقوقی میشود نه فنی. به همین دلیل است که پشتیبانگیری برونمحلی تمام پاسخ است و باید پیش از نیاز شما وجود داشته باشد.
میزبانها معمولاً یک سرویس معلق را چه مدت نگه میدارند؟
این بازه از چند روز تا چند ماه متغیر است و در شرایط خدمات شما ذکر شده. به انتهای بخشنده این بازه اتکا نکنید.
توسط همان افرادی نوشته شده که به اخطارها پاسخ میدهند، و در صورت اشتباه اصلاح میشود. آخرین بازبینی: 31 ژوئیهٔ 2026.
هر قیمت در این مجموعه بهطور کامل و در یک مکان منتشر شده است. کل کاتالوگ را ببینید