سرور برای بک‌آپ

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

خبر خوب این است که یک سرور بک‌آپ لازم نیست گران باشد. این نقش دقیقاً برعکس بقیه کاربردهاست: کمترین پردازنده و حافظه، بیشترین دیسک.

چرا اسنپ‌شات کافی نیست؟

اسنپ‌شات ابزار خوبی است، اما برای مسئله دیگری. تفاوت را روشن کنیم:

اسنپ‌شات را برای «قبل از به‌روزرسانی، محض احتیاط» استفاده کنید. بک‌آپ روی سرور جدا را برای «اگر همه‌چیز از بین رفت».

قاعده ۳-۲-۱ را به یاد بسپارید: سه نسخه از داده، روی دو نوع رسانه متفاوت، که یکی خارج از محل اصلی باشد. سرور بک‌آپ در لوکیشنی دیگر، همان یکِ خارج از محل است.

انتخاب منابع

این تنها کاربردی است که در آن عمداً نامتوازن خرید می‌کنید:

دیسک را دو تا سه برابر داده فعلی بگیرید. بک‌آپ تنها یک نسخه نیست؛ نسخه‌های تاریخی نگه می‌دارید تا بتوانید به یک هفته پیش برگردید، نه فقط به دیروز. ابزارهایی مثل Restic داده تکراری را حذف می‌کنند و همین کمک بزرگی است، اما باز هم فضا لازم است.

پردازنده و حافظه را کم بگیرید. اگر رمزنگاری و فشرده‌سازی کمی کند انجام شود اهمیتی ندارد؛ این کار در پس‌زمینه و شبانه اجرا می‌شود.

لوکیشن: جدا از سرور اصلی

این نکته کل هدف کار است. سرور بک‌آپ باید جایی باشد که یک رویداد نتواند هم آن و هم سرور اصلی را از بین ببرد:

گرفتن بک‌آپ روی سروری در همان دیتاسنتر بهتر از هیچ است، اما هدف اصلی — جداسازی ریسک — را برآورده نمی‌کند.

رمزنگاری الزامی است

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

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

دقیقاً از چه چیزی بک‌آپ بگیرید؟

فهرستی که معمولاً ناقص نوشته می‌شود. بک‌آپ گرفتن از پوشه فایل‌های سایت کافی نیست:

• داده برنامه — فایل‌های آپلودی، رسانه، اسناد
• دیتابیس — با ابزار خروجی خود دیتابیس، نه کپی مستقیم فایل‌ها. کپی فایل دیتابیسی که در حال نوشتن است می‌تواند ناسازگار باشد
• فایل‌های پیکربندی — تنظیمات وب‌سرور، متغیرهای محیطی، فایل‌های Compose
• کرون‌جاب‌ها — crontab -l و محتوای /etc/cron.d/
• گواهی‌ها و کلیدها — اگر خودکار صادر نمی‌شوند
• volumeهای داکر — اگر با کانتینر کار می‌کنید، داده واقعی آنجاست نه در فایل Compose. توضیح بیشتر در صفحه سرور برای داکر

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

آزمایش بازیابی؛ کاری که همه فراموش می‌کنند

این مهم‌ترین جمله این صفحه است: بک‌آپی که هرگز بازیابی نشده، بک‌آپ نیست.

مشکلات رایجی که فقط هنگام آزمایش بازیابی معلوم می‌شوند:

• مسیری که فکر می‌کردید در بک‌آپ هست، در تنظیمات جا افتاده
• دیتابیس در حال نوشتن بوده و خروجی ناسازگار است
• رمز مخزن اشتباه یادداشت شده
• کرون‌جاب چند ماه است خطا می‌دهد و کسی متوجه نشده

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

راه‌اندازی

راهنمای بک‌آپ خودکار با Restic مسیر کامل را پوشش می‌دهد: نصب، ساخت مخزن رمزنگاری‌شده، زمان‌بندی خودکار و سیاست نگهداری نسخه‌ها.

سرور بک‌آپ را هم مثل هر سرور دیگری امن کنید — راهنمای امن‌سازی سرور لینوکس. سروری که همه داده‌های شما را نگه می‌دارد، هدف ارزشمندی است.

نگهداری

جمع‌بندی

سرور برای بک‌آپ ارزان‌ترین بیمه‌ای است که می‌توانید بخرید: کمترین پردازنده و حافظه، بیشترین دیسک، در لوکیشنی جدا از سرور اصلی.

اسنپ‌شات را کنار آن نگه دارید اما جایگزینش نکنید. و هر سه ماه یک‌بار بازیابی را آزمایش کنید — این تنها راه دانستن این است که بک‌آپ شما واقعاً کار می‌کند.

ساخت سرور ابری برای بک‌آپ