بک‌آپ‌های رمزنگاری‌شدهٔ خارج از سایت: 3-2-1 روی VPS آفشور خودتان

اسنپ‌شات یک بک‌آپ نیست

اسنپ‌شات داخل پنل شما واقعاً چیز مفیدی است و باید پیش از هر تغییر پرریسکی یکی بگیرید. همچنین یک بک‌آپ هم نیست، و این تفاوت موشکافی نیست — بلکه تمام فهرست موقعیت‌هایی است که سعی دارید از آن‌ها جان سالم به در ببرید. یک اسنپ‌شات روی همان میزبان، داخل همان حساب، پشت همان اطلاعات ورودیِ ماشینی زندگی می‌کند که از آن محافظت می‌کند. دقیقاً به یک سؤال خوب پاسخ می‌دهد: چطور آخرین ۲۰ دقیقه را برگردانم؟ به هیچ سؤال دیگری پاسخ نمی‌دهد. اگر حساب از بین برود، اسنپ‌شات هم با آن از بین می‌رود. اگر منطقه در دسترس نباشد، rollback هم در دسترس نیست. اگر یک مهاجم به پنل دست یابد، به اسنپ‌شات‌ها هم دست می‌یابد. و اگر داده از قبل، هنگام گرفتن اسنپ‌شات، خراب بوده باشد، آن خرابی را با وفاداری تحسین‌برانگیزی حفظ کرده‌اید.

همین موضوع دربارهٔ دو چیزی هم صدق می‌کند که مردم اغلب آن‌ها را با بک‌آپ اشتباه می‌گیرند. RAID یک بک‌آپ نیست: در برابر از‌کارافتادن یک دیسک محافظت می‌کند و rm -rf را با تمام سرعت روی mirror تکرار می‌کند. Replication هم به همین دلیل بک‌آپ نیست — طوری طراحی شده که نسخهٔ دوم را هرچه سریع‌تر با نسخهٔ اول یکسان کند، حتی وقتی نسخهٔ اول همین الان نابود شده باشد. روی یک میزبان بدون KYC، شاخهٔ حساب در این فهرست از هر جای دیگری تیزتر است: ثبت‌نام یعنی یک هندل، یک رمز عبور و هشت کد بازیابی، بدون هیچ ایمیل یا مدرکی در هیچ جای این چرخه، پس اگر آن‌ها را گم کنید، هیچ نردبان پشتیبانی‌ای برای بالا رفتن وجود ندارد. این همان محصولی است که طبق طراحی کار می‌کند. این یعنی نسخه‌ای که واقعاً اهمیت دارد، همان نسخه‌ای است که از طریق اطلاعات ورودی‌ای که ممکن است گمشان کنید، در دسترس نیست.

3-2-1، بازنویسی‌شده برای سروری که هیچ‌کس نمی‌تواند شناسایی‌اش کند

قانون قدیمی هنوز برقرار است: سه نسخه از هرچیزی که برایتان اهمیت دارد، روی دو سیستم متفاوت، که یکی از آن‌ها خارج از سایت باشد. بسط مدرنی که مردم آن را 3-2-1-1-0 می‌نویسند، دو بند را اضافه می‌کند که در 2026 بیش از همه اهمیت دارند — یک نسخه که غیرقابل‌تغییر یا آفلاین باشد، و صفر خطا هنگام تأیید. روی یک تک‌سرور که پیاده‌اش کنید، این‌طور خوانده می‌شود: نسخهٔ اول داده‌های زنده است؛ نسخهٔ دوم اسنپ‌شات سمت ارائه‌دهنده یا افزونهٔ بک‌آپ‌های رمزنگاری‌شدهٔ روزانه است، که اشتباه معمول ساعت دو بامداد را بدون هیچ تلاشی از سمت شما مدیریت می‌کند؛ نسخهٔ سوم یک مخزن رمزنگاری‌شده روی یک ماشین دوم، در یک منطقهٔ متفاوت است، که ماشین اول هیچ اختیاری برای حذف آن ندارد. فقط نسخهٔ سوم است که از دست‌رفتن حساب ماشین اول جان سالم به در می‌برد، و فقط نسخهٔ سوم به این معنا واقعاً مال شماست که هیچ‌کس دیگری را نمی‌توان مجبور به ارائه‌اش کرد.

دربارهٔ اینکه "خارج از سایت" یعنی چه، عمدی عمل کنید. یک رَک دیگر در همان ساختمان، به هیچ معنای مهمی خارج از سایت نیست، و یک منطقهٔ دیگر تحت همان قانون هم فقط نیمی از راه است — یک سند حقوقیِ واحد که به یک ماشین می‌رسد، نباید خودکار به هر دو هم برسد. با 6 منطقه برای انتخاب، این تصمیمی است که فقط یک‌بار، در زمان استقرار می‌گیرید و دیگر هرگز به آن برنمی‌گردید. با این حال ارزش دارد رک گفته شود: دو سرور اینجا همچنان دو سرور نزد یک ارائه‌دهنده‌اند، که هرقدر هم ایزوله‌سازی خوب باشد، یک ریسک هم‌بسته است. اگر مدل تهدید شما واقعاً از‌دست‌دادنِ ما را هم شامل می‌شود، نسخهٔ سوم باید کاملاً جای دیگری باشد — یک ماشین در خانه، رَکِ یک دوست، یا میزبانی دیگر در قاره‌ای دیگر. هرچه در این راهنما آمده، هرجا که مقصد باشد، دقیقاً به همان شکل کار می‌کند؛ تنها چیزی که تغییر می‌کند، آدرس درون یک متغیر محیطی است.

پیش از خروج از دستگاه، رمزنگاری کنید

مقصد باید جایی باشد که بایت‌هایی را ذخیره می‌کند که نمی‌تواند بخواند. این یک سیاست نیست که از یک ارائه‌دهنده بپذیرید، بلکه یک ویژگی است که خودتان می‌سازید: داده روی مبدأ تکه‌بندی، فشرده، رمزنگاری و تأیید می‌شود، و آنچه از شبکه عبور می‌کند از قبل مبهم است. حالت‌های repokey و keyfile در Borg هر تکه را با AES-256 در حالت شمارنده (counter mode) رمزنگاری و تأیید می‌کنند، و نسخه‌های -blake2، HMAC-SHA256 را با BLAKE2b جایگزین می‌کنند که روی پردازنده‌های 64 بیتی مدرن، به‌شکل قابل‌اندازه‌گیری سریع‌تر است. محتوای فایل‌ها، نام فایل‌ها و مانیفستِ آرشیوی که فهرستشان می‌کند، همگی رمزنگاری می‌شوند؛ مقصد فقط فایل‌های قطعهٔ شماره‌گذاری‌شده و یک ایندکس را نگه می‌دارد که نمی‌تواند تفسیرش کند. restic همان شکل را با لوله‌کشی داخلی متفاوتی به شما می‌دهد. در هر دو حالت، مدل ذهنی درست این است که شما فضای دیسک را اجاره می‌کنید، نه اعتماد را.

دو نکتهٔ صادقانه. اول اینکه چه چیزی هنوز لو می‌رود: هرکس دیسک مقصد را در اختیار داشته باشد می‌تواند ببیند چقدر داده می‌رسد و چه زمانی می‌رسد. اندازهٔ مخزن و زمان‌بندی نوشتن‌ها حتی وقتی محتوا دیده نمی‌شود، قابل‌مشاهده‌اند، که برای اکثر افراد بی‌اهمیت است و برای عده‌ای کم، نه. دوم، رمزنگاری در حالت سکون روی مقصد — یعنی LUKS روی باکس بک‌آپ — در برابر خارج‌شدن دیسک از ساختمان دفاع می‌کند، نه در برابر میزبانِ درحال‌اجرا، پس رمزنگاری سمت کلاینت را تکمیل می‌کند، نه اینکه جایگزینش کند. و بعد بخشی که کار دست آدم می‌دهد: با repokey، خودِ مادهٔ کلید درون مخزن زندگی می‌کند، پیچیده‌شده در عبارت عبور شما، پس با از‌دست‌دادن مخزن، کلید را هم از دست می‌دهید؛ با keyfile، فقط روی مبدأ زندگی می‌کند، پس با از‌دست‌دادن مبدأ، هر آرشیوی را که تابه‌حال ساخته‌اید از دست می‌دهید. هیچ‌کدام امن نیستند تا وقتی کلید را export کرده و آن export را جایی گذاشته باشید که هیچ‌کدام از دو ماشین نباشد. این کار را در مرحلهٔ سوم انجام دهید، نه "بعداً".

Borg، restic، rclone: یکی را انتخاب کنید و دلیلش را بدانید

اینجا دو ابزار پاسخ درستی هستند، و انتخاب واقعاً به مقصد بستگی دارد. Borg حذف تکرار در سطح تکه، فشرده‌سازی و رمزنگاری تأییدشده انجام می‌دهد، و — به همین دلیل است که مثال کاری در ادامهٔ همین راهنماست — یک حالت append-only واقعی و سمت‌سرور ارائه می‌دهد که آن را رایگان، فقط از راه SSH ساده به دست می‌آورید، بدون هیچ دیمنی برای اجرا و بدون هیچ پورت اضافه‌ای برای باز کردن. به نصب‌بودن borg در هر دو سر نیاز دارد و به پروتکل خودش صحبت می‌کند. restic همان تضمین‌ها را ارائه می‌دهد، درحالی‌که نسبت به backend بی‌تفاوت است: SFTP، فضای ذخیره‌سازی شیءمحورِ سازگار با S3، Backblaze B2، یا rest-server خودش. روی یک هدف SFTP ساده هیچ‌چیز نیاز به نصب ندارد، که راحت است، اما append-only در آن حالت به rest-server --append-only یا یک سیاست bucket بستگی دارد، نه به یک محدودیت SSH. قاعدهٔ سرانگشتی: وقتی مقصد سروری است که خودتان کنترلش می‌کنید، Borg؛ وقتی فضای ذخیره‌سازی شیءمحور است یا می‌خواهید یک ابزار را روی چندین backend مختلف استفاده کنید، restic.

چه چیزی را نباید استفاده کرد، چون این رایج‌ترین راهی است که این کار خراب می‌شود. rclone یک ابزار همگام‌سازی است. ریموتِ crypt آن واقعاً رمزنگاری سمت کلاینت به شما می‌دهد، اما یک sync، حذف‌ها را هم منتقل می‌کند — فایلی که ساعت 03:00 گم کرده‌اید، با وفاداری کامل، ساعت 03:15 از مقصد هم حذف می‌شود، که دقیقاً همان شکستی است که سعی داشتید از آن جان سالم به در ببرید. برای push کردن یک مخزن تمام‌شدهٔ Borg یا restic به یک مکان سوم عالی است؛ اما یک بک‌آپ نیست. همین ایراد به یک rsync --delete ساده در cron هم وارد است، که چیزی نیست جز یک mirror با لباس بک‌آپ به تن. tar | gpg به یک مسیر remote، یک بک‌آپ واقعی است، اما بدون حذف تکرار، بدون منطق نگه‌داری، و با یک بازیابی که یعنی طی‌کردن کل زنجیرهٔ افزایشی‌ها فقط برای پس‌گرفتن یک فایل. از ابزارهایی استفاده کنید که برای همین کار طراحی شده‌اند؛ همهٔ آن‌ها در هر توزیعی که در این راهنما نام برده شده، به‌صورت پکیج در دسترس‌اند.

Append-only، وگرنه مهاجم بک‌آپ‌های شما را هم حذف می‌کند

این همان سناریویی است که یک سیستم بک‌آپ را از یک اسکریپت بک‌آپ جدا می‌کند. یک نفر روی باکس تولید شما دسترسی root پیدا می‌کند — از طریق اپلیکیشن، یک وابستگی، یک کلید لو رفته، فرقی نمی‌کند از چه راهی. اولین کاری که یک باج‌افزار حرفه‌ای می‌کند، و اولین کاری که یک انسان حرفه‌ای می‌کند، گشتن به‌دنبال بک‌آپ‌هاست، چون قربانی‌ای که بک‌آپ‌های کاری دارد، نه پول می‌دهد و نه وحشت می‌کند. job شبانهٔ شما بدون دخالت اجرا می‌شود، پس اطلاعات ورودش الزاماً روی همان ماشین است. اگر job بتواند آرشیوها را حذف کند، مهاجم هم می‌تواند آرشیوها را حذف کند، و شما دقیقاً همان لحظه‌ای متوجه می‌شوید که به آن‌ها نیاز دارید. این یک حالت شکستِ فرضی نیست؛ همان حالت عادی است.

راه‌حل کوچک است، و مهم‌ترین سطر این راهنماست. روی مقصد، کلید خودکار را به یک دستور واحد در authorized_keys پین کنید: command="borg serve --append-only --restrict-to-path /srv/borg",restrict. آن کلید اکنون می‌تواند دقیقاً یک کار انجام دهد — اضافه‌کردن داده به یک مخزن، زیر یک مسیر واحد. نمی‌تواند یک shell بگیرد، نمی‌تواند یک پورت را forward کند، نمی‌تواند فایل‌سیستم شما را فهرست کند، و نمی‌تواند حتی یک آرشیو را هم حذف کند. کلیدواژهٔ restrict (در OpenSSH 7.2 به بعد) با یک کلمه، تخصیص pty و هر نوع forwarding را خاموش می‌کند، پس این محدودیت با اضافه‌شدن گزینه‌های جدید، فرسوده نمی‌شود. حالا آن نکتهٔ صادقانه‌ای که بیشتر آموزش‌ها از قلم می‌اندازند: تا وقتی append-only برقرار است، borg prune و borg compact به‌ظاهر موفق می‌شوند اما در واقع هیچ‌چیزی را آزاد نمی‌کنند — حذف در یک تراکنش ثبت می‌شود که نشست append-only بعدی آن را rollback می‌کند. بنابراین نگه‌داری به یک کلید دوم و بدون محدودیت نیاز دارد که آن را دستی، از لپ‌تاپ خودتان استفاده کنید و هرگز روی مبدأ ذخیره نکنید. دو کلید، دو کار: کلید شبانه فقط می‌تواند بنویسد؛ کلید نگه‌داری می‌تواند حذف کند و جایی زندگی می‌کند که ماشین آلوده‌شده به آن دسترسی ندارد. آن کلید را برای یک هدف دیگر هم دم‌دست نگه دارید — job که وسط اجرا کشته شود، یک قفل بات‌شده به‌جا می‌گذارد، و borg break-lock خودش یک نوشتن است.

نسخهٔ دوم کجا باید زندگی کند

بک‌آپ‌ها همان یک بارِ کاری‌اند که تأخیر در آن‌ها اهمیتی ندارد، پس آن غریزهٔ معمول برای نزدیک نگه‌داشتن ماشین به کاربرانتان را نادیده بگیرید و به‌جایش بر اساس قانون و استقلال انتخاب کنید. یک کشور متفاوت از تولید، کف کار است؛ یک خانوادهٔ حقوقیِ متفاوت بهتر است. هرکدام از مناطق ما به یک سؤال متفاوت پاسخ می‌دهد — رومانی پرچم‌دار ماست، جایی که اخطارهای DMCA اصلاً پردازش نمی‌شوند؛ سوئیس بیرون از اتحادیهٔ اروپا و پشت قوانین حفاظت از دادهٔ غیرمعمول‌سخت‌گیرانه‌ای قرار دارد؛ ایسلند چارچوب IMMI را دارد؛ پاناما نه قانون نگه‌داری اجباری داده دارد و نه مسیر سریعی برای درخواست‌های خارجی؛ مالزی یک نسخه را کاملاً بیرون از دسترس Five Eyes قرار می‌دهد؛ و هلند هاب peering است. کدام موقعیت آفشور را انتخاب کنید؟ به‌درستی همهٔ داد‌وستدها را بررسی می‌کند؛ برای یک هدف بک‌آپ، پاسخ معمولاً "هرجایی که تولید آنجا نیست" است. پورت‌ها روی هر پلن نامحدودند، پس اولین آپلود کامل، محدود به این است که مبدأ با چه سرعتی می‌تواند دیسک خودش را بخواند، نه به یک سهمیهٔ ترافیک که مجبور باشید جیره‌بندی‌اش کنید.

اندازه‌گیری کمتر از آنچه مردم انتظار دارند دراماتیک است. حذف تکرار به‌همراه zstd یعنی مخزن معمولاً فقط بخش کوچکی از حجم مبدأ است، و بعد از اولین اجرا، فقط تکه‌های تغییرکرده از شبکه عبور می‌کنند — یک سرور شلوغِ 40 GB با نرخ تغییر معمولی، به چند صد مگابایت در هر شب می‌رسد، پس یک سال آرشیو روزانه، دیسک بسیار کمتری نسبت به یک سال tarball روزانه مصرف می‌کند. کوچک‌ترین پلن روی این نردبان، هدفی کاملاً خوب است؛ فقط اگر دارید تاریخچهٔ عمیقی از چیزی واقعاً بزرگ نگه می‌دارید پلن بالاتر بروید، و مشخصات دقیق را روی صفحهٔ پلن‌ها بخوانید، نه اینکه به عددی که در یک راهنما نوشته شده و ممکن است با گذر زمان منسوخ شود اعتماد کنید. یک قاعده دربارهٔ خودِ باکس: هیچ کار دیگری به آن ندهید. نه وب‌سرور، نه پایگاه‌داده، هیچ سرویس عمومی‌ای به‌جز SSH با کلید. هدف بک‌آپی که یک پروژهٔ جانبی را هم میزبانی می‌کند، هدف بک‌آپی است که سطح حملهٔ آن پروژهٔ جانبی را هم دارد، و پیش از دریافت حتی یک آرشیو، باید کامل تحت رویهٔ اولین ساعت قرار بگیرد.

بک‌آپی که بازیابی‌اش نکرده‌اید، یک شایعه است

سیستم‌های بک‌آپ به‌ندرت با سروصدا شکست می‌خورند. شکست می‌خورند چون یک الگوی exclude بی‌سروصدا دایرکتوری داده را بلعیده، یا چون یک پایگاه‌داده فایل‌به‌فایل کپی شده درحالی‌که نوشتن‌ها در حال انجام بودند و dump به یک جدولِ درهم‌ریخته بازیابی می‌شود، یا چون تایمر شش هفته است پشت یک ارتقای توزیع دارد شکست می‌خورد و هیچ‌کس mail spool را نمی‌خواند. تنها آزمونی که هرکدام از این‌ها را کشف می‌کند، یک بازیابی است. آن را طبق یک زمان‌بند انجام دهید: یک آرشیو را تصادفی انتخاب کنید، آن را در یک دایرکتوری موقت extract کنید، چند فایل را با نسخهٔ تولید diff بگیرید، پایگاه‌داده را از dump راه‌اندازی کنید و یک کوئری اجرا کنید، و یادداشت کنید کل این کار چقدر طول کشید. آن عدد، زمان بازیابی واقعی شماست — نه آن‌که فرض کرده بودید — و تنها رقمی است که ارزش دارد ساعت سه بامداد به خودتان یادآوری کنید. دست‌کم یک‌بار، این تمرین را از یک ماشین کاملاً خالی انجام دهید، چون آن سناریوی واقعی است: یک VPS تازه، یک عبارت عبور از مدیر رمز عبورتان، یک کلید صادرشده از هرجایی که گذاشته‌اید، و هیچ‌چیز دیگر.

مانیتورینگ هم به همان تردیدی نیاز دارد که برای بقیهٔ استک به‌کار بردید. توصیهٔ رایج، یک dead-man's-switch شخص‌ثالث است که job شما هنگام موفقیت به آن ping می‌زند، که بی‌سروصدا به یک سرویس بیرونی می‌گوید hostnameهای شما چیست، زمان‌بندتان چیست و زیرساخت‌تان چه زمانی ناسالم است — چیز عجیبی برای بستن به ماشینی که عمداً بدون به‌جا گذاشتن هیچ هویتی خریده‌اید. به آن نیازی ندارید. تازگی را می‌شود کاملاً بدون کلید و از روی مقصد بررسی کرد: جدیدترین فایل قطعه در مخزن یک برچسب زمانی دارد، پس یک cron پنج‌خطی روی باکس بک‌آپ که وقتی طی ۲۵ ساعت چیزی نرسیده فریاد بزند، هیچ هزینه‌ای ندارد و هیچ‌چیزی را هم لو نمی‌دهد. یکپارچگی هم یک بررسیِ بدون‌کلید دارد — borg check --repository-only به‌صورت محلی روی مقصد اجرا می‌شود و ساختار قطعه‌ها را بدون آنکه هرگز داده‌های شما را ببیند، اعتبارسنجی می‌کند. گاهی هم گذر عمیق --verify-data را از روی مبدأ، با کلید نگه‌داری اجرا کنید — همان‌جایی که آن کلید متعلق به آن است.

چقدر هزینه دارد، و کجای استک قرار می‌گیرد

معادلهٔ اقتصادی‌اش اصلاً نزدیک هم نیست. یک VPS دوم از $8.00 در ماه، تأمین‌مالی‌شده از همان موجودی پیش‌پرداخت با شارژهای مجدد از $30.00، که در حدود 15 min آنلاین می‌شود، در برابر هزینهٔ از‌دست‌دادن هرچه روی ماشین اول است. آن را کنار بک‌آپ‌های سمت ارائه‌دهنده اجرا کنید، نه به‌جای آن‌ها: افزونهٔ بک‌آپ‌های رمزنگاری‌شدهٔ روزانه، حالتِ حذف‌کردنِ دایرکتوریِ اشتباه را بدون هیچ کاری از سمت شما و بدون فکرکردن ساعت سه بامداد مدیریت می‌کند، درحالی‌که آنچه اینجا ساخته‌اید، نسخه‌ای است که وقتی حساب، منطقه یا ارائه‌دهنده همان چیزی است که از بین رفته، همچنان مال شما می‌ماند. این دو، شکست‌های متفاوتی را پوشش می‌دهند و هیچ‌کدام جایگزین دیگری نیست، که کل هدف از شمردن تا سه همین است.

ارزش دارد جایی تمام کنیم که بک‌آپ‌ها نسبت به بقیهٔ چیزها کجا قرار می‌گیرند، چون این‌ها چهار کنترل‌اند که مستقل از هم شکست می‌خورند. اینکه میزبان دربارهٔ شما چه می‌داند، اولی است، و اینجا این مقدار تقریباً هیچ است — یک هندل و یک موجودی رمزارزی، موضوع پرداخت ناشناس برای هاستینگ. اینکه قانون از آنِ چه کسی باشد، دومی است، که با این تعیین می‌شود سخت‌افزار کجا قرار دارد، نه اینکه شما کجا هستید. اینکه ماشین چه چیزی را اجازه می‌دهد، سومی است، که همان اولین ساعت پس از استقرار است و پیکربندی‌اش فقط بر عهدهٔ خودتان است. و اینکه چه چیزی از خودِ ماشین جان سالم به در می‌برد، چهارمی است — تنها موردی که قولی است که به خودِ آیندهٔ خودتان می‌دهید، و تنها موردی که هیچ‌کس تا روزی که برای شروعش خیلی دیر شده باشد، آن را به شما یادآوری نمی‌کند. یک ساعت امشب، و یک تمرین بازیابی در تقویم. تمام ماجرا همین است.

گام‌به‌گام

1. 01

   هدف بک‌آپ را مستقر کنید و هیچ کار دیگری به آن ندهید

   یک VPS دوم را در منطقه‌ای مستقر کنید که تولید در آن زندگی نمی‌کند، و با آن مثل یک دستگاه تک‌منظوره رفتار کنید. چک‌لیست استاندارد اولین ساعت را روی آن اجرا کنید — SSH فقط-با-کلید، فایروال default-deny روی هر دو خانوادهٔ IP، به‌روزرسانی‌های امنیتی بدون دخالت — و بعد هیچ چیز دیگری باز نکنید. تنها پورت ورودی روی این ماشین، SSH است.

   ssh root@198.51.100.7
   apt update && apt full-upgrade -y
   hostnamectl set-hostname vault-01
   apt install -y borgbackup ufw unattended-upgrades
   ufw default deny incoming && ufw default allow outgoing
   ufw limit 22/tcp && ufw enable

2. 02

   یک حساب borg محدودشده با دو کلید بسازید

   روی مبدأ دو جفت‌کلید بسازید: یکی برای job شبانه (بدون عبارت عبور — چون باید بدون دخالت اجرا شود) و یکی برای نگه‌داری، که آن را فقط روی لپ‌تاپ خودتان نگه می‌دارید. روی هدف، یک کاربر borg بدون‌امتیاز بسازید و هر کلید را به یک دستور اجباری پین کنید. کلید job، --append-only می‌گیرد؛ کلید نگه‌داری نمی‌گیرد. همین یک فایل است که مهاجمی روی مبدأ را از پاک‌کردن تاریخچهٔ شما متوقف می‌کند.

   # on the source
   ssh-keygen -t ed25519 -N "" -f /root/.ssh/borg_job -C "job@edge-01"
   # on your laptop
   ssh-keygen -t ed25519 -f ~/.ssh/borg_maint -C "maint@laptop"
   
   # on the target
   adduser --disabled-password --gecos "" borg
   install -d -m 700 -o borg -g borg /home/borg/.ssh /srv/borg
   cat > /home/borg/.ssh/authorized_keys <<'EOF'
   command="borg serve --append-only --restrict-to-path /srv/borg",restrict ssh-ed25519 AAAA...job@edge-01
   command="borg serve --restrict-to-path /srv/borg",restrict ssh-ed25519 AAAA...maint@laptop
   EOF
   chown borg:borg /home/borg/.ssh/authorized_keys
   chmod 600 /home/borg/.ssh/authorized_keys

3. 03

   مخزن را initialise کنید، سپس کلید را از هر دو ماشین خارج کنید

   با کلید نگه‌داری و از روی لپ‌تاپ خودتان initialise کنید — ساختن یک مخزن، یک append نیست. یک مخزن به‌ازای هر میزبان مبدأ، نگه‌داری را بی‌دردسر و شعاع انفجار را کوچک نگه می‌دارد. سپس کلید را دوبار، در دو قالب export کنید، و هر دو export را جایی ببرید که نه مبدأ باشد نه هدف: یک مدیر رمز عبور، یک فلش USB رمزنگاری‌شده، یک برگه کاغذ در یک کشو. مخزنی که کلیدش فقط درون خودش وجود دارد، شیر یا خط است.

   export BORG_REPO='ssh://borg@198.51.100.7/srv/borg/edge-01'
   export BORG_RSH='ssh -i ~/.ssh/borg_maint'
   borg init --encryption=repokey-blake2
   
   borg key export :: /tmp/edge-01.borgkey
   borg key export --paper :: /tmp/edge-01.paper
   # move both off this machine, then shred the copies
   shred -u /tmp/edge-01.borgkey /tmp/edge-01.paper

4. 04

   پیش از خواندن دیسک، وضعیت اپلیکیشن را freeze کنید

   کپی‌کردن فایل‌به‌فایلِ یک دایرکتوری پایگاه‌دادهٔ زنده، فایلی تولید می‌کند که شبیه پایگاه‌داده به‌نظر می‌رسد اما مثل یک صحنهٔ جرم بازیابی می‌شود. اول dump بگیرید، از آن دامپ بک‌آپ بگیرید، و دایرکتوری دادهٔ خام را exclude کنید. همین منطق دربارهٔ هرچیزی با یک قالبِ روی‌دیسک که کنترلش نمی‌کنید هم صدق می‌کند: از آن dump بگیرید، یا آن را برای همان چند ثانیه‌ای که اسنپ‌شات طول می‌کشد متوقف کنید.

   install -d -m 700 /var/backups/dumps
   mariadb-dump --single-transaction --quick --all-databases \
     > /var/backups/dumps/mariadb.sql
   # PostgreSQL:
   # sudo -u postgres pg_dumpall > /var/backups/dumps/pg.sql
   chmod 600 /var/backups/dumps/*.sql

5. 05

   job بک‌آپ را بنویسید و روی یک تایمر بگذارید

   اسکریپت را خسته‌کننده نگه دارید و بگذارید با سروصدا شکست بخورد. عبارت عبور از یک فایل با مجوز 600 و از راه BORG_PASSCOMMAND می‌آید، پس هرگز در فهرست پردازش‌ها ظاهر نمی‌شود. آرشیوها را با نام میزبان و یک برچسب زمانی ISO نام‌گذاری کنید تا مرتب شوند. توجه کنید در این اسکریپت چه چیزی وجود ندارد: نه prune، نه delete — کلید job اصلاً نمی‌توانست آن‌ها را اجرا کند. تایمری با Persistent=true بعد از یک ری‌استارت خودش را جبران می‌کند، و یک تأخیر تصادفی‌شده جلوی این را می‌گیرد که همهٔ ماشین‌های شما در یک ثانیهٔ واحد آپلود کنند.

   cat > /usr/local/sbin/borg-backup.sh <<'EOF'
   #!/bin/bash
   set -euo pipefail
   export BORG_REPO='ssh://borg@198.51.100.7/srv/borg/edge-01'
   export BORG_RSH='ssh -i /root/.ssh/borg_job -o BatchMode=yes'
   export BORG_PASSCOMMAND='cat /root/.config/borg/passphrase'
   borg create --stats --compression zstd,6 --one-file-system \
     --exclude-caches --exclude '/var/cache/*' \
     --exclude '/var/lib/mysql' --exclude '/home/*/.cache' \
     ::'{hostname}-{now:%Y-%m-%dT%H:%M}' \
     /etc /root /home /srv /var/www /var/backups/dumps
   EOF
   chmod 700 /usr/local/sbin/borg-backup.sh
   
   cat > /etc/systemd/system/borg-backup.service <<'EOF'
   [Unit]
   Description=Off-site Borg backup
   [Service]
   Type=oneshot
   Nice=10
   IOSchedulingClass=idle
   ExecStart=/usr/local/sbin/borg-backup.sh
   EOF
   
   cat > /etc/systemd/system/borg-backup.timer <<'EOF'
   [Unit]
   Description=Nightly off-site Borg backup
   [Timer]
   OnCalendar=*-*-* 03:17:00
   RandomizedDelaySec=900
   Persistent=true
   [Install]
   WantedBy=timers.target
   EOF
   systemctl daemon-reload
   systemctl enable --now borg-backup.timer

6. 06

   Prune با کلید نگه‌داری، compact روی هدف

   نگه‌داری نمی‌تواند از روی مبدأ اجرا شود، چون کلید مبدأ append-only است و حذف‌هایش بی‌سروصدا rollback می‌شوند. به‌جایش آن را از روی لپ‌تاپ خودتان و با هر ریتمی که برایتان مناسب است اجرا کنید — ماهانه کاملاً کافی است. prune تصمیم می‌گیرد کدام آرشیوها نگه داشته شوند؛ compact چیزی است که واقعاً دیسک را پس می‌گیرد. اول یک --dry-run بزنید و فهرست را بخوانید، پیش از آنکه بگذارید چیزی حذف شود.

   export BORG_REPO='ssh://borg@198.51.100.7/srv/borg/edge-01'
   export BORG_RSH='ssh -i ~/.ssh/borg_maint'
   
   borg prune --dry-run --list \
     --keep-daily 7 --keep-weekly 4 --keep-monthly 6
   borg prune --list --stats \
     --keep-daily 7 --keep-weekly 4 --keep-monthly 6
   borg compact --progress

7. 07

   تمرین بازیابی را اجرا کنید، سپس runbook را بنویسید

   پیش از آنکه لازم شود، بازیابی کنید. یک آرشیو واقعی را در یک دایرکتوری موقت extract کنید، چند فایل را با نسخه‌های اصلی مقایسه کنید، و دامپ پایگاه‌داده را در یک اسکیمای یک‌بارمصرف بارگذاری کنید. سپس آن دو بررسی‌ای را اضافه کنید که بدون توجه شما اجرا می‌شوند: یک هشدار تازگیِ بدون‌کلید روی هدف، و یک گذرِ یکپارچگیِ دوره‌ای. در پایان، سه واقعیتی را که در بدترین روزتان لازم خواهید داشت یادداشت کنید — کلید صادرشده کجا زندگی می‌کند، عبارت عبور کجا زندگی می‌کند، و دستورهای دقیق زیر.

   borg list ::
   mkdir -p /var/tmp/drill && cd /var/tmp/drill
   borg extract --list ::edge-01-2026-08-31T03:17 etc/nginx
   diff -r etc/nginx /etc/nginx && echo 'restore OK'
   
   # on the target, no key needed:
   borg check --repository-only /srv/borg/edge-01
   find /srv/borg/edge-01/data -type f -mmin -1500 | head -1   # empty = stale