پشتیبان‌گیری از داده‌ها: راه درست

داده‌ها روی سخت‌افزار ذخیره می‌شوند و سخت‌افزار خراب می‌شود. فرقی نمی‌کند که یک رایانه‌ی شخصی کوچک باشد یا یک سرور گران‌قیمت در یک مرکز داده‌ی قدرتمند. هارد دیسک باشد یا SSD یا فلش. این یک واقعیت است: سخت‌افزار خراب می‌شود!

از تابستان ۱۳۹۴ که توسعه‌ی Quera را شروع کردیم، پشتیبان‌گیری از داده‌ها برایمان یک دغدغه‌ی جدی بود. داده‌های مربوط به توسعه‌دهندگان، دانشگاه‌ها، مدارس و شرکت‌ها که برای ما و کاربران ارزش زیادی دارند و باید به خوبی از آن‌ها محافظت شود. به همین دلیل از همان اوایل از داده‌ها پشتیبان گرفتیم و تا به امروز سعی کرده‌ایم استراتژی پشتیبان‌گیری خود را بهبود دهیم.

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

یادم می‌آید روزی را که یکی از دوستان هارد دیسک سرور اصلی استارتاپشان را در دست داشت و به دنبال راهی برای بازگرداندن داده‌های آن بود. آن هارد دیسک دچار مشکل سخت‌افزاری شده بود و آخرین نسخه‌ی پشتیبان که از داده‌ها داشتند مربوط به چند ماه پیش بود... مدل کسب‌وکارشان طوری بود که حجم اعظم داده‌ها مجدداً قابل تولید بود و داده‌هایی که به ازای هر کاربر ذخیره می‌شد، چندان حیاتی نبود (گرچه مهم بود). به همین دلیل خوشبختانه توانستند هزینه‌ی این حادثه را تحمل کنند و کارشان را ادامه دهند.

اما اگر چنین اتفاقی برای Quera بیفتد، فاجعه‌ای برای ما خواهد بود. اطلاعاتی از دست می‌رود که با زحمت هزاران نفر و صرف صدها هزار ساعت وقت به دست آمده (اطلاعات کلاس‌های درسی، تمرین‌های کلاسی و پاسخ‌های دانشجویان، هزاران سؤال برنامه‌نویسی و Test Case های آن‌ها، کدهای کاربران، اطلاعات شرکت‌ها و ...).

استراتژی پشتیبان‌گیری

پشتیبان‌گیری از داده برای هر کسب و کاری از مهم‌ترین ضروریات است. هر شرکت نیاز جدی به طراحی و مستندسازی یک استراتژی دقیق و مؤثر برای پشتیبان‌گیری از داده‌ها و بازیابی نسخه‌های پشتیبان دارد. پشتیبان‌گیری اگر به درستی انجام نشود، ممکن است خودش باعث خسارت شود!

فرض کنید در روز حادثه به سراغ داده‌های پشتیبان می‌روید و متوجه می‌شوید که ۳ ماه پیش دیسک سرور پشتیبان پر شده... یا این که متوجه می‌شوید داده‌های پشتیبان به قدری به‌روز هستند که داده‌های حذف‌شده از سرور اصلی، طی عملیات همگام‌سازی (Sync) از سرور پشتیبان نیز حذف شده‌اند! یا ممکن است حادثه‌ای رخ ندهد اما به دلیل تنظیمات ضعیف، سرور پشتیبان هک شود و داده‌ها لو برود.

در این پست قصد ندارم همه‌ی استانداردهای لازم برای یک استراتژی مناسب را شرح دهم، زیرا مطلب بسیار مفصلی خواهد شد؛ به علاوه، من یک متخصص تمام‌عیار در این زمینه نیستم. تنها سعی می‌کنم بخشی از تجربیاتی که در این زمینه داشته‌ام را بیان کنم.

روی بازیابی داده‌های حذف‌شده از دیسک حساب نکنید

احتمالاً پیش آمده که فایلی را اشتباهاً حذف کرده‌اید و با استفاده از نرم‌افزارهای بازیابی، آن را بازگردانده‌اید. اما وقتی صحبت از داده‌های یک سرور می‌شود، این روش بازیابی جواب نمی‌دهد، زیرا نیاز به بازگرداندن دقیق محتوا و نام هزاران فایل دارید. هیچ راه دررویی نیست! شما به داده‌ی پشتیبان نیاز دارید.

از همه‌ی داده‌های حیاتی پشتیبان بگیرید

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

مطمئن شوید که پشتیبان‌ها به سادگی قابل بازیابی هستند

تصور کنید همین حالا حادثه‌ای برای سرور شما پیش بیاید و دیسک آن به کلی از بین برود. از خود بپرسید در چنین شرایطی چطور می‌توانید همه‌چیز را درست کنید؟ آیا کار سخت یا غیرممکنی خواهد بود؟ در این صورت باید استراتژی پشتیبان‌گیری خود را بازبینی کنید و مشکلاتش را برطرف کنید.

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

در ۲ ژوئن ۲۰۱۶، سیستم پُلیگان وب‌سایت کدفرسز علیرغم پشتیبان‌گیری، داده‌های ۳ هفته‌ی خود را به خاطر یک نقص فنی از دست داد و نتوانست آن‌ها را بازیابی کند. توصیه می‌کنم داستانش را بخوانید.

از داده‌ها در چند جا پشتیبان بگیرید

داشتن تنها یک نسخه‌ی پشتیبان ریسک بالایی دارد. به ویژه اگر نسخه‌ی پشتیبان از لحاظ فیزیکی به داده‌های اصلی نزدیک باشد. فرض کنید مرکز داده دچار آتش‌سوزی یا حادثه‌ی دیگری شود. ممکن است داده‌های اصلی و نسخه‌ی پشتیبانی که در همان مرکز داده است با هم از بین بروند. باید چند نسخه از داده‌ها را در چند نقطه‌ی فیزیکی مختلف نگهداری کنید.

پشتیبان‌گیری را به طور منظم و مداوم انجام دهید

پشتیبان‌گیری از داده‌ها را به صورت خودکار و منظم تنظیم کنید. برای هر بخش از داده‌ها بر اساس نرخ تغییرات آن و میزان حیاتی بودن آن تصمیم بگیرید که بازه‌ی زمانی برای پشتیبان‌گیری چقدر باشد. در لینوکس می‌توانید از Cron Job برای زمان‌بندی و خودکار کردن پشتیبان‌گیری استفاده کنید.

پایش مداوم فرایند پشتیبان‌گیری

خیلی خیلی مهم است که همواره از اجرای صحیح مراحل پشتیبان‌گیری مطمئن باشید. به طور مستمر پشتیبان‌ها را بررسی کنید تا در صورت بروز خطا به سرعت متوجه شوید. توصیه اکید می‌کنم که از سیستم‌های monitoring استفاده کنید و طوری تنظیم کنید که به محض بروز خطا شما را به طور خودکار مطلع کند. حواستان به فضای خالی و ظرفیت سرورها و دیسک‌های پشتیبان نیز باشد!

پشتیبان‌ها را به صورت رمزنگاری‌شده ذخیره کنید

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

پشتیبان‌گیری در Quera

داده‌های حیاتی ما که از آن‌ها به طور منظم پشتیبان می‌گیریم در ۳ گروه زیر هستند:

• پایگاه داده‌ی PostgreSQL
• فایل‌ها، عمدتاً فایل‌های آپلودی کاربران
• لاگ‌های مهم

نحوه‌ی پشتیبان‌گیری ما از این داده‌ها به صورت اجمالی در ادامه می‌آید.

لایه‌ی اول: پشتیبان‌گیری محلی از پایگاه داده

با توجه به اهمیت پایگاه داده، به پشتیبان‌گیری از آن توجه ویژه‌ای کرده‌ایم. برای خودکار شدن فرایند و رسیدن به اهدافی که برایمان مهم بود، ابزار بسیار ساده‌ای به نام pgbackup توسعه دادیم که پشتیبان‌گیری از پایگاه داده را به صورت محلی (Local) و به دو روش Dump و PITR برایمان ساده‌تر می‌کند. این ابزار را در جایی منتشر نکرده‌ایم. پس اگر پروژه‌ای با همین نام پیدا کردید متعلق به ما نیست :)

در روش اول یک بار در هر شبانه‌روز یک Dump از کل پایگاه داده گرفته و ذخیره می‌کنیم. نقش اصلی pgbackup در این مرحله، چرخش یا Rotation است، و نسخه‌های قدیمی را به نحوی حذف می‌کند که فایل‌های مربوط به ۷ روز اخیر به صورت روزانه، ۵ هفته‌ی اخیر به صورت هفتگی و ۱۲ ماه اخیر به صورت ماهانه باقی بمانند.

گرفتن روزانه‌ی پشتیبان خوب است ولی در صورت بروز حادثه، در حالت میانگین اطلاعات ۱۲ ساعت از دست خواهد رفت. برای جلوگیری از این مشکل، از امکان PITR یا Point In Time Recovery پایگاه داده PostgreSQL استفاده می‌کنیم. این روش به صورت Incremental عمل می‌کند. به این صورت که ابتدا یک نسخه‌ی مبنا از پایگاه داده را ذخیره می‌کند و در طول زمان تک‌تک تغییرات پایگاه داده نسبت به پایگاه داده‌ی مبنا را در فایل‌هایی به نام WAL Archive ذخیره می‌کند. بنابراین شما یک پشتیبان پیوسته از پایگاه داده دارید و می‌توانید پایگاه داده را به هر لحظه‌ای از زمان که بخواهید برگردانید. مثلاً در صورتی که در ساعت ۱۲:۳۰ اطلاعات پایگاه داده حذف شود، کل پایگاه داده‌ی ساعت ۱۲:۲۹:۵۹ را دارید. بنابراین هیچ چیزی از دست نمی‌رود! زیبا نیست؟ :)

این روش جادویی یک بار ما را نجات داده است. اشتباهاً کدی بر روی سرور اجرا شد که باعث حذف بخش کوچکی از پایگاه داده شد. به سرعت سایت را در حالت نگهداری قرار دادیم تا تغییر جدیدی روی پایگاه داده اتفاق نیفتد. سپس با استفاده از پشتیبان‌های PITR توانستیم پایگاه داده را به یک لحظه قبل از حادثه برگردانیم.

به دلیل بالا بودن حجم WAL Archive ها، با استفاده از pgbackup پایگاه داده‌ی مبنا را هر هفته نوسازی می‌کنیم. البته پایگاه داده‌ی مبنا و WAL Archive های هفته‌ی قبل را نیز نگهداری می‌کنیم. بنابراین برای ۷ تا ۱۴ روز (در حالت میانگین ۱۰ روز) پشتیبان PITR داریم و می‌توانیم پایگاه داده‌ی هر لحظه از ۱۰ روز گذشته را داشته باشیم.

لایه‌ی دوم: پشتیبان‌گیری در خارج از سرور

نوبت به این می‌رسد که از پشتیبان‌های محلی پایگاه داده، فایل‌ها و لاگ‌ها پشتیبان بگیریم. این کار را هر ۴ ساعت بر روی دو سرور در دو مرکز داده‌ی متفاوت انجام می‌دهیم.

برای این که این پشتیبان‌ها به صورت رمزنگاری‌شده ذخیره شوند و کنترل مناسبی روی حذف نسخه‌های قدیمی داشته باشیم و همچنین برای این که حادثه‌ای که برای پُلیگان رخ داد برای ما اتفاق نیفتد، به جای استفاده از روش‌های ساده‌ای مانند rsync یا lsyncd از ابزار فوق‌العاده و متن‌باز Restic برای پشتیبان‌گیری استفاده می‌کنیم. Restic یک ابزار CLI متن‌باز برای پشتیبان‌گیری بهینه و امن است که به زبان Go نوشته شده است. این ابزار می‌تواند داده‌ها را بر روی سرور SFTP (با SSH)، سرور REST، سرویس S3 آمازون، سرویس ابری گوگل و ... ذخیره کند.

برای خودکارسازی فرایندها، یک نقش (Role) با Ansible ایجاد کردیم و این نقش را به دو سرور پشتیبانمان اختصاص دادیم. این نقش کارهای زیر را انجام می‌دهد:

• آماده‌سازی محیط پشتیبان‌گیری (یک بار): تنظیم دسترسی فایل‌ها، نصب Restic، تنظیمات SSH، ایجاد مخازن پشتیبانی، ایجاد Cron Job
• عملیات پشتیبان‌گیری (هر ۴ ساعت): لاگ شروع پشتیبان‌گیری، پشتیبان‌گیری با Restic، لاگ پایان پشتیبان‌گیری
• حذف پشتیبان‌های قدیمی (هر ۲۴ ساعت): عملیات Forget و Prune در Restic

یک مرحله جلوتر!

اگر می‌خواهید استراتژی پشتیبان‌گیری کاملی داشته باشید و از دست نرفتن داده‌ها برایتان بسیار مهم است، به پشتیبان آفلاین نیز نیاز دارید. روی DVD، دیسک خارجی، فلش یا نوار مغناطیسی.

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

در ۲۷ فوریه ۲۰۱۱، تیم پشتیبانی گوگل گزارش‌هایی را از کاربران جیمیل دریافت کرد که پس از ورود به حسابشان، با Inbox خالی مواجه شده بودند و تنظیماتشان به حالت اولیه بازگشته بود. تعدادی از کاربران نیز دریافت خطای ۵۰۰ سرور را گزارش داده بودند. مشخص شد که در نتیجه‌ی یک به‌روزرسانی نرم‌افزاری، دسترسی به اطلاعات ۴۰ هزار کاربر با مشکل رو به رو شده است. گوگل مجبور شد از پشتیبان‌های آفلاینی که روی نوارهای مغناطیسی ذخیره کرده بود برای بازگرداندن اطلاعات استفاده کند. گزارش گوگل از این حادثه را می‌توانید اینجا و اینجا بخوانید.

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

شرکت‌های بزرگ از نوار مغناطیسی به دلیل ظرفیت ذخیره‌سازی بالا و هزینه‌ی پایین برای پشتیبان آفلاین استفاده می‌کنند. اولین نوار مغناطیسی تجاری در سال ۱۹۵۱ بر روی رایانه‌ی یونیواک ۱ استفاده شد. امروز قادریم ده‌ها (و حتی صدها) ترابایت داده را روی تنها یک نوار مغناطیسی ذخیره کنیم.

نظر شما چیست؟ چه نکته‌ی مهمی را جا انداخته‌ام؟ شما هم از تجربیات خود در این زمینه بگویید.