چطور از سرور مجازی بکاپ بگیریم؟
نسخه خارج از VPS، سازگاری داده و آزمون Restore
بکاپ زمانی ارزش دارد که پس از خرابی، حذف اشتباه، compromise یا ازکارافتادن زیرساخت بتوانید با آن سرویس را برگردانید. یک archive روی همان دیسک، یک snapshot بدون کپی مستقل یا job سبزرنگی که هرگز restore نشده، طرح بازیابی نیست.
اول RPO و RTO را به زبان کسبوکار تعریف کنید
RPO بیشترین دادهای است که میتوانید از دست بدهید؛ اگر RPO یک ساعت است، نسخه روزانه کافی نیست. RTO بیشترین زمان قابلتحمل برای بازگرداندن سرویس است؛ archive بزرگ روی storage کند ممکن است backup سالم باشد اما RTO را نقض کند. این دو هدف، تناوب، نوع backup و محل نگهداری را تعیین میکنند.
وابستگیها را نیز فهرست کنید: DNS، گواهی و کلید، repository، image، مجوز نرمافزار، حساب cloud، runbook و فرد دارای دسترسی. بازیابی فایل برنامه بدون credential دیتابیس یا دستور راهاندازی، سرویس قابل استفاده تحویل نمیدهد. برای هر سرویس owner و اولویت بازگشت مشخص کنید.
دقیقاً چه چیزهایی باید در backup باشد؟
فهرست معمول شامل داده کاربر، uploadها، دیتابیس، configuration برنامه و وبسرور، unitهای systemd، jobهای زمانبندی، certificate/کلید در صورت نیاز و inventory نسخههاست. cache، فایل موقت و artifact قابلساخت را میتوان برای کاهش حجم حذف کرد، به شرط آنکه روش ساخت دوباره مستند و آزموده باشد.
secretها باید با کنترل دسترسی و رمزگذاری قوی نسخهبرداری شوند؛ حذف همه آنها از backup ممکن است restore را غیرممکن کند، و ذخیره بدون حفاظت نیز رخداد امنیتی میسازد. کلید رمزگشایی backup را فقط داخل همان VPS نگه ندارید، وگرنه با از دسترفتن سرور نسخه سالم هم غیرقابل استفاده میشود.
نسخه سازگار با برنامه و دیتابیس بسازید
کپی فایل خام یک دیتابیس در حال نوشتن ممکن است از نظر برنامه ناسازگار باشد. از ابزار پشتیبانگیری همان موتور—مانند SQL dump، base backup یا روش point-in-time مستندشده—استفاده کنید و الزامات lock، WAL/binlog و نسخه مقصد را بدانید. برای سیستم تراکنشی، ترتیب backup دیتابیس و فایلهای وابسته باید یک نقطه منطقی قابل بازیابی بسازد.
freeze یا توقف کوتاه برنامه میتواند سازگاری را ساده کند، اما اثر آن بر کاربران باید برنامهریزی شود. agent یا snapshot application-aware گزینه دیگری است، به شرط آنکه واقعاً با workload شما سازگار باشد. خروج موفق ابزار را همراه log، اندازه و مدت ثبت کنید؛ فایل صفر بایت یا dump ناقص نباید «موفق» گزارش شود.
کپی را خارج از همان VPS و failure domain نگه دارید
نسخهای که فقط روی دیسک همان VM است در برابر خرابی دیسک مجازی، حذف VM، باجافزار یا قفل حساب محافظت نمیکند. حداقل یک کپی را به storage یا سامانهای جدا منتقل کنید؛ برای ریسک بالاتر، حساب/credential و مکان مستقل یا کپی offline/immutable نیز بررسی شود. هدف این است که یک رخداد واحد، production و همه backupها را همزمان نابود نکند.
قاعده 3-2-1 یک یادآور مفید است: چند کپی، بیش از یک نوع/سامانه نگهداری و دستکم یک کپی خارج از محل اصلی. آن را نسخهبرداری مکانیکی ندانید؛ تهدید، RPO، RTO و بودجه شما طرح نهایی را تعیین میکنند. انتقال backup نیز باید رمزگذاری و دسترسی آن حداقلی باشد.
چرا snapshot مساوی backup نیست؟
snapshot وضعیت storage/VM را در یک نقطه نگه میدارد و برای rollback کوتاه پیش از update یا تغییر پرریسک مفید است. اما معمولاً به همان storage، control plane و چرخه عمر VM وابسته است؛ حذف یا خرابی زیرساخت اصلی میتواند snapshot را نیز از بین ببرد. نگهداری طولانی snapshot همچنین ممکن است هزینه، کارایی یا پیچیدگی merge ایجاد کند.
اگر platform امکان export یا copy مستقل snapshot به مقصد جدا میدهد، آن کپی میتواند بخشی از راهبرد backup باشد؛ باز هم سازگاری برنامه و restore باید آزموده شود. نام «snapshot» یا «backup» در پنل معیار کافی نیست—مکان فیزیکی/منطقی، وابستگیها، retention و شیوه بازیابی را سؤال کنید.
Retention، رمزگذاری و مانیتورینگ را خودکار کنید
نسخهها را بر اساس نیاز ساعتی، روزانه، هفتگی یا بلندمدت نگه دارید و پاکسازی را طوری طراحی کنید که خطای امروز فوراً همه نقاط سالم قبلی را حذف نکند. backup افزایشی حجم را کم میکند، اما زنجیره restore و وابستگی به base باید کنترل شود. فضای مقصد، زمان job، نرخ تغییر و failure انتقال را هشدار دهید.
checksum و فرمان check ابزار backup خرابی ذخیرهسازی یا repository را زودتر آشکار میکنند، ولی جای restore برنامه را نمیگیرند. کلیدها را rotate و دسترسی نوشتن/حذف backup را از credential روزمره production جدا کنید. گزارش موفقیت باید به کسی برسد که failure را پیگیری میکند، نه فقط در log همان سرور باقی بماند.
آزمون Restore، بخش اصلی بکاپ است
در محیط جدا و بدون overwrite تولید، یک سرور خالی را از روی runbook بازیابی کنید: زیرساخت پایه، secret، فایل، دیتابیس، سرویسها و DNS آزمایشی. سپس integrity کاربردی را بسنجید؛ ورود، خواندن رکورد جدید، دانلود فایل، job و API باید کار کنند. زمان واقعی را ثبت و با RTO مقایسه کنید.
آزمون نمونه کوچک مفید است اما جای drill کامل را نمیگیرد. آن را پس از تغییر معماری، نسخه دیتابیس یا ابزار backup و نیز بهصورت دورهای تکرار کنید. خروجی آزمون باید کمبود runbook، permission، key و dependency را به اقدام اصلاحی تبدیل کند. backup تأییدنشده یک فرض است، نه تضمین بازیابی.
پرسشهای پرتکرار
آیا نگهداری backup داخل همان VPS کافی است؟
خیر. در برابر حذف VM، خرابی storage، compromise یا قفل حساب همان failure domain محافظتی ندارد. یک کپی مستقل و رمزگذاریشده خارج از همان VPS لازم است.
آیا snapshot همان backup است؟
بهتنهایی خیر. snapshot معمولاً به VM و storage اصلی وابسته و برای rollback کوتاه مناسب است. backup مستقل باید failure domain جدا، retention و مسیر restore آزمودهشده داشته باشد.
هر چند وقت یکبار backup بگیرم؟
بر اساس RPO و نرخ تغییر داده. اگر فقط یک ساعت داده قابل از دستدادن است، تناوب باید آن هدف را پوشش دهد؛ نسخه روزانه برای چنین RPOای کافی نیست.
آیا کپی پوشه دیتابیس کافی است؟
برای دیتابیس در حال اجرا ممکن است ناسازگار باشد. از روش رسمی همان موتور مانند dump، base backup یا point-in-time recovery با الزامات نسخه و log استفاده کنید.
از کجا بفهمم backup سالم است؟
check و checksum مفیدند، اما معیار نهایی restore در محیط جدا و آزمون داده و عملکرد برنامه است. مدت بازیابی را نیز با RTO بسنجید.
کلید رمزگذاری backup را کجا نگه دارم؟
در password/secret manager یا سامانه امن جدا با دسترسی محدود و مسیر بازیابی مستند؛ تنها کپی آن نباید داخل VPS یا کنار همان backup بدون حفاظت باشد.
منابع رسمی و مطالعه بیشتر
پیش از استقرار، ظرفیت بکاپ را هم حساب کن
حجم داده، ترافیک خروجی، RPO و زمان بازیابی را در انتخاب زیرساخت لحاظ کن.