پرش به محتوای اصلی

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

هکرنیوز۱۴۰۵ شهریور ۲۵, چهارشنبه، ساعت ۲۳:۵۷حدود 9 دقیقه مطالعه

آدرس مقاله: https://filipovski.net/2026/09/16/backups-arent-simple.html آدرس نظرات: https://news.ycombinator.com/item?id=49732513 امتیاز: 259 # نظرات: 156

همچنین ببینید: وبلاگ عالی جان سالواتیر، واقعیت دارای جزئیات شگفت انگیزی است

من یک کامنت را در جایی خواندم که برایم جالب بود، چیزی شبیه به این:

دو نوع آدم وجود دارد: کسانی که از دست دادن فاجعه‌بار داده‌ها را متحمل شده‌اند و آن‌هایی که این کار را خواهند کرد.»

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

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

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

خوشبختانه ما توانستیم عکس‌ها را بازیابی کنیم، و این یک درس ارزان در مدیریت داده‌ها بود. شما هرگز چیزهای مهم را فقط در یک مکان نگه نمی دارید. حدود یک میلیون چیز وجود دارد که ممکن است اشتباه پیش برود. درایو شما ممکن است بمیرد، ممکن است دزدیده شود، بیت‌ها ممکن است در فضای سرد پوسیده شوند (هارد دیسک‌ها دارای ذرات مغناطیسی هستند که می‌توانند به طور غیرقابل توضیحی جابجا شوند، و SSD‌ها از ترانزیستورهای NAND ساخته شده‌اند که برق را نشت می‌کنند و به مرور زمان داده‌های شما را خراب می‌کنند).

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

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

بنابراین نسخه پشتیبان ما نباید آینه ای از درایو اول باشد، زیرا ما همچنین می خواهیم در صورت خرابکاری بتوانیم به گذشته برگردیم. مهمتر از همه، این بدان معناست که انعکاس دیسک شما با چیزی مانند RAID 1 تمام شده است. ما به روش دیگری نیاز داریم که از چیزها عکس برداری کند.

هر چند وقت یکبار می خواهیم عکس فوری بگیریم؟ شاید در مورد عکس‌ها باید هر هفته یک نسخه پشتیبان تهیه می‌کردیم. اگر 6 روز و 23 ساعت داده را از دست بدهیم، خوب است و می توانیم با آن زندگی کنیم. این همان چیزی است که در فناوری اطلاعات، Recovery Point Objective (RPO) نامیده می‌شود، و در موارد واقعی، از کمتر از 30 ثانیه برای مؤسسات مالی حیاتی که واقعا نمی‌توانند داده‌ها را از دست بدهند، تا 24 ساعت یا بیشتر برای برخی از شرکت‌های کوچک (اگر حتی استراتژی بازیابی فاجعه‌ای داشته باشند) متغیر است.

گرفتن عکس فوری به این معنی است که ما بار فزاینده ای بر روی فضای ذخیره سازی خود داریم. با RPO 24 ساعته، در نهایت 7 عکس فوری در هفته خواهید داشت. 30 در ماه 365 در سال، اگر واقعا نروید و عکس‌های فوری خود را هرس نکنید. بنابراین باید نسخه های پشتیبان خود را بچرخانید.

فرض کنید من با رویکرد ساده لوحانه پیش می روم و تصمیم می گیرم که عکس های فوری ۱۴ روزه را نگه دارم. وقتی یک عکس فوری جدید می‌گیرم، قدیمی‌ترین عکس را حذف می‌کنم و جدید را اضافه می‌کنم. خیلی ساده است، اما اکنون من را مجبور می کند که یک چشم مراقب داشته باشم. شاید من داده های زیادی را نگه دارم و نمی توانم حوصله بررسی کنم که آیا چیزی در دو هفته گذشته خراب شده است یا خیر؟ اما باز هم، من نمی توانم فقط یک سال پشتیبان تهیه کنم و آنها به سادگی به من مربوط نیستند. اتفاقی که بین روز 2 و روز 3 سال رخ داد تقریبا وقتی روز 364 است هیچ اهمیتی ندارد. بنابراین جزئیاتی که در آن ما نسخه پشتیبان تهیه می کنیم باید تغییر کند.

هر چه به امروز نزدیک‌تر باشیم، عکس‌های فوری بیشتر می‌شوند. هرچه عقب تر باشید، تعداد عکس های فوری کمتر می شود.

بنابراین شاید ما بک‌آپ‌های روزانه‌مان را هر 14 روز بچرخانیم، اما بک‌آپ‌های هفتگی را که هر 7 هفته یکبار می‌چرخانیم، و پشتیبان‌گیری‌های ماهیانه را هر 12 ماه یکبار می‌گیریم. این باید بسیار کارآمدتر باشد. اما دوباره پیچیدگی ما افزایش می یابد. ما اکنون چیزی به نام پشتیبان گیری مبتنی بر عکس فوری با چرخش GFS داریم. همانطور که در اندکی خواهیم دید، این لیست از صفت ها به رشد خود ادامه خواهد داد.

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

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

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

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

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

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

با انگیزه موفقیت ما در توسعه این راه حل، ما سعی می کنیم از آن برای پشتیبان گیری از homelab با 10 کانتینر Docker آن استفاده کنیم. اما بعدا از لاگ‌های موجود در دستگاه‌های جداگانه متوجه می‌شویم که پشتیبان‌گیری‌ها با شکست مواجه هستند. دلیل آن این است که بسیاری از کانتینرهای Docker دوست دارند فایل های متعلق به ریشه ایجاد کنند و اگر مراقب نباشید می توانید یک cronjob ایجاد کنید که به عنوان کاربر پیش فرض اجرا می شود.

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

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

اینجاست که نسخه پشتیبان 3-2-1 نام خود را می گیرد: 3 نسخه، در 2 نوع رسانه مختلف، با 1 نسخه خارج از سایت.

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

اما سوال این است که چگونه این کار را انجام می دهید؟ آیا همه چیز را در یک تربال غول پیکر می چسبانید؟ بدیهی است که نه، پس بک آپ گیری افزایشی شما با لینک های سخت دیگر معنی ندارد. بهترین کار این است که همه چیز را به تکه های تمیز 50 مگابایتی تقسیم کنید، اما موفق باشید با انجام این کار به روشی که به طور قابل تأیید ایمن باشد!

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

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

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

همچنین مطمئن شوید که در ساعت 2 یا 3 بامداد، نسخه پشتیبان تهیه نکنید، در غیر این صورت ممکن است همه چیز ترسناک شود.

خواندن متن کامل در هکرنیوزبه زبان اصلی، در سایت ناشر باز می‌شود
متن اصلی (انگلیسی)

Backups Aren't Simple

Article URL: https://filipovski.net/2026/09/16/backups-arent-simple.html Comments URL: https://news.ycombinator.com/item?id=49732513 Points: 259 # Comments: 156

همه‌ی اخبار فناوری