نحوه بک‌آپ گرفتن از دیتابیس اپلیکیشن (و بازیابی واقعی آن)

برای بک‌آپ گرفتن از دیتابیس اپلیکیشن، آن را طبق برنامه‌ای مشخص به یک فایل خروجی بگیرید (برای Postgres، ابزار استاندارد pg_dump است)، کپی‌ها را جایی جدا از خود دیتابیس نگه دارید و به‌طور منظم یکی از آن‌ها را در یک دیتابیس خالی بازیابی کنید تا ثابت شود کار می‌کند. پیش از هر تغییر پرریسک یک بک‌آپ اضافه بگیرید. بک‌آپ کدتان، چه مخزن GitHub باشد چه خروجی پروژه، داده‌های شما را شامل نمی‌شود.

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

بک‌آپ باید چه چیزهایی را پوشش دهد

یک اپلیکیشن فقط دیتابیسش نیست. بدانید هر بخش با کدام بک‌آپ محافظت می‌شود.

داده بخشی است که نمی‌توانید دوباره بسازید. کد را می‌توان بازنویسی کرد و تنظیمات را دوباره وارد کرد؛ سفارش‌های مشتریانتان را نمی‌توان.

مرحله ۱: تعیین کنید چقدر می‌توانید از دست بدهید

دو سؤال برنامه‌ی بک‌آپ شما را تعیین می‌کند:

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

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

مرحله ۲: ببینید میزبانتان از قبل چه کاری انجام می‌دهد

بسیاری از ارائه‌دهندگان دیتابیس مدیریت‌شده بک‌آپ خودکار می‌گیرند. این موارد را بررسی کنید:

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

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

مرحله ۳: با pg_dump خروجی بگیرید

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

یک دستور معمولی، با استفاده از رشته‌ی اتصالی که اپلیکیشنتان از قبل در یک متغیر محیطی دارد:

pg_dump "$DATABASE_URL" --format=custom --no-owner --file=backup-2026-09-29.dump

کار گزینه‌ها:

• --format=custom یک فایل فشرده می‌نویسد که pg_restore می‌تواند آن را بخواند و به شما اجازه می‌دهد بعداً فقط یک جدول را بازیابی کنید. اگر فایل .sql خوانا می‌خواهید، از --format=plain استفاده کنید.
• --no-owner دستورهای مالکیت را حذف می‌کند، که بازیابی در یک دیتابیس دیگر را ساده‌تر می‌کند.
• تاریخ در نام فایل باعث می‌شود بک‌آپ‌ها از هم جدا بمانند.

نسخه‌ی pg_dump باید برابر یا جدیدتر از نسخه‌ی Postgres دیتابیس شما باشد. یک pg_dump قدیمی‌تر ممکن است اجرا نشود.

اگر با هوش مصنوعی می‌سازید و نمی‌خواهید به خط فرمان دست بزنید، می‌توانید بپرسید:

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

مرحله ۴: خودکارش کنید

بک‌آپ دستی را آدم فراموش می‌کند. آن را با هر چیزی که تنظیماتتان پشتیبانی می‌کند خودکار کنید:

• بک‌آپ زمان‌بندی‌شده‌ی ارائه‌دهنده‌ی دیتابیس، در صورتی که ارائه می‌دهد.
• یک کار زمان‌بندی‌شده روی یک سرور یا سرویس CI که pg_dump را اجرا کند و فایل را به ذخیره‌سازی آپلود کند.
• یک سرویس بک‌آپ میزبانی‌شده که به دیتابیس شما وصل می‌شود.

هر کدام را انتخاب کردید، مطمئن شوید که وقتی بک‌آپ شکست می‌خورد به شما خبر می‌دهد. یک کار بک‌آپ که سه ماه بی‌صدا شکست خورده باشد، داستان کلاسیک وحشت است.

مرحله ۵: کپی‌ها را جای دیگری نگه دارید

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

• دیتابیس زنده
• بک‌آپ‌های خودکار خود ارائه‌دهنده
• خروجی‌های خودتان در ذخیره‌سازی جدا، مثل یک bucket ذخیره‌سازی شیءمحور در حسابی متفاوت

همچنین:

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

مرحله ۶: بازیابی را آزمایش کنید

یک بک‌آپ فقط به اندازه‌ی آخرین بازیابی موفقش ارزش دارد. دست‌کم هر چند ماه یک‌بار، و پس از هر تغییر در فرایند بک‌آپ:

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

pg_restore --no-owner --dbname="$TEST_DATABASE_URL" backup-2026-09-29.dump

برای فایل .sql ساده، به جای آن از psql "$TEST_DATABASE_URL" -f backup.sql استفاده کنید.

۳. بررسی کنید که همه‌ی جدول‌ها وجود دارند، تعداد ردیف‌ها را با دیتابیس زنده مقایسه کنید و چند رکورد اخیر را نگاه کنید. ۴. اگر می‌توانید، یک نسخه از اپلیکیشن را به آن وصل کنید و وارد شوید. ۵. مدت زمان بازیابی را یادداشت کنید. این زمان واقعی بازیابی شماست.

مرحله ۷: پیش از تغییرات پرریسک بک‌آپ بگیرید

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

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

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

اشتباهات رایج

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

بک‌آپ و Mythex

پروژه‌های Mythex می‌توانند یک دیتابیس Postgres اختصاصی داشته باشند و جزئیات اتصال آن به فضای کار و اپلیکیشن منتشرشده تزریق می‌شود. مستندات Mythex قابلیت بک‌آپ یا بازیابی دیتابیس را توصیف نمی‌کند، پس خودتان برنامه بریزید: از عامل بخواهید خروجی بگیرد، آن را دانلود کنید و جای امنی نگه دارید، به‌ویژه پیش از تغییرات بزرگ. خروجی پروژه (Pro) شامل کد شماست که اسرار و node_modules از آن حذف شده‌اند؛ شامل ردیف‌های دیتابیس نیست. برای جزئیات بیشتر به Database و Data ownership در مستندات مراجعه کنید. برای اطلاعات بیشتر درباره‌ی خود دیتابیس، Postgres چیست را بخوانید.

چک‌لیست بک‌آپ

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

پرسش‌ها