هر بکاپی کار میکند، تا روزی که واقعاً به آن نیاز باشد. اسنپشات روی همان پلتفرمی نشسته که تازه از کار افتاده. tarball شبانه از وقتی یک دیسک در مارس پر شده، بیسروصدا شکست میخورد. دامپ پایگاهداده یک کپی فایل بوده که وسط نوشتن گرفته شده، و بازیابیاش به هیچ میرسد. بکاپها تنها بخشی از یک سرور هستند که نمیتوانید فقط با نگاهکردن دربارهٔ آنها قضاوت کنید — فقط با بازیابیکردنشان. این نحوه ساختن بکاپی است که در برابر خرابی سختافزار، دست خودتان و کسی که اعتبارنامههای شما را در اختیار دارد دوام بیاورد، بدون آنکه یک کپی قابلخواندن از دستگاه را به هر کسی که آن را نگه میدارد بدهید.
چهار چیز یک سرور را از بین میبرد، و هرکدام به چیز متفاوتی نیاز دارد
بکاپ را حول محور خرابی طراحی کنید، نه حول محور ابزار. تقریباً هر ازدسترفتن واقعی زیر چهار سناریو جا میگیرد، و هرکدام از نسخهای که نگه میدارید چیز متفاوتی میخواهد. چیدمانی که یکی از آنها را پوشش میدهد، کاملاً کافی به نظر میرسد — تا وقتی با سناریوی دیگری روبهرو شود.
خرابی سختافزار یا میزبان
دیسک، نود یا دیتاسنتر از کار میافتد. هر کپیای که هر جای دیگری نگهداشته باشید نجاتتان میدهد. این تنها خرابیای است که یک اسنپشات روی همان پلتفرم بهطور قابلاعتماد پوشش میدهد — و دقیقاً به همین دلیل است که خیلیها فکر میکنند اسنپشات کافی است.
دست خودتان
یک فلگ اشتباه، یک اسکریپت مهاجرت که بهسمت پروداکشن نشانه رفته، یک پاکسازی که بیشتر از حد لازم چیز حذف کرده. این آسیب فوراً به هر چیزی که آینه (mirror) میکند سرایت میکند، پس آنچه نجاتتان میدهد تاریخچه است — نسخهای از پیش از اشتباه، نه یک کپی فعلی از بعد آن.
نفوذ و باجافزار
مهاجمی با دسترسی root دقیقاً همان دسترسیای را دارد که کار بکاپگیری شما دارد: همان اعتبارنامهها، همان مقصد، همان زمانبندی. اگر سرور بتواند بکاپهای خودش را حذف کند، حذف خواهند شد. بقا به این بستگی دارد که کپی، فقطالحاقی باشد یا کاملاً خارج از دسترس.
از دستدادن حساب، نه سرور
وقفه در صورتحساب، یک حساب تعلیقشده، یک حذف محتوا (takedown) در حوزهٔ قضایی نادرست. سختافزار کاملاً سالم است و شما بهسادگی نمیتوانید به آن دسترسی داشته باشید. اینجا فقط یک کپی زیر یک ارائهدهندهٔ متفاوت، با مسیر پرداختی متفاوت، کمک میکند.
پیش از انتخاب هرچیزی، بنویسید دقیقاً در برابر کدامیک از این چهار مورد دارید از خودتان دفاع میکنید. یک کپی شبانه در یک دایرکتوری دوم روی همان دیسک، دقیقاً یکی از آنها را پوشش میدهد — بعیدترینشان را — درحالیکه کاملاً حس یک بکاپ واقعی را میدهد. بیشتر چیدمانهایی که در پروداکشن شکست میخورند، به این دلیل شکست میخورند که هیچکس هرگز سناریو را نام نبرده.
اسنپشاتها بکاپ نیستند
این دو کلمه اغلب بهجای هم استفاده میشوند، اما دو چیز متفاوت با دو حوزهٔ خرابی متفاوت را توصیف میکنند. دانستن اینکه کدامیک را دارید، تعیین میکند که اصلاً چیزی دارید یا نه.
از اسنپشاتها برای همان کاری استفاده کنید که واقعاً در آن عالیاند: یک بازگشت پنجثانیهای پیش از دستزدن به کرنل، بوتلودر یا اسکیمای پایگاهداده. یکی بگیرید، کار پرریسک را انجام دهید، و وقتی جواب داد حذفش کنید. کاری که هرگز نباید بکنید این است که بگذارید عبارت "یک اسنپشات که هست" دلیل نبود بکاپ شود — سرنوشت یک اسنپشات با همان پلتفرمی که نگهش میدارد گره خورده، و یک حساب تعلیقشده هر دو را یکجا با خودش میبرد.
قاعدهٔ 3-2-1، و دو عددی که همه از قلم میاندازند
این قاعدهٔ قدیمی دوام آورده چون استقلال را توصیف میکند، نه یک سیستم بایگانی: سه نسخه از داده، روی دو نوع فضای ذخیرهسازی متفاوت، که یکیشان جای دیگری باشد. دو مورد اضافه هم خرابیهایی را پوشش میدهند که زمان نوشتن این قاعده کمیاب بودند و امروز عادیاند.
- سه نسخه. دادههای زنده بهعلاوهٔ دو بکاپ. دو نسخه یعنی فقط با یک بازیابی ناموفق، به صفر میرسید.
- دو رسانه، یا دو ارائهدهنده. روی زیرساخت اجارهای، "رسانه" در واقعیت یعنی استقلال اداری — یک کپی دوم زیر همان حساب، روی همان پلتفرم، پرداختشده از همان موجودی، فقط همان یک کپی است با چند مرحلهٔ اضافه.
- یک نسخه خارج از سرور. ساختمانی متفاوت، شبکهای متفاوت، و اگر برایتان مهم است، حوزهٔ قضاییای متفاوت. /locations نسخهٔ عملی همین ایده است: منطقهای انتخاب کنید که مستقل از منطقهای که دارید از آن محافظت میکنید از کار بیفتد.
- یک نسخهٔ تغییرناپذیر یا آفلاین. کپیای که خود سرور نمیتواند حذفش کند، چون هرکس مالک سرور است، مالک اعتبارنامههای آن هم هست.
- صفر بازیابی تأییدنشده. بکاپی که هرگز بازیابیاش نکردهاید، فقط یک فرضیه است. عددی که اهمیت دارد این است که چند بازیابی را کامل کردهاید، نه اینکه چند اجرا موفقیت گزارش داده.
از دادهها بکاپ بگیرید، بقیه را بازسازی کنید
غریزهٔ اول این است که از همهچیز ایمیج بگیرید. این کار پرهزینه است، بازیابیاش کند است، و باینری بهخطرافتاده، وضعیت خراب پکیجها و انحراف کانفیگی را که دیگر یادتان نیست کی ایجادش کردهاید، وفادارانه حفظ میکند. یک سرور سه نوع محتوا دارد، و فقط یکی از آنها جایش در بکاپ است.
- اینها را وارد کنید: /etc، /home، /root، /srv، web root شما، دایرکتوری وضعیت اپلیکیشنتان، ولومهای نامگذاریشدهٔ کانتینر، و یک دایرکتوری از دامپهای تازهٔ پایگاهداده.
- خود دستورالعمل استقرار را هم وارد کنید — فایلهای compose، اسکریپتهای Ansible یا شل، یادداشتهایی که ساعت دو بامداد نوشتهاید. آن را در version control هم نگه دارید، اما یک کپی در بکاپ هم بگذارید تا بازیابی هرگز به در دسترس بودن یک سرویس دوم وابسته نباشد.
- اینها را کنار بگذارید: /proc، /sys، /dev، /run و دایرکتوریهای موقت. اینها واسطهای کرنل و فضای کاری موقتاند؛ کپیکردنشان یا وقت تلف میکند یا کل اجرا را کاملاً هنگ میکند.
- کشهای پکیج، دایرکتوریهای بیلد، درختهای dependency و virtualenvها را هم کنار بگذارید — هرچیزی که یک مرحلهٔ بیلد دوباره میسازد. روی یک سرور اپلیکیشن معمولی، این بیشتر حجم دیسک را تشکیل میدهد.
- اگر دارید بهدرستی از پایگاهداده دامپ میگیرید، فایلهای زندهٔ پایگاهداده را کنار بگذارید. بکاپگرفتن از هر دو یعنی همان کپی بزرگتر و بیفایده، همانی است که یک نفر ساعت سه بامداد بازیابیاش میکند.
- فایلهای مخفی را کنار نگذارید. نیمی از چیزهایی که روی یک ماشین لینوکسی اهمیت دارند، با یک نقطه شروع میشوند.
پایگاهدادهها یک کپی فایلی را تاب نمیآورند
این تنها رایجترین دلیل شکستخوردن یک بازیابی است. یک پایگاهدادهٔ در حال اجرا وضعیتش را در حافظه نگه میدارد و خارج از ترتیب مینویسد؛ کپیکردن فایلهایش درحالیکه در حال اجراست، وضعیتی ناقص و نیمهنوشته را ثبت میکند که ممکن است بازیابی شود، ممکن است بیسروصدا خراب بازیابی شود، یا اصلاً بازیابی نشود. یک دامپ درست بگیرید، بعد از آن دامپ بکاپ بگیرید.
- PostgreSQL: برای هر پایگاهداده pg_dump، یا برای کل کلاستر شامل roleها، pg_dumpall. جایی که ازدستدادن یک روز غیرقابلقبول است، آرشیوسازی WAL هم اضافه کنید تا بتوانید به یک نقطهٔ زمانی مشخص بازیابی کنید، نه فقط به دیشب.
- MySQL یا MariaDB: mysqldump با --single-transaction روی InnoDB یک اسنپشات سازگار میدهد، بدون آنکه جلوی نوشتنها را بگیرد. روی MyISAM اینطور نیست — یک دلیل دیگر برای اجرا نکردن MyISAM. برای دیتاستهای بزرگ، یک ابزار فیزیکی مثل mariabackup بسیار سریعتر از replay کردن یک دامپ بازیابی میکند.
- SQLite: هرگز فایل را کپی نکنید. از دستور .backup یا VACUUM INTO استفاده کنید، که قفل را بهدرستی میگیرند. کپیکردن یک پایگاهداده با یک write-ahead log فعال، مثل شیر یا خط انداختن است — دیر یا زود میبازید.
- Redis: یک background save راه بیندازید و از فایل اسنپشات حاصل بکاپ بگیرید، یا با append-only mode اجرا کنید و از لاگ بکاپ بگیرید. کپیکردن یک اسنپشات زنده وسط نوشتن، فایلی بریدهشده به شما میدهد که مثل یک دیتاست خالی لود میشود.
- کانتینرها: ولوم همان داده است. برای همان چند ثانیهای که کپیکردن طول میکشد، استک را متوقف کنید، یا ابزار دامپ را داخل کانتینر اجرا کنید — اما ولوم یک پایگاهدادهٔ در حال اجرا را tar نکنید و اسمش را بکاپ نگذارید.
- هر چیز دیگری که یک پردازهٔ پایدار دارد — ایندکسهای جستوجو، صفهای پیام، دیمنهای ledger — دستور صادرات سازگار خودش را دارد. همین حالا پیدایش کنید، نه وسط یک قطعی.
اسنپشاتهای فایلسیستمی این مسئله را از جهت دیگری حل میکنند: LVM، ZFS و btrfs در چند میلیثانیه یک نمای سازگار از ولوم را منجمد میکنند، و شما از همان نمای منجمدشده بکاپ میگیرید درحالیکه پایگاهداده همچنان سرویس میدهد. این پاسخ درست برای دیتاستهایی است که گرفتن دامپ ساعتها طول میکشد. اما دلیلی نیست برای رد کردن دامپ در یک پایگاهدادهٔ 200 MB، جایی که دامپ سادهتر است، میان نسخههای مختلف engine قابلجابهجایی است، و وقتی چیزی عجیب شده، برای یک انسان قابلخواندن است.
انتخاب یک ابزار
چهار ابزار تقریباً همهٔ موارد را پوشش میدهند. مهمترین ویژگی این است که رمزنگاری کجا اتفاق میافتد. اگر داده فقط در حین انتقال رمزنگاری شود، و بعد در حالت سکون توسط ارائهدهندهٔ ذخیرهسازی، آن ارائهدهنده میتواند آن را بخواند — و بکاپ بیسروصدا به ضعیفترین نقطهٔ سیستمی تبدیل شده که همهجای دیگرش را مقاوم کردهاید.
هرچه انتخاب کنید، عبارت عبور یا کلید باید جایی جز همان سروری که دارد بکاپ گرفته میشود وجود داشته باشد. این همان تلهای است که آدمهای محتاط را هم میگیرد: کلید مخزن که در /root ذخیره شده، وفادارانه داخل همان مخزنی بکاپ گرفته شده که خودش بازش میکند. آن را چاپ کنید، یا در یک مدیر گذرواژه نگه دارید که بتوانید از یک ماشین هنوز زنده باز کنید. مخزنی که نمیتوانید رمزگشاییاش کنید، هیچ فرقی با نبود هیچ بکاپی ندارد.
نسخهٔ دوم کجا باید زندگی کند
مقصد به همان اندازه که فضای دیسک است، یک حوزهٔ قضایی و یک رابطهٔ مالی هم هست. چهار گزینه، تقریباً به ترتیب اینکه چقدر از سروری که دارید محافظتش میکنید مستقلاند.
یک سرور دوم در منطقهای دیگر
پاسخ ساده: یک اینستنس ارزان در کشوری دیگر، قابلدسترسی روی SSH، که چیزی جز sshd و یک مخزن روی آن اجرا نمیشود. یک پلن /vps با 1 GB بکاپهای یک ناوگان کوچک را در خودش جا میدهد، و میشود حساب را به یک دستور اجباری تکی قفل کرد تا یک کلید دزدیدهشده هیچ شلی باز نکند.
دیسک ردهٔ ذخیرهسازی
بهمحض اینکه دیتاست به صدها گیگابایت برسد، ظرفیت HDD روی یک آپلینک نامحدود، به ازای هر ترابایت بسیار ارزانتر از NVMe تمام میشود، و نوشتن بکاپ هم اصلاً نیازی به تأخیر NVMe ندارد. /storage دقیقاً برای همین ساخته شده: دیسک محافظتشده با RAID در مقیاس ترابایت، root کامل، و بدون بازرسی محتوا.
object storage سازگار با S3
راحت، با قیمتگذاری هر گیگابایت، و اغلب با پشتیبانی object-lock که تغییرناپذیری واقعی میدهد. پیش از تکیهکردن به آن، قیمت egress را بخوانید — کشیدن یک ترابایت در یک اورژانس، لحظهٔ خوبی برای کشفکردن هزینهٔ retrieval نیست.
سختافزاری که خودتان دارید
یک دیسک خارجی یا یک دستگاه در خانه، که بهجای push شدن، pull میشود. کندتر و دستی، و تنها کپی این فهرست که هیچ ارائهدهنده، حکم دادگاه یا اختلاف مالیای نمیتواند به آن دست بزند. برای دادهای که واقعاً نمیتوانید دوباره بسازید، ارزش نگهداشتن دارد، حتی اگر یک هفته عقبتر باشد.
ویژگیهای حریم خصوصی بکاپ را با همانهای سرور جور کنید. رمزنگاری یک دیسک با LUKS و بعد فرستادن بکاپهای شبانهٔ متنساده به یک bucket که زیر نام کارت شما ثبت شده، کل این تمرین را بیاثر میکند: حالا داده قابلخواندن است، و زیر نام خودتان بایگانی شده. اگر پرداخت ناشناس برای سرور میارزید، برای این کپی هم میارزد — سمت کلاینت رمزنگاری کنید، و مقصد را همانطوری بخرید که مبدأ را خریدید.
ساختنش، گام به گام
- 1
اول این دو عدد را مشخص کنید
چقدر از داده را میتوانید از دست بدهید — فاصلهٔ میان دو اجرا — و چقدر میتوانید از کار افتاده باشید. بقیهٔ چیزها از همین دو پاسخ میآید. بکاپ ساعتی از یک سایت استاتیک صرفاً نمایش است؛ بکاپ شبانه از یک پایگاهدادهٔ سفارشها، تصمیمی است که باید آگاهانه گرفت، نه از یک آموزش به ارث برد.
- 2
مقصد را بسازید
یک اینستنس دوم در منطقهای دیگر با کلید SSH خودش و یک کاربر اختصاصی و بدونامتیاز که خانهاش همان مخزن است. هیچچیز دیگری آنجا اجرا نمیشود. کلید را به یک دستور اجباری محدود کنید تا یک اعتبارنامهٔ دزدیدهشده فقط بتواند بکاپ اضافه کند، هرگز شل باز نکند.
- 3
کلید را بسازید و جای دیگری نگهش دارید
یک عبارت عبور طولانی و تصادفی، که جایی ثبت شده که ازدسترفتن سرور را دوام میآورد. مخزن را initialize کنید، بعد ثابت کنید که میتوانید محتوایش را از یک ماشین سوم، فقط با همان چیزی که یادداشت کردهاید، فهرست کنید. اگر نمیتوانید، پیش از نوشتن حتی یک بکاپ، این را درست کنید.
- 4
اول از پایگاهدادهها دامپ بگیرید
یک اسکریپت کوتاه که دامپهای سازگار را در یک دایرکتوری آمادهسازی مینویسد و اگر هرکدام شکست بخورد با کد غیرصفر خارج میشود — پیش از بکاپ فایلها اجرا شود، نه همزمان با آن. اجرایی که بعد از یک دامپ ناموفق همچنان ادامه میدهد، دقیقاً همان چیزی است که آدمها را به 30 روز فایل خالی (صفر بایت) میرساند.
- 5
از مسیرهایی که اهمیت دارند بکاپ بگیرید
ابزار را به فهرست include اشاره دهید، excludeها را اعمال کنید، و از سلامت اولین اجرا مطمئن شوید. اگر یک مخزن تازه از یک سرور 40 GB به 300 MB برسد، چیزی دارد بیسروصدا نادیده گرفته میشود؛ اگر به 38 GB برسد، excludeهای شما کار نمیکنند.
- 6
زمانبندیاش کنید و شکست را پرسروصدا کنید
یک تایمر systemd با تأخیر تصادفی، یا cron اگر عادتتان همان است. بعد کاری کنید که اجرا گزارش بدهد: با موفقیت، یک سیگنال زندهبودن (heartbeat) به یک مانیتور بفرستد، و وقتی این heartbeat دیگر نرسد هشدار بدهد. شکست بیصدا، حالت عادی شکستخوردن بکاپهاست، چون وقتی متوقف میشوند هیچچیز قابلمشاهدهای خراب نمیشود — تا وقتی که همهچیز خراب شود.
- 7
نگهداری را تنظیم کنید و واقعاً هرس کنید
ساعتی برای یک روز، روزانه برای دو هفته، هفتگی برای چند ماه، ماهانه برای یک سال. بعد هرس را اجرا کنید و مطمئن شوید مخزن دیگر بزرگتر نمیشود. نگهداریای که پیکربندی شده اما هرگز اجرا نشده، مقصد را پر میکند و بکاپها را هم با خودش پایین میکشد.
- 8
همین امروز چیزی را بازیابی کنید
نه یک اجرای آزمایشی — یک فایل واقعی، به یک دایرکتوری موقت، که باز و بررسی شود. بعد یک تاریخ برای کل ماشین در تقویم بگذارید. اولین بازیابی کامل همیشه چیزی را رو میکند: یک مسیر گمشده، یک مجوز، یک گواهی، یک کاربر پایگاهداده که فقط روی دستگاه قدیمی وجود داشته.
اگر بکاپ را از سرور به بیرون هل بدهید (push)، یعنی پذیرفتهاید که هرکسی با دسترسی root روی آن میتواند هر کپی را نابود کند. آن را برعکس اجرا کنید — میزبان بکاپ وصل میشود، میکشد (pull) و قطع میشود — و یک سرور بهخطرافتاده اصلاً نمیتواند به مخزن برسد، چون هیچ اعتبارنامهای برایش ندارد. راهاندازی pull کار بیشتری دارد، و بزرگترین بهبودی است که بیشتر چیدمانها میتوانند داشته باشند.
نگهداری، و چرا طولانیتر از آنچه بهنظر میرسد ارزانتر است
نگهداری معمولاً بر اساس هرچه در دیسک جا شود تنظیم میشود، و بعد فراموش میشود. اما ارزش یک فکر آگاهانه را دارد، چون تعیین میکند کدام اشتباهها قابلجبراناند. یک بازهٔ هفتروزه، فایلی را که سهشنبه حذف شده میگیرد. اما خرابیای را که شش هفته پیش شروع شده و وقتی یک گزارش غلط از آب درآمده رو شده، یا نفوذگری را که یک ماه بیسروصدا روی دستگاه نشسته بوده پیش از دستبهکار شدن، نمیگیرد.
حذف دادههای تکراری این را بسیار ارزانتر از آنچه جدول نشان میدهد میکند: دومین اجرا روی سروری که بیشترش تغییر نکرده، فقط همان چیزی را ذخیره میکند که تغییر کرده، پس یک سال از نقاط بازیابی ماهانه روی یک دستگاه 40 GB معمولاً چند گیگابایت هزینه دارد، نه نیمترابایت. سیاست را بر اساس چیزی که باید از آن بازیابی کنید تنظیم کنید، بعد صورتحساب را چک کنید. معمولاً میبینید که از پس نسخهٔ سخاوتمندانهتر هم برمیآیید.
تغییرناپذیری: بخشی که جلوی باجافزار را میگیرد
همهٔ آنچه در بالا آمد فرض میکند حریف، آنتروپی است. اگر حریف فردی با دسترسی root باشد، یک کار بکاپگیری معمولی، خودش یک دفترچهٔ راهنماست — اعتبارنامهها روی همان دستگاهاند، مقصد در کانفیگ است، و مخزن پیش از شروع رمزنگاری پاک میشود. چهار سازوکار این زنجیره را میشکند، و هرکدام از آنها بهتنهایی نتیجه را عوض میکند.
- مخزنهای فقطالحاقی. حالت فقطالحاقی سمت سرور Borg، یا سرور REST در restic در حالت فقطالحاقی، دادههای تازه را میپذیرند و حذف را رد میکنند. سرور میتواند بنویسد؛ فقط شما، از جای دیگری، میتوانید هرس کنید.
- بکاپگیری بر پایهٔ pull. میزبان بکاپ اتصال را آغاز میکند و تنها اعتبارنامهها را در اختیار دارد. سرور پروداکشن نه کلیدی دارد، نه آدرس مقصدی، و نه هیچ مسیری بهسمت مخزن.
- Object lock. فضای ذخیرهسازی سازگار با S3 با یک دورهٔ نگهداری اجراشده در سطح bucket، جایی که حذف را خود لایهٔ ذخیرهسازی رد میکند، فارغ از اینکه اعتبارنامهها در غیر اینصورت چه اجازهای میدادند.
- اعتبارنامهٔ جدا برای هر میزبان. یک ماشین بهخطرافتاده نباید تاریخچهٔ همهٔ ماشینهای دیگر را هم فاش کند. کلیدهای جدا، مسیرهای جدا، محدودیتهای جدا.
- یک کپی که واقعاً آفلاین است. دیسکی که از برق کشیده شده، در برابر هر حملهٔ از راه دوری که تا به حال نوشته شده مصون است. دمده، اما شکستناخورده.
تمرین بازیابی
یک بازیابی یک روال است، و روالی که هیچکس اجرایش نکرده، تخیلی بیش نیست. این را همین حالا یکبار و بعد هر شش ماه یکبار اجرا کنید، و هرچه یاد میگیرید را بنویسید — این یادداشتها در نهایت بهاندازهٔ خود داده ارزش پیدا میکنند.
- 1
یک اینستنس خالی مستقر کنید
همان نسخهٔ سیستمعامل، هیچچیز دیگری نصب نشده. یک VPS کوتاهعمر کافی است، و کل این تمرین هزینهاش از یک وعده ناهار هم کمتر است.
- 2
فقط با چیزی که یادداشت کردهاید بازیابی کنید
آدرس مخزن، عبارت عبور، دستورها. اگر به چیزی نیاز داشتید که فقط روی همان سروری وجود دارد که وانمود میکنید مرده، همین الان ایراد کار را پیدا کردهاید — در روزی که پیدا کردنش هیچ هزینهای ندارد.
- 3
پیش از اپلیکیشن، داده را برگردانید
دامپ پایگاهداده را لود کنید، فایلها را جایی که باید باشند بگذارید، بعد ownership و modeها را درست کنید. ownership معمولاً همان غافلگیری همیشگی است: شناسههای عددی کاربر از دستگاه قدیمی بهندرت با دستگاه جدید جور درمیآیند.
- 4
سرویس را استارت کنید و واقعاً استفادهاش کنید
نه یک دستور status — لاگین کنید، یک صفحه بارگذاری کنید، یک کوئری اجرا کنید، یک پیام بفرستید. سرویسی که استارت میشود با سرویسی که کار میکند یکی نیست.
- 5
زمانش را بگیرید، و عدد را بنویسید
کل این کار چقدر طول کشید؟ این همان زمان واقعی بازیابی شماست، و تقریباً همیشه چند برابر تخمین است. یادداشتها را کنار عبارت عبور نگه دارید و هر وقت استک تغییر کرد، هر دو را بهروزرسانی کنید.
هزینهاش چقدر است، صادقانه
بکاپ ارزانترین بیمهٔ زیرساخت است، و بهطور معمول بهخاطر قیمت نادیده گرفته میشود. چند عدد عینی برای یک سرور کوچک، با این فرض که داده همانطور که دادههای معمولی فشرده و بدون تکرار میشوند، فشرده و بدون تکرار شود.
هرکدام از اینها را با هزینهٔ همان قطعیای مقایسه کنید که جلویش را میگیرند. نکتهٔ اصلی همین نامبردن عدد است — استدلال علیه بکاپ، وقتی پول روی کاغذ نوشته شود، دیگر واقعاً دربارهٔ پول نیست.
جایگاه میزبان در این میان
یک برنامهٔ بکاپ، دقیقاً همان دو وابستگی سروری را دارد که دارد از آن محافظت میکند: جایی مستقل برای گذاشتن کپی، و راهی برای پرداخت هزینهاش که سابقهٔ تازهای از هویت شما نسازد. هر دوی اینها اینجا از مبدأ هم بیشتر اهمیت دارند، چون بکاپ یک کپی کامل از هرچیزی است که مبدأ داشت از آن محافظت میکرد.
هر پلن /vps و /storage در اینجا از یک موجودی رمزارزی پیشپرداختشده و بدون KYC مستقر میشود، در 15 منطقهای که در /locations فهرست شدهاند — پس کپی دوم میتواند زیر حوزهٔ قضایی متفاوتی از کپی اول بنشیند، بدون هیچ بررسی هویت دومی در هیچجای این زنجیره. اسنپشات آنی روی هر اینستنس برای همان بازگشت پنجثانیهای گنجانده شده، پهنایباند نامحدود یعنی نه اولین آپلود و نه بازیابی اورژانسی، هیچکدام یک رویداد اندازهگیریشده نیستند، و /storage دیسک محافظتشده با RAID در مقیاس ترابایت را از $8.99/mo اضافه میکند، بدون بازرسی محتوا. /pay-with ارزهای پذیرفتهشده را پوشش میدهد، /offshore-hosting مشخص میکند حوزهٔ قضایی واقعاً چه چیزی را تغییر میدهد، و /guides مقالههای همراه دربارهٔ رمزنگاری دیسک و دربارهٔ اینکه یک میزبان دربارهٔ یک ماشین چه چیزی را میتواند و نمیتواند ببیند را دارد.
چکلیست
- پیش از انتخاب یک ابزار، خرابیای را که در برابرش دفاع میکنید نام ببرید.
- با اسنپشاتها مثل یک دکمهٔ بازگشت رفتار کنید، هرگز مثل خود بکاپ.
- از داده و کانفیگ بکاپ بگیرید؛ سیستمعامل را از یک اسکریپت بازسازی کنید.
- از هر پایگاهداده با دستور صادرات سازگار خودش دامپ بگیرید، و از آن دامپ بکاپ بگیرید.
- پیش از آنکه چیزی از دستگاه خارج شود، در سمت کلاینت رمزنگاری کنید.
- عبارت عبور مخزن را جایی نگه دارید که ازدسترفتن سرور را دوام بیاورد.
- دستکم یک کپی را زیر یک ارائهدهنده، منطقه و مسیر پرداخت متفاوت بگذارید.
- یک کپی را فقطالحاقی، بر پایهٔ pull یا آفلاین کنید تا یک root بهخطرافتاده نتواند پاکش کند.
- دربارهٔ نبود یک اجرای موفق هشدار بدهید — شکستها بیصدا هستند، و همان سکوت، علامت است.
- همین امروز یک فایل را بازیابی کنید و سالی دوبار کل ماشین را. زمانش را بگیرید و بنویسیدش.
آیا اسنپشاتهای ارائهدهنده بهتنهایی کافیاند؟
نه، و این رایجترین شکاف در چیدمانهایی است که در باقی موارد محتاطاند. یک اسنپشات روی همان پلتفرمی زندگی میکند که ولومی که کپی میکند رویش است، پس یک خرابی سطح پلتفرم، یک تعلیق حساب یا یک وقفهٔ صورتحساب را دوام نمیآورد — دقیقاً سه سناریویی که بیشترین نیاز را به آن دارید. معمولاً تاریخچهٔ کوتاهی هم نگه میدارد، پس فایلی را که ماه پیش حذف شده یا خرابیای را که شش هفته پیش شروع شده بازیابی نمیکند. اسنپشاتها بهعنوان یک بازگشت پنجثانیهای پیش از یک تغییر پرریسک عالیاند: نگهشان دارید، روزانه استفادهشان کنید، و یک بکاپ واقعی را جای دیگری نگه دارید.
restic یا Borg — کدام را استفاده کنم؟
اگر مقصد object storage یا یک حساب SSH ساده است، restic، چون در سمت دیگر به هیچچیز نصبشدهای نیاز ندارد و بهطور native با S3 صحبت میکند. اگر مقصد یک ماشین لینوکسی است که خودتان کنترلش میکنید و حالت سرور فقطالحاقی و فشردهسازی کمی فشردهترش را میخواهید، Borg. هر دو دادههای تکراری را حذف میکنند، هر دو در سمت کلاینت رمزنگاری و احرازهویت میکنند، هر دو بالغ و بهطور گسترده در حال استفادهاند، و هرکدام انتخابی قابلدفاع است. پاسخ اشتباه این است که یک ماه را صرف مقایسهشان کنید درحالیکه سرور اصلاً هیچ بکاپی ندارد — همین امروز بعدازظهر یکی را انتخاب کنید و اگر روزی واقعاً اهمیت داشت، بعداً نظرتان را عوض کنید.
هر چند وقت یکبار باید از یک VPS بکاپ بگیرم؟
فاصلهٔ زمانی، بهسادگی همان بیشترین کاری است که حاضرید دوباره انجام دهید. برای یک سایت استاتیک، هفتگی صادقانه است. برای هرچیزی که کاربرها در آن مینویسند، شبانه کف است و ساعتی هم وقتی حذف دادههای تکراری کارش را میکند ارزان است — دومین اجرای روز معمولاً فقط چند مگابایت ذخیره میکند. ارزش دادهٔ یک روز را در برابر هزینهٔ ذخیرهکردن 24 نقطهٔ بازیابی بهجای یکی بسنجید، و معمولاً پاسخ روشن است.
باید از کل دیسک بکاپ بگیرم یا فقط از دادههای خودم؟
تقریباً در همهٔ موارد، از داده و کانفیگ. یک ایمیج کامل دیسک، ماشین را دقیقاً همانطور که بوده بازمیگرداند، از جمله همان نفوذی که دارید از آن بازیابی میشوید و همان وضعیت پکیجهایی که دیگر نمیفهمیدشان، و هم ساختنش و هم بازیابیاش کندتر است. یک بکاپ سطح فایل از /etc، دادههای اپلیکیشنتان و دامپهای پایگاهدادهتان، در کنار اسکریپتی که سیستمعامل را بازمیسازد، سریعتر و تمیزتر بازیابی میشود. دیسک را وقتی ایمیج بگیرید که به حفظ فارنزیک بیتبهبیت نیاز دارید، یا وقتی ماشین یک جعبهٔ سیاه است که یک نفر دیگر ساخته.
ارائهدهندهام میگوید دیسکها رمزنگاریشدهاند — یعنی بکاپ من هم رمزنگاریشده؟
نه به هیچ معنایی که به کارتان بیاید. رمزنگاری سمت ارائهدهنده در برابر بیرونبردن یک درایو از یک رک محافظت میکند؛ کلید دست ارائهدهنده است، پس داده هم برای ارائهدهنده و هم برای هرکسی که بتواند ارائهدهنده را مجبور کند، قابلخواندن باقی میماند. رمزنگاری سمت کلاینت — restic، Borg، لایهٔ crypt در rclone، یا یک آرشیو رمزنگاریشده — یعنی چیزی که به مقصد میرسد، بدون عبارت عبوری که هرگز از دستگاه شما خارج نشده، بیمعناست. برای یک استک حساس به حریم خصوصی، این تفاوت کل نکته است، چون بکاپ یک کپی کامل از هرچیزی است که سرور داشت از آن محافظت میکرد.
چطور جلوی باجافزار را بگیرم که بکاپهایم را هم رمزنگاری نکند؟
فرض کنید هرچیزی که سرور به آن دسترسی دارد، مهاجمی با دسترسی root هم میتواند نابودش کند — اعتبارنامهها، مقصد و زمانبندی، همه روی همان دستگاه نشستهاند. این دسترسی را به یکی از این سه راه بشکنید: یک مخزن فقطالحاقی که نوشتن را میپذیرد اما حذف را رد میکند، یک مدل pull که در آن میزبان بکاپ بهسمت داخل وصل میشود و سرور اصلاً هیچ اعتبارنامهای ندارد، یا object storage با قفلی که خود لایهٔ ذخیرهسازی اجرایش میکند. بعد یک نگهداری طولانی هم اضافه کنید، تا یک نفوذ آهسته و بیسروصدا پیش از آنکه کسی متوجه شود از بازه بیرون نیفتد، و یک کپی را هم آفلاین نگه دارید، جایی که هیچ حملهٔ از راه دوری نتواند به آن برسد.
