ابر یک تغییر فناوری به چشم اندازهای فناوری اطلاعات و استراتژیهای پشتیبان و پیادهسازی آنها میآورد. تکیه بر قوانین و الگوهای به خوبی تثبیت شده پشتیبان گیری on-prem راحت است اما خطرناک است. این استراتژیهای پشتیبان به این دلیل محبوب شدند که چالشهای حیاتی را در دنیای اولیه به طور موثر حل میکنند. با این حال، هیچ تضمینی وجود ندارد که این راهحلها وقتی بدون تغییر در راهاندازی ابری مستقر شوند، منطقی، مناسب و مقرون به صرفه باشند.
بیایید به دو استراتژی پرمصرف پشتیبان – الگوی پدربزرگ – پدر – پسر و الگوی 3-2-1 – نگاه کنیم و ارتباط آنها را در دنیای ابرهای عمومی بررسی کنیم.
استراتژی پشتیبان گیری 3-2-1
یکی از شناخته شده ترین استراتژی ها در زمینه پشتیبان گیری، الگوی 3-2-1، از سه عنصر تشکیل شده است:
- (حداقل) سه نسخه از داده های خود را نگه دارید.
- پشتیبانگیریها را روی (حداقل) دو نوع رسانه پشتیبان ذخیره کنید.
- (حداقل) یک نسخه را خارج از سایت نگه دارید.
به جای اجرای مجدد این استراتژی در طراحی ابری، معماران باید از خود بپرسند: چرا قوانین الگو در دنیای اولیه حیاتی بودند؟ مهندسان و معماران برای رسیدن به چه چیزی با آنها تلاش کردند؟

شکل 1: مفاهیم پشتیبان گیری قدیمی در مقابل ویژگی های ابر
شکل 1 این جنبه ها را نشان می دهد: ستون سمت چپ شامل قوانین الگو است. ستون وسط نیازها و الزاماتی را که منجر به قوانین الگو می شود برجسته می کند. در نهایت، ستون سمت راست برای عصر ابر مهم است: تغییرات در ابرهای عمومی مانند AWS آمازون، GCP گوگل یا Azure مایکروسافت را برجسته می کند.
برای چندین دهه، ارائه دهندگان خدمات و شرکت ها سرورهای خود را در مراکز داده ساخته شده در مکان هایی با دقت انتخاب شده میزبانی کرده اند. آنها می خواهند خطر خطرات زیست محیطی مانند سیل یا رانش زمین را کاهش دهند. در مقابل، بسیاری از سازمانهای کوچک و متوسط دولتی یا خصوصی و SMEها ممکن است هنوز سرورهای خود را در زیرزمین ساختمان اداری خود قرار دهند.
آتشسوزی، زلزله یا کامیونی که به داخل ساختمان میرود – همه این رویدادها به طور بالقوه کل ساختمان، از جمله اتاق سرور را از بین میبرند. سپس، “یک نسخه پشتیبان خارج از سایت” توصیه شده تنها نجات دهنده می شود. اما چنین پشتیبانگیریهایی در عصر ابر چقدر مرتبط هستند؟
مفهوم “در محل” در مقابل “خارج از محل” در عصر ابر تغییر می کند، اما یک خطر ثابت باقی می ماند: مهم نیست که چقدر مکان را با دقت انتخاب می کنید و چقدر امنیت فیزیکی را جدی می گیرید، یک هواپیما می تواند به ساختمان سقوط کند یا آتش سوزی شود. (و آتش نشانی بعدی) ممکن است مرکز داده را از بین ببرد. داشتن حجم کار تولید خود در یک مرکز داده و حداقل یک نسخه پشتیبان در مرکز دیگر هنوز منطقی است. و ویژگیهایی مانند AWS Cross-Region Replication یا ذخیرهسازی جغرافیایی اضافی در Azure حتی کسبوکارهای کوچک را قادر میسازد تا برای بلایای منطقهای یا سراسری آماده شوند.
نیاز به قانون «دو نوع رسانه پشتیبان» کمتر آشکار است. اما بیایید زمان هایی را به یاد بیاوریم که شرکت ها نسخه های پشتیبان خود را روی نوارها یا دیسک های نوری ذخیره می کردند و ببینیم چه چیزی ممکن است اشتباه باشد. اول، یک مهندس ممکن است تصمیم بگیرد – برای راحتی – همه نسخه های پشتیبان را در یک رسانه نگه دارد. اگر این رسانه نقص داشته باشد یا گم شود، تمام نسخه های پشتیبان از بین می روند. واضح است که یک رسانه بسیار پرخطر است، اما چه خطری در هنگام استفاده از سه نوار وجود دارد که هر کدام برای سال ها یا دهه ها کار می کنند؟
مربوط: گزارش رایگان ما، Zero Trust and the Modern Enterprise را دانلود کنید
برای اهداف توضیحی، احتمال از دست دادن یک نوار پشتیبان در سال را 0.1٪ تعریف می کنیم و فرض می کنیم که سه نسخه پشتیبان داریم. سپس، احتمال از دست دادن هر سه 0.1٪ * 0.1٪ * 0.1٪ = 0.001٪ است. اگر خیلی زیاد است، سه نسخه پشتیبان دیگر اضافه کنید. احتمال از دست دادن هر شش در یک سال 0.000001٪ است. در مقایسه، احتمال برخورد صاعقه یک بار در زندگی شما 0.0065٪ است. با توجه به این احتمالات، آیا برای کاهش ریسک از دست دادن سه یا شش نوار به طور همزمان سرمایه گذاری می کنید؟
این یک سوال ترفندی است زیرا بر اساس یک اشتباه رایج است: فرض اینکه رویدادهایی نامرتبط باشند (متغیرهای وابسته در مقابل مستقل در آمار). اگر یک نوار به دلیل نقص مواد از کار بیفتد، همه نوارهای تولید شده در یک دستگاه در همان کارخانه احتمالاً دارای همان نقص هستند. اگر سه تا را با هم سفارش دهید، احتمالاً همه آنها یک عیب دارند. بنابراین، نیاز به دو نوع رسانه پشتیبان، روشی راحت و آسان برای پیادهسازی در دنیای on-prem برای کاهش خطر فساد همه رسانهها به طور همزمان است. اما این قانون چگونه به پشتیبان گیری ابری کمک می کند؟
پاسخ این است: پیچیده است. توافقنامه سطح سرویس دوام برای ذخیره سازی اشیاء S3 99.999999999٪ در یک سال است. اما، از آنجایی که این یک قرارداد در سطح خدمات (SLA) است، باید به ارائهدهنده خدمات اعتماد کنید و نمیتوانید طراحی و پیادهسازی فناوری را تأیید کنید. اگر ارائه دهندگان ابر SLA را از دست بدهند، ممکن است شرکت شما از کار بیفتد، اما ارائه دهنده ابر نه. ارائهدهنده ابر ممکن است تخفیف کوچکی در قبض ابری شما ارائه دهد، اما اگر دادههایتان از بین بروند، این کار شما را نجات نخواهد داد. نظر شخصی من: قانون “دو رسانه” در فضای ابری تقریبا غیرممکن است، اما اگر بتوانید به SLA ها اعتماد کنید، چندان ضروری نیست.
“3” از “3-2-1” مربوط به نگهداری سه نسخه از داده های شما است. برای مثال، با داشتن دو نسخه پشتیبان از نقاط مختلف زمان. یک نوع پیاده سازی محبوب که بیش از حد این نیاز را برآورده می کند، دومین استراتژی شناخته شده پشتیبان است: الگوی پدربزرگ-پدر-پسر.
درک استراتژی پدربزرگ-پدر-پسر
یک پیاده سازی معمولی از این الگوی پشتیبان گیری داده ها:
- هر هفته یک نسخه پشتیبان تهیه می کند (پدر)
- پشتیبان گیری روزانه را انجام می دهد (پسر)
- و یک نسخه پشتیبان در ماه نگه می دارد (پدربزرگ)

شکل 2: نمونه برنامه ماهانه برای مفهوم پشتیبان گیری پدربزرگ-پدر-پسر
شکل 2 نشان میدهد که چگونه چنین برنامهای با پشتیبانگیری دادههای هفتگی «پدر» و «پدربزرگ» ماهانه در دوشنبه شب، و همچنین پشتیبانگیریهای روزانه «پسر» میتواند به نظر برسد.
استراتژی پشتیبان گیری پدربزرگ-پدر-پسر یک مفهوم پیچیده است که سناریوهای مختلفی را پوشش می دهد که در آن شرکت ها به پشتیبان نیاز دارند. سناریوی اول در مورد اشتباهات عملیاتی است. در تئوری، ادمین ها هرگز پایگاه داده های سازنده را به اشتباه حذف نمی کنند.
به طور مشابه، مهندسان باید قبل از اعمال تغییرات در سیستم های آزمایشی، تغییرات پیکربندی را به دقت آزمایش کنند. اما اگر واقعیت از تئوری پیشی بگیرد، مهندسان باید سرورها و اجزای سازنده را به سرعت به حالت قبل از وقوع آشفتگی برگردانند – و راه حل این است که از یک به روز رسانی اخیر استفاده کنید، مانند یکی از روز قبل. پشتیبان «پسر» این نیاز را برآورده می کند.
هنگامی که باندهای باج افزار یا بازیگران تحت حمایت دولتی به یک چشم انداز فناوری اطلاعات نفوذ می کنند، ممکن است برای روزها یا هفته ها ناشناخته بمانند. بنابراین، پشتیبان گیری دیروز چندان کمکی نمی کند. در عوض، مهندسان باید پیکربندیها و برنامههای کاربردی (نه دادههای تجاری) را به وضعیتی که هفتهها قبل قبل از نفوذ انجام میشود، برگردانند. برای این منظور، پشتیبان گیری “پدربزرگ” ایده آل است.
این دو سناریو نمونه برای دنیای ابر نیز ضروری هستند. چه تغییراتی در ویژگیهای جدید پشتیبانگیری از دادههای موجود در فضای ابری است، مانند نسخهسازی شی یا بازیابی لحظهای.
بازیابی نقطه در زمان (PITR) در حال حاضر برای پایگاه داده های مختلف برای مدتی در دسترس بوده است، اما ابرهای عمومی تطبیق و ادغام با استراتژی های پشتیبان شرکت را تسریع می کنند. PITR یک ابزار سفر در زمان است که به مدیران و مهندسان این امکان را می دهد تا وضعیت پایگاه داده را به هر زمان معینی برگردانند، به عنوان مثال، در هفته یا ماه گذشته (شکل 3، سمت چپ). در صورت موجود و فعال بودن، PITR پشتیبان گیری روزانه و هفتگی را منسوخ می کند. بسته به نیازهای مشخص، ریسک پذیری و ویژگی های یک سرویس ابری خاص، شرکت ها علاوه بر PITR به پشتیبان «پدربزرگ» نیز نیاز دارند.
نسخه بندی شی مفهوم دیگری است که به ویژه برای ذخیره سازی اشیا مفید است. هنگامی که کاربران، اسکریپتها یا برنامهها یک شی را با نسخه جدیدتر جایگزین میکنند، ابر نسخه قدیمی را برای مدت مشخصی نگه میدارد (شکل 3، سمت راست). در طول این دوره، نیازی به پشتیبانگیری اضافی (مثلاً روزانه یا هفتگی) نیست، اگرچه معماران ممکن است مجبور باشند نسخههای پشتیبان طولانیمدت را پیکربندی کنند.

شکل 3: نمونههای ویژگی پشتیبانگیری ابری پیشرفته – Azure Cosmos DB (سمت چپ) و AWS S3 (راست)
قوانین سنتی پشتیبان گیری هنوز هم اعمال می شود
پیکربندی پشتیبانگیری هرگز آسانتر از فضای ابری نبود. با چند کلیک و کارتان تمام شد – و با این حال، صورتحسابهای هنگفت برای مصرف فضای ذخیرهسازی ممکن است مورد کسبوکار شما را خراب کند. برای جلوگیری از افزایش سرسام آور هزینه ها، معماران باید رابطه هزینه و فایده را هنگام تعریف استراتژی پشتیبان گیری ابری در نظر بگیرند. نگه داشتن نسخه پشتیبان ماهانه خود برای یک سال به این معنی است که شما دوازده نسخه دارید. چهار نسخه دیگر برای نگهداری بک آپ های هفتگی به مدت یک ماه وجود دارد. بهعلاوه، اگر پشتیبانگیری کامل روزانه انجام دهید و آنها را برای یک هفته ذخیره کنید، اینها هفت نسخه اضافی هستند. بنابراین، حجم ذخیره سازی پشتیبان 21 برابر بیشتر از حجم ذخیره سازی برای تولید است.
قوانین پشتیبان گیری سنتی ایجاد شده مانند 3-2-1 و پدربزرگ-پدر-پسر هنوز برای معماری های ابری امروزی مرتبط هستند. ارتباط آنها بیشتر از الزامات پشت استراتژی ها ناشی می شود تا قوانین و فناوری های دقیق آنها. با این حال، ابرها همچنین دارای ویژگیهای جدیدی هستند، از جمله ویژگیهای افزونگی و پشتیبانگیری ابری، که اکثر شرکتهای متوسط و کوچک چند سال پیش هرگز تصورش را نمیکردند.
بنابراین، وظیفه مهندسان ابر اجرای الگوها مانند قبل نیست. آنها باید الزامات قدیمی هنوز معتبر را در نظر بگیرند و با ویژگی های ابری امروزی به آنها رسیدگی کنند. بنابراین، بخشهای فناوری اطلاعات میتوانند استراتژیهای پشتیبانگیری ابری مقرونبهصرفه و آیندهنگر را تعریف و اجرا کنند.