استراتژی بکاپ هرگز در شبی که سرور از کار میافتد آزمایش نمیشود. آزمایش آن هفتهها زودتر، در سه تصمیم بیسروصدا اتفاق میافتد که هیچکس آنها را یادداشت نمیکند: نسخه کجا نگهداری میشود، چه کسی اجازه حذف آن را دارد، و اینکه آیا تا به حال کسی واقعاً یک نسخه را بازخوانی کرده است یا نه.
هاستینگی که هرگز هویت شما را نپرسیده، در ازای آن چیزی را از دست میدهد و اینجا جای صادقانه گفتنش است. هیچ مدیر حسابی برای تماس گرفتن نیست، هیچ تیکتی که یک ولوم پاکشده را زنده کند وجود ندارد، و سیاست نگهداری خودمان در این باره صریح است: دادههای سرور ظرف 24 ساعت پس از فسخ نابود میشوند، دیسکها بهجای فرمتشدن بهصورت رمزنگاریشده پاک میشوند و هیچ بکاپی نگهداری نمیشود. این همان ویژگی است که این پلتفرم را ارزش خرید میدهد، فقط از زاویه دیگر. هر چیزی که بخواهید بعد از یک شب بد پس بگیرید، باید از قبل جای دیگری باشد و این شما هستید که آن را آنجا میگذارید.
واقعاً چه چیزی سرورها را نابود میکند
تقریباً هیچکس سرور خود را به شکلی که تصور میکند از دست نمیدهد. خرابی فاجعهبار سختافزار واقعی است اما نادر، و تنها موردی است که یک هاست حرفهای از قبل در برابرش مهندسی کرده. اتفاقهایی که واقعاً رخ میدهند کسلکنندهترند و هرکدام نوع متفاوتی از نسخه پشتیبان را از کار میاندازند — به همین دلیل «من بکاپ دارم» تا وقتی نگویید در برابر کدامیک از اینها دوام میآورد، پاسخ محسوب نمیشود.
| چه چیزی خراب میشود | معمولاً چگونه رخ میدهد | چه چیزی شما را نجات میدهد |
|---|---|---|
| دست خودتان | یک rm -rf در حالی که یک متغیر شل خالی بوده، مایگریشنی که بهاشتباه به سرور اصلی اشاره کرده، یا دیپلویی که جدول اشتباه را حذف کرده | هر نسخه خارج از سرور که مربوط به پیش از اشتباه باشد — یعنی بازه نگهداری باید از زمانی که متوجه اشتباه میشوید عقبتر برود |
| خرابی بیصدا | یک NVMe رو به مرگ، نوشتاری ناقص هنگام ریبوت، پایگاهدادهای که یک هفته است ردیفهای خراب مینویسد | نسخههای دارای تاریخچه که آنقدر عمیق باشند تا به یک نقطه سالم برسند. یک نسخه آینهای تک، خرابی را هم دقیقاً کپی میکند |
| نفوذ | کلید دزدیدهشده، اپلیکیشن وصلهنشده، یک وابستگی مسموم — و سپس، عمداً، بکاپهای شما | نسخهای که دستگاه نفوذشده هیچ قدرتی برای حذف آن نداشته. اینجا فقط همین حساب میشود |
| رویداد در سطح ارائهدهنده یا کشور | از دست رفتن سختافزار، اقدام قانونی در دیتاسنتر، حسابی یا توکنی که دیگر به آن دسترسی ندارید | نسخهای که نه نزد آن ارائهدهنده است و نه زیر آن حوزه قضایی |
| گمکردن کلید | پسعبارت فراموششده، فایل کلیدی که همراه سروری که محافظت میکرد پاک شده، هدر LUKS که هیچکس از آن خروجی نگرفته | هیچچیز. این تنها ردیفی است که ستون بازیابی ندارد و از خرابی سختافزار هم رایجتر است |
این جدول را بهجای فهرست ترسها، یک چکلیست بدانید. یک نسخه شبانه روی دیسک دوم همان دستگاه فقط به ردیف اول پاسخ میدهد و بس. یک اسنپشات در همان پنل به ردیفهای اول و دوم پاسخ میدهد. فقط نسخهای که جایی نگهداری شود که سرور به آن دسترسی ندارد، زیر کلیدی که هنوز در اختیار دارید، به هر پنج مورد پاسخ میدهد.
اسنپشات بکاپ نیست، و هاست شما هم بکاپ نیست
اسنپشاتها در کاری که انجام میدهند عالیاند: در چند ثانیه و بدون هیچ انتقالی، یک آپدیت ناموفق را برمیگردانند. کاری که از دستشان برنمیآید این است که در برابر چیزی که سرور را از بین برده دوام بیاورند، چون هر دامنه شکستی را با آن سرور مشترک هستند — همان ارائهدهنده، همان حساب، همان توکن پرداخت، همان کشور و اغلب همان کلاستر ذخیرهسازی. اسنپشات شما را در برابر خودتان محافظت میکند. بکاپ شما را در برابر همهچیز دیگر محافظت میکند.
این تفاوت اینجا بیشتر از یک هاست معمولی اهمیت دارد، چون شبکههای ایمنی معمول عمداً حذف شدهاند. هیچکس به سرورهای مشتری وارد نمیشود، پس هیچکس متوجه نمیشود که وظیفه بکاپ شما از ماه مارس دارد شکست میخورد. هیچ هویتی به حساب متصل نیست، پس هیچ مسیر انسانی برای «ثابت کن چه کسی هستی تا برایت بازیابی کنیم» وجود ندارد. و فسخ واقعاً پایان کار است: موجودی منقضیشده یک رویداد ازدسترفتن داده است، نه یک رویداد مالی.
بند 24 ساعته کل استدلال است. در این پلتفرم، دادههای یک سرور فسخشده ظرف یک روز نابود میشود و دیسکها بهجای فرمتشدن بهصورت رمزنگاریشده پاک میشوند. هیچ آندلیتی، هیچ لایه سرد پنهانی، و هیچ نتیجه پشتیبانی که به «یک نسخه قدیمیتر پیدا کردیم» ختم شود وجود ندارد — چون نگهداشتن یک نسخه یعنی داده شما را بعد از درخواست حذف نگه داشتهایم. شبکه ایمنی و حریم خصوصی، یک معامله واحدند که فقط یکبار انجام میشود.
قانون 3-2-1، بازنویسیشده برای کسانی که هرگز مدرک هویتی نشان ندادهاند
قانون کلاسیک میگوید سه نسخه، روی دو نوع رسانه، که یکی از آنها خارج از محل باشد. این قانون برای دوران نوار و دیسک گردان نوشته شده بود و بند «رسانه» بیسروصدا دیگر معنایی ندارد: دیسک سرور اصلی شما NVMe است، دیسک مقصد بکاپ هم NVMe است، و نامیدن این دو با عنوان «دو رسانه» فقط داستانی است که به خودتان میگویید. بندی که ارزش نگهداشتن دارد، بند «فاصله» است و در زیرساخت آفشور فاصله با کیلومتر سنجیده نمیشود.
آن را اینطور بازنویسی کنید: سه نسخه، دو ارائهدهنده، دو حوزه قضایی. اتفاقهایی که هر دو نسخه را همزمان از بین میبرند تقریباً هرگز فیزیکی نیستند — یک حساب است که دسترسیاش را از دست دادهاید، یک ارائهدهنده که هفته بدی داشته، یا یک ابزار قانونی که در یک کشور اثر میگذارد و در کشور دیگر هیچ دسترسی ندارد. دو سرور در یک رک، یک نسخه با چند مرحله اضافه است؛ دو سرور زیر یک نظام قانونی یکسان هم بهسختی بهتر است. راهنمای انتخاب حوزه قضایی ما توضیح میدهد چطور دومی را طوری انتخاب کنید که ریسک اولی را تکرار نکند.
در عمل این کار ارزان است. مقصد بکاپ نیازی به هسته پردازشی ندارد و تقریباً به شبکه هم نیاز ندارد — فقط به دیسک و یک آدرس نیاز دارد. کوچکترین پلن VPS در یکی دیگر از هفت لوکیشن ما یک مقصد کاملاً کافی برای restic یا Borg است، و برای آرشیوهایی که با ترابایت سنجیده میشوند، یک سرور اختصاصی با درایوهای واقعی هزینه هر ترابایت کمتری نسبت به هر آبجکت استوریج دارد. جایی که داده واقعاً حجیم است و بهندرت خوانده میشود، صرفه اقتصادی بهوضوح به سمت بر متال است.
یک نکته که افراد در سرور اصلی درست انجام میدهند اما در مقصد بکاپ فراموش میکنند: هزینهاش را هم به همان روش بپردازید. خرید یک سرور دوم با کارت به نام خودتان، بیسروصدا همان هویتی را که برای حذفش از سرور اول زحمت کشیده بودید دوباره وصل میکند، آن هم درست روی سروری که یک نسخه کامل از همهچیز را نگه میدارد. اگر هزینه سرور اصلی با Monero پرداخت میشود، سرور بکاپ هم سزاوار همان رفتار است.
نسخه سوم چیزی است که بیشتر افراد از آن صرفنظر میکنند، در حالی که تنها نسخهای است که در برابر همه خرابیهای راه دور همزمان مصون میماند: دیسکی که فیزیکاً در اختیار دارید، هرازگاهی بهروز میشود و آفلاین نگهداری میشود. برای بیشتر افراد ماهی یکبار کافی است. هزینهاش بهاندازه توجهِ یک فنجان قهوه است و همان نسخهای است که سناریوهایی را که آن دو نسخه دیگر مشترکاً در برابرشان آسیبپذیرند، پشت سر میگذارد.
پوش، پول، و اشتباهی که یک شب بد را قادر میکند هر دو نسخه را نابود کند
این چیدمانی است که تقریباً همه اول از همه میسازند. یک وظیفه روی سرور اصلی هر شب اجرا میشود، یک کلید یا توکن برای مقصد بکاپ در اختیار دارد، متصل میشود و داده را پوش میکند. کار میکند، ساده است، و ویژگیای دارد که فقط در بدترین روز عمر سرور خودش را نشان میدهد: هرکس سرور اصلی را کنترل کند، بکاپها را هم کنترل میکند.
این فرضی نیست. حذف یا رمزگذاری بکاپهای قربانی پیش از اعلام حضور، رویه استاندارد هرکسی است که این کار را بهصورت تجاری انجام میدهد — اعتبارنامهها معمولاً در یک کرونجاب یا یک فایل محیطی نشستهاند و پیدا کردنشان حدود یک دقیقه طول میکشد. نسخهای که مهاجم شما بتواند حذفش کند، نسخه دوم نیست. آینهای است از نسخه اول با کمی تأخیر.
دو راهحل تمیز وجود دارد که با سختسازی پایهای که باید از قبل انجام داده باشید، بهخوبی ترکیب میشوند.
- مقصدهای append-only. هر دو ابزار اصلی حالتی را پشتیبانی میکنند که در آن کلاینت میتواند داده اضافه کند اما نمیتواند حذف کند. Borg این کار را با محدودکردن کلید SSH روی مقصد به
borg serve --append-onlyانجام میدهد؛ restic آن را با یک سرور REST که با--append-onlyاجرا شده انجام میدهد. سرور اصلی هر شب مینویسد و از نظر ساختاری قادر به نابودکردن تاریخچه نیست. هرس اسنپشاتهای قدیمی سپس روی مقصد انجام میشود، در نشستی که سرور اصلی نمیتواند آغازش کند. - پول بهجای پوش. جهت را برعکس کنید: هاست بکاپ به سرور اصلی متصل میشود، میخواند و ذخیره میکند. سرور اصلی اصلاً هیچ اعتبارنامهای برای مقصد ندارد، پس چیزی برای دزدیدن وجود ندارد. کلیدی که در سمت سرور اصلی استفاده میشود را با
restrictو یکcommand=اجباری محدود کنید تا یک کلید بکاپ دزدیدهشده نتواند به یک شل تبدیل شود.
پول مدل قویتری است و اجرایش کمی کار بیشتری میبرد؛ append-only اگر از قبل از Borg یا restic استفاده میکنید تقریباً رایگان است. هرکدام «مهاجم بکاپهای من را حذف کرد» را از یک نتیجه به یک تلاش ناکام تبدیل میکند. اگر فقط یک چیز از این راهنما بردارید، همین بخش را بردارید.
در مبدأ رمزنگاری کنید، سپس تصمیم بگیرید کلید دست کیست
هر دو ابزار جدی، پیش از اینکه هر چیزی از شبکه عبور کند، روی همان دستگاهی که در حال بکاپگیری است رمزنگاری میکنند. مقصد بلابهایی را ذخیره میکند که نمیتواند بخواند — و دقیقاً همین چیزی است که نسخه بینارائهدهنده را امن میکند. هاست دومتان نیازی نیست قابلاعتماد یا حتی دوستانه باشد؛ فقط باید در دسترس باشد و دیسک داشته باشد. همین یک ویژگی است که «سروری در کشوری که هیچ نمیدانم» را از یک ریسک به یک زیرساخت تبدیل میکند.
این مکانیزمی متفاوت از رمزنگاری دیسک خود سرور است و این دو به پرسشهای متفاوتی پاسخ میدهند — راهنمای ما درباره رمزنگاری کامل دیسک روی VPS شرح میدهد رمزنگاری دیسک هنگام روشنبودن دستگاه چه چیزی را محافظت میکند و چه چیزی را نه. رمزنگاری بکاپ از این دو راحتتر و باارزشتر است، چون مدل تهدید صادقانه است: داده در حالت سکون است، روی سختافزاری که کنترلش دست شما نیست، و کلید هرگز به آنجا نمیرود.
این یعنی کل ریسک به نگهداری کلید منتقل میشود. پسعبارت حالا تنها نقطه ازدسترفتن کامل است و نقطهای بدتر از آنچه افراد انتظار دارند، چون ازدسترفتنش بیصداست — چیزی خراب نمیشود، بکاپها همچنان اجرا میشوند و شما دقیقاً همان لحظهای که به آنها نیاز دارید متوجه میشوید. سه عادت این را حل میکند:
- پسعبارت را روی سرور فقط بهصورت فایلی که تنها روت آن را بخواند نگه دارید، با ارجاع از طریق
--password-file، تا هرگز در فهرست پردازشها یا تاریخچه شل ظاهر نشود. - یک نسخه قابلخواندن انسانی خارج از هر دستگاه درگیر نگه دارید. کاغذ در یک کشو واقعاً بهتر از یک پسورد منیجر است که با حسابی همگام میشود که ممکن است دسترسیاش را هم از دست بدهید.
- یک کلید دوم به مخزن اضافه کنید —
restic key add، یا یک کلید Borg خروجیگرفتهشده — تا فراموشی یک پسعبارت فقط یک دردسر باشد نه پایان آرشیو.
قانون زیربنایی هر سه: اگر تنها نسخه کلید روی همان دستگاهی زندگی کند که بکاپ قرار است جایگزینش شود، شما بکاپ ندارید. شما یک توده رمزنگاریشده از بلوکها و یک داستان دربارهشان دارید.
انتخاب یک ابزار، در یک جدول
انتخاب ابزار کماهمیتتر از جهت اتصال و وضعیت کلید شماست، به همین دلیل ششمین مورد است نه اولین. با این حال، تفاوتها واقعیاند و انتخاب شکل نادرست برای این کار، بعداً برایتان دردسر میسازد.
| ابزار | پیش از خروج رمزنگاری میکند | حذف داده تکراری | مقصد append-only | کجا مناسب است |
|---|---|---|---|---|
| restic | بله، کل مخزن | بله | بله، از طریق سرور REST خودش | گزینه پیشفرض. با SFTP، آبجکت استوریج و سرور خودش صحبت میکند، پس مقصد میتواند تقریباً هر چیزی باشد |
| BorgBackup | بله، کل مخزن | بله، بهترین در این گروه | بله، بهصورت بومی روی SSH | یک مقصد لینوکسی که از طریق SSH در دسترس است. در داده حجیم و تکراری بیرقیب است |
| rsync با چرخش نسخهها | خیر — مقصد همهچیز را میبیند | جزئی، از طریق هاردلینک | خیر | آینهسازی به دستگاهی که کاملاً کنترلش دست شماست، وقتی بازیابی جزئی فوری از حریم خصوصی مهمتر است |
| rclone | فقط با rclone crypt | خیر | بسته به ارائهدهنده ذخیرهسازی | انتقال آرشیوی که از قبل وجود دارد به آبجکت استوریج، یا بین ارائهدهندهها |
| تکرار ZFS | فقط با یک دیتاست رمزنگاریشده | بله، در سطح بلوک | از طریق مجوزهای اسنپشات | تکرار بین دو دستگاه ZFS. بسیار سریع، بسیار سختگیر درباره هر دو سر |
| tar با age یا GPG | بله، اگر آرشیو را رمزنگاری کنید | خیر | موردی ندارد | آرشیوهای کوچک، گاهبهگاه و همیشه-نگهدار که سادگی بر کارایی برتری دارد |
برای یک سرور تک، استفاده از restic به سمت یک VPS دوم کوتاهترین مسیر به سمت چیزی درست است. برای سیدباکس، آرشیو رسانهای یا هر چیزی با تعداد زیادی فایل بزرگ مشابه، حذف داده تکراری در Borg تفاوت بین یک دیسک پر و یک دیسک راحت را میسازد — راهنمای سیدباکس جنبه ذخیرهسازی آن نوع بار کاری را با جزئیات بیشتری پوشش میدهد.
هرچیزی که در حال اجراست، یک فایل نیست
رایجترین بکاپ خراب در دنیا، یک کپی مستقیم از فایلهای یک پایگاهداده زنده است. بدون خطا کامل میشود، حجم درستی دارد و بعد به جدولی بازیابی میشود که موتور از باز کردنش سر باز میزند. پایگاهداده وسط یک نوشتن بوده که کپی از آن گرفته شده؛ چیزی که ذخیره کردهاید عکسی است از صفحهای در حال ورقخوردن.
سه راه خروج، به ترتیب افزایش زحمت. دامپش بگیرید: mysqldump --single-transaction بدون قفلکردن نویسندهها یک دامپ سازگار از InnoDB میدهد، و pg_dump همین کار را برای PostgreSQL انجام میدهد. از آن اسنپشات بگیرید: فایلسیستم را منجمد کنید یا یک اسنپشات LVM یا ZFS بگیرید، از روی اسنپشات کپی کنید، بعد آزادش کنید — اینطور با مجموعهدادههایی برخورد میکنید که برای دامپ شبانه خیلی بزرگاند. یا متوقفش کنید: برای یک سرویس کوچک، دو دقیقه قطعی در ساعت 04:00 یک استراتژی سازگاری کاملاً قابلاحترام است و تنها گزینهای است که هیچ حالت خاصی ندارد.
همین منطق فراتر از پایگاهدادهها هم صدق میکند. لایه قابلنوشتن یک کانتینر مصرفی است، اما ولومهایش نیستند و فایل docker compose و محیط کنارشان هم همینطور — بکاپی که داده را بازیابی میکند اما تعریف را نه، شما را وامیدارد استک را از حافظهتان بازسازی کنید. صفهای پیام، Redis با پرسیستنس فعال، و یک صف ایمیل که یک MTA در حال نوشتن در آن است، همگی سزاوار همین رفتارند: متوقف کنید، اسنپشات بگیرید یا دامپ بگیرید، اما هرگز مستقیم کپی نکنید و امیدوار نباشید.
چه چیزی را بکاپ بگیرید، و بخشهایی که همه فراموش میکنند
بیشتر افراد از بار اصلی و واضح — پایگاهداده و دایرکتوری اپلیکیشن — بکاپ میگیرند و بقیه را زیر فشار و با دست بازسازی میکنند. بازسازی همان جایی است که ساعتها وقت صرفش میشود. بکاپی که شما را به یک سیستم کارآمد برمیگرداند، نه فقط به یک انبوه داده درست، شامل لایه کسلکننده هم میشود:
/etcبهطور کامل، بههمراه واحدها و تایمرهای systemd که خودتان نوشتهاید و هر کرونتبی که خارج از آن زندگی میکند.- گواهیهای TLS و کلیدهای خصوصیشان، یا دستکم کلید حساب ACME، تا گواهیها تمدید شوند نه اینکه از صفر شروع کنید.
- قوانین فایروال و فهرست بستهها، که با هم شکل دستگاه را سریعتر از هر خاطرهای از آن بازسازی میکنند.
- اسرار اپلیکیشن و فایلهای محیطی — همانهایی که عمداً از مخزن کد شما کنار گذاشته شدهاند و به همین دلیل جای دیگری وجود ندارند.
- رکوردهای DNS که بهصورت متن خروجی گرفته شدهاند، شامل رکوردهای reverse-DNS و PTR، که نزد ارائهدهنده هستند نه روی سرور.
برخی کلیدها داده نیستند — هویتاند. کلید خصوصی یک سرویس onion در Tor همان آدرس است: آن را از دست بدهید و سایت دیگر نمیتواند با همان نام .onion برگردد، مهم نیست چه چیز دیگری را بازیابی کرده باشید. کلید سرور WireGuard یعنی باید هر کانفیگ کلاینتی که تا حالا دادهاید را دوباره صادر کنید. کلید DKIM یک میلسرور یعنی یک selector جدید و شروعی دوباره برای تحویلپذیری ایمیل. سید و وضعیت کانال یک نود Lightning میتواند یعنی وجوه باشد، نه فایل — راهنمای هاست نود در این باره صریح است. اینها را جداگانه کپی کنید، آفلاین نگه دارید و باارزشتر از دادهای که محافظت میکنند در نظرشان بگیرید.
بازیابیای که تست نکردهاید، فقط یک شایعه است
نرمافزار بکاپ درباره خودش گزارش میدهد و صادقانه هم درباره چیز اشتباهی گزارش میدهد. «اسنپشات کامل شد» یعنی داده در یک مخزن نوشته شده. این جمله هیچ چیزی درباره اینکه آیا آن مخزن روی دستگاهی غیر از این یکی، توسط کسی که یازده ماه پیش چه چیزی را تنظیم کرده به یاد ندارد، قابل خواندن است یا نه، نمیگوید.
با بررسیهای ارزان یکپارچگی شروع کنید — restic check --read-data-subset=5% یا borg check --verify-data روی یک زمانبندی منظم — و بدانید که اینها فقط آرشیو را تأیید میکنند، نه توانایی شما در استفاده از آن را. تمرین واقعی چیز دیگری است و یک بار، یک بعدازظهر وقت میگیرد. یک سرور تازه را ساعتی در لوکیشنی که معمولاً استفاده نمیکنید سفارش دهید. با هیچچیز جز آدرس مخزن، پسعبارت و یادداشتهای خودتان روی آن بازیابی کنید. سرویس را بالا بیاورید. کل فرایند را زمان بگیرید. بعد دستگاه را نابود کنید. هزینه کل: چند دلار، و تنها تمرینی است که عددی قابلاعتماد به شما میدهد.
چیزی که این تمرین همیشه لو میدهد، هرگز خود داده نیست. بسته گمشدهای است که هیچکس یادداشت نکرده، تنظیماتی که بیرون از مسیرهای بکاپگیریشده زندگی میکرده، پسعبارتی که فقط در تاریخچه شل همان سروری وجود داشته که دارید جایگزینش میکنید، و نسخهای از ابزار که فرمت مخزن شما را میخواند. تکتک اینها از قبل بهسادگی قابل رفعاند و کشفکردنشان وسط یک قطعی، دردناک است.
دو عدد را که این تمرین به شما میدهد یادداشت کنید: بازیابی چقدر طول کشید و برنامه بکاپ میتواند چقدر کار را از دست بدهد. اینها همان سیاست بکاپاند. هرچه بالاتر آمد، جزئیات اجرا در خدمت همین دو عدد است.
آن را خودکار کنید تا همیشه اتفاق بیفتد
وظیفه را از طریق یک تایمر systemd اجرا کنید نه cron. اینطور لاگها در یک جا جمع میشوند، رکورد واقعی از آخرین اجرا دارید و یک زمانبندی که در برابر ریبوت دوام میآورد — هیچکدام از اینها را cron بدون کار اضافه به شما نمیدهد. پسعبارت را خارج از خود فایل یونیت نگه دارید، چون هرکسی با دسترسی شل میتواند آن را مستقیماً از systemctl cat بخواند.
بعد حالت شکستی را حل کنید که واقعاً افراد را گرفتار میکند، که یک خطا نیست بلکه سکوت است. بکاپی که شش هفته پیش از کار افتاده دقیقاً شبیه بکاپی است که کاملاً درست اجرا شده، چون هیچکدام خروجیای تولید نمیکنند. روی نبودن هشدار بدهید، نه روی شکست. کاری کنید وظیفه هنگام موفقیت به یک مانیتور پینگ بزند و بگذارید مانیتور وقتی پینگ نرسید شکایت کند — و آن مانیتور را هر جایی بهجز خودِ سروری که زیر نظر دارد بگذارید، چون دستگاهی که از کار افتاده نمیتواند گزارش دهد که از کار افتاده.
بازه نگهداری را عمداً تنظیم کنید نه بهصورت پیشفرض. چیزی مثل --keep-daily 7 --keep-weekly 4 --keep-monthly 6 هم اشتباهاتی را که امشب متوجه میشوید و هم خرابیای را که در بهار متوجه میشوید، بدون رشد بیپایان پوشش میدهد. اگر append-only شدهاید، هرس را در سمت مقصد اجرا کنید، که خودِ هدف append-only شدن است. حجم انتقال بهندرت محدودیت شبکه ماست — پهنای باند در همه پلنها نامحدود است — پس برای ثبات برنامهریزی کنید نه برای یک سهمیه، و زمانبندی را با ساعات آرام خودتان بسنجید. عادتهای گستردهتر پیرامون همه اینها در راهنمای OpSec سرور پوشش داده شدهاند.
نسخه کوتاه
اگر هیچ کار دیگری با این صفحه نمیکنید، این شش کار را انجام دهید، تقریباً به همین ترتیب:
- یک نسخه را نزد یک ارائهدهنده دوم، در یک حوزه قضایی دوم، به همان روش خصوصی نسخه اول پرداختشده قرار دهید.
- آن نسخه را append-only کنید، یا آن را از مقصد پول کنید، تا یک سرور نفوذشده نتواند نابودش کند.
- بگذارید ابزار در مبدأ رمزنگاری کند و کلید را خارج از هر دو دستگاه درگیر نگه دارید.
- از پایگاهدادهها دامپ بگیرید و هرچه در حال اجراست را متوقف یا اسنپشات کنید؛ هرگز از وضعیت زنده مستقیم کپی نگیرید.
- کلیدهای هویتی را جداگانه بکاپ بگیرید — onion، WireGuard، DKIM، سیدهای نود — چون اینها قابل بازتولید نیستند.
- یکبار روی یک سرور یکبارمصرف بازیابی کنید، زمانش را بسنجید و بنویسید چه چیزی کم بود.
هیچکدام از اینها عجیب نیست و هیچکدام یک آخر هفته وقت نمیگیرد. یک بعدازظهر راهاندازی و یک تمرین است، در برابر دستهای از خسارت که پروژهها را تمام میکند. روی پلتفرمی که عمداً هیچ چیزی درباره شما نگه نمیدارد، نسخهای که خودتان ساختهاید تنها نسخهای است که وجود دارد — که همان هزینه این چیدمان است، هزینهای منصفانه. یک سرور دوم راه بیندازید در حوزه قضاییای غیر از اولی، و به بکاپ امشب جایی برای فرود بدهید.