کپی‌کردن پوشه یک Docker Volume در حالی که دیتابیس مشغول نوشتن است ممکن است archiveای بسازد که کامل به نظر می‌رسد اما Restore نمی‌شود. روش درست به نوع داده بستگی دارد: فایل upload، دیتابیس، queue و config نقطه consistency یکسانی ندارند. بکاپ زمانی ارزش دارد که مستقل نگهداری شود، خطایش هشدار بدهد و بازیابی آن آزموده شده باشد.
پاسخ سریع: volumeها و ownerشان را inventory کنید، RPO/RTO را تعیین کنید و برای دیتابیس از dump یا روش native سازگار استفاده کنید. برای فایل‌ها، نوشتن را متوقف/فریز یا snapshot هماهنگ بگیرید. خروجی را با metadata نسخه، checksum و رمزگذاری خارج از host نگه دارید؛ سپس در محیط جدا Restore و صحت برنامه را بررسی کنید.
اول بفهمید چه چیزی را بکاپ می‌گیرید
نام volume به‌تنهایی معنای داده را نمی‌گوید. مسیر mount داخل container، سرویس نویسنده، نسخه برنامه، dependencyهای مرتبط و نرخ تغییر را ثبت کنید. cache قابل‌بازسازی شاید backup نخواهد، ولی upload کاربر و کلیدهای لازم برای رمزگشایی حیاتی‌اند. راهنمای Docker Volume تفاوت volume، bind mount و tmpfs را توضیح می‌دهد.
RPO و RTO روش را تعیین می‌کنند
اگر حداکثر یک ساعت داده قابل‌ازدست‌رفتن است، backup روزانه کافی نیست. اگر بازیابی باید در سی دقیقه انجام شود، archive چندصد گیگابایتی روی storage کند مناسب نیست. RPO فاصله قابل‌قبول از آخرین داده و RTO زمان هدف بازیابی است. این دو را با صاحب سرویس توافق کنید، نه فقط با فضای Disk موجود.
بکاپ سطح فایل یا بکاپ Application-aware؟
برای فایل‌های immutable یا uploadهایی که هنگام backup تغییر نمی‌کنند، archive سطح فایل مناسب است. برای PostgreSQL، MySQL و دیتابیس‌های دیگر، ابزار native یا snapshot هماهنگ با دیتابیس لازم است. کپی فایل‌های data directory زنده بدون protocol رسمی ممکن است صفحات و log را در زمان‌های متفاوت بگیرد. «container را pause کردم» نیز تضمین سازگاری چند سرویس یا flush شدن داده نیست.
سه الگوی consistency
- توقف کنترل‌شده: نویسنده را graceful متوقف کنید، فایل‌ها را بگیرید و سرویس را بالا بیاورید؛ ساده اما دارای downtime.
- Dump منطقی: دیتابیس خروجی سازگار می‌دهد؛ Restore و زمان/حجم آن را بسنجید.
- Snapshot هماهنگ: با ابزار storage و quiesce دیتابیس؛ سریع‌تر، اما پیچیده و وابسته به پلتفرم.
برای transactionهای حساس، علاوه بر backup دوره‌ای ممکن است archive log یا replication لازم باشد. replica جای backup مستقل نیست؛ حذف اشتباه یا داده خراب می‌تواند replicate شود.
الگوی Archive برای Volume فایل
Docker Volume را می‌توان به یک container ابزار به‌صورت read-only mount کرد و خروجی archive را در مقصد دیگری نوشت. فرمان دقیق باید نام volume و مسیر مقصد را صریح داشته باشد. قبل از اجرا، نویسنده را متوقف یا consistency را با روش برنامه تضمین کنید. از مثال‌های اینترنتی با متغیر، wildcard یا مسیر مبهم روی production کپی نکنید؛ ابتدا target را با inspect خواندنی تأیید کنید.
docker run --rm --mount source=app_uploads,target=/source,readonly --mount type=bind,source=/srv/backups/app,target=/backup alpine:3.20 tar -C /source -czf /backup/uploads.tar.gz .این نمونه برای volume فایل با نام دقیق app_uploads است، نه data directory دیتابیس زنده. مقصد باید از قبل وجود داشته، فضای کافی و permission مناسب داشته باشد. tag image ابزار را در runbook pin و به‌روز کنید. archive فشرده رمزگذاری‌شده نیست و باید در مرحله بعد محافظت شود.
Dump دیتابیس داخل Container
از ابزار client هم‌نسخه و روش توصیه‌شده دیتابیس استفاده کنید. credential را در command line یا log آشکار نکنید؛ فایل secret یا سازوکار امن pipeline بهتر است. خروجی dump را خارج از همان volume دیتابیس نگه دارید. خط خروج صفر به‌تنهایی کافی نیست: اندازه غیرعادی، log خطا، checksum و Restore واقعی را بررسی کنید.
بکاپ چند Volume مرتبط
فروشگاه ممکن است دیتابیس، upload و object storage داشته باشد. گرفتن هرکدام در زمان متفاوت می‌تواند مرجع فایل و رکورد را ناسازگار کند. maintenance window، snapshot group یا marker تراکنشی متناسب طراحی کنید. config و image digest release را نیز کنار backup ثبت کنید تا بدانید داده با کدام نسخه اجرا می‌شده است. Secret لازم برای decrypt داده را جدا و امن نگه دارید؛ بدون آن Restore بی‌استفاده است.
مقصد مستقل و قاعده چندکپی
بکاپ روی همان host یا همان volume در برابر خرابی Disk و حذف اشتباه مستقل نیست. حداقل یک نسخه خارج از failure domain اصلی و با credential جدا نگه دارید. نسخه immutable یا object lock می‌تواند در برابر حذف و باج‌افزار کمک کند، اما retention و هزینه دارد. راهنمای بکاپ سرور لایه‌های نگهداری و Restore را کامل‌تر بررسی می‌کند.
رمزگذاری و کلید بازیابی
بکاپ معمولاً داده حساس کامل‌تری از production دارد. در انتقال و در مقصد رمزگذاری، کنترل دسترسی و audit لازم است. کلید رمزگذاری را فقط داخل همان backup ذخیره نکنید و recovery آن را برای افراد مجاز مستند کنید. rotation کلید نباید نسخه‌های قدیمی را غیرقابل‌بازیابی کند؛ mapping نسخه به key را امن نگه دارید.
Retention و حذف قابل‌کنترل
نگهداری همه نسخه‌ها دائمی نیست. سیاست روزانه/هفتگی/ماهانه را بر اساس RPO، قانون و هزینه تعیین کنید. حذف باید فقط backupهای تأییدشده و منقضی را هدف بگیرد؛ script با glob یا متغیر خالی خطرناک است. dry-run، allowlist مقصد و گزارش فهرست حذف‌شده داشته باشید. نگهداری طولانی داده شخصی نیز الزام حریم خصوصی ایجاد می‌کند.
Checksum چه چیزی را ثابت می‌کند؟
Checksum نشان می‌دهد فایل بعد از تولید تغییر نکرده یا انتقال خراب نشده؛ ثابت نمی‌کند backup از ابتدا سازگار بوده است. checksum و metadata را همراه archive نگه دارید و در مقصد دوباره بسنجید. برای مجموعه چندفایلی، manifest دقیق با اندازه، زمان و نسخه ابزار مفید است. امضای manifest می‌تواند tampering را بهتر آشکار کند.
نسخه ابزار dump و restore را نیز ثبت کنید. سازگاری نسخه‌ها را طبق مستندات همان دیتابیس بررسی کنید؛ نصب تصادفی «آخرین نسخه» هنگام بحران می‌تواند بازیابی را عقب بیندازد.
Restore Test مرحله‌به‌مرحله
- محیط جدا و بدون اتصال به production آماده کنید.
- نسخه ابزار، image و config ثبت‌شده را بازیابی کنید.
- checksum و قابلیت بازشدن archive را بررسی کنید.
- دیتابیس و فایل‌ها را با ترتیب مستند Restore کنید.
- migration ناخواسته را پیش از تهیه clone کنترل کنید.
- تعداد/نمونه داده، login و جریان حیاتی را آزمون کنید.
- مدت واقعی Restore و گام‌های دستی را ثبت کنید.
محیط Restore نباید ایمیل، پرداخت یا webhook واقعی ارسال کند. credential بیرونی را غیرفعال یا با sandbox جایگزین کنید. پاک‌سازی محیط آزمون نیز باید target دقیق داشته باشد.
بازیابی روی Volume جدید
برای کاهش ریسک، اغلب Volume تازه می‌سازید، داده را Restore می‌کنید و یک stack آزمایشی به آن وصل می‌کنید. پس از صحت‌سنجی، cutover کنترل‌شده انجام می‌شود. overwrite مستقیم volume اصلی راه برگشت را کم می‌کند. اگر مجبور به جایگزینی هستید، backup تازه و snapshot قبل از عملیات بگیرید و زمان freeze نوشتن را مشخص کنید.
مانیتورینگ Job بکاپ
آخرین اجرای موفق، مدت، حجم، checksum، upload مقصد و سن آخرین Restore Test را پایش کنید. «job اجرا شد» با «فایل قابل بازیابی است» فرق دارد. backup بسیار کوچک یا سریع می‌تواند نشانه volume خالی/نام اشتباه باشد. هشدار باید owner و runbook داشته باشد و پیش از عبور از RPO فعال شود.
اشتباه‌های رایج
- tar گرفتن از data directory دیتابیس زنده بدون روش سازگار
- نگهداری تنها نسخه روی همان سرور
- بکاپ از volume اشتباه به‌خاطر prefix پروژه Compose
- ثبت password در فرمان یا log CI
- نبود آزمون Restore و زمان واقعی بازیابی
- رمزگذاری بدون برنامه نگهداری key
- حذف backup با wildcard کنترل‌نشده
چه زمانی مداخله تخصصی لازم است؟
اگر سرویس تراکنشی، چند volume مرتبط یا downtime بسیار محدود دارد، یک archive ساده کافی نیست. پشتیبانی ساعتی DevOps می‌تواند inventory، consistency، بکاپ خارج host و Restore Test را برای همان stack طراحی و اجرا کند.
پرسش‌های متداول
آیا snapshot Volume بکاپ است؟
می‌تواند بخشی از راهکار باشد، اما consistency برنامه، استقلال failure domain، retention و Restore Test همچنان لازم‌اند.
آیا باید container را برای بکاپ خاموش کنیم؟
برای فایل‌های در حال تغییر، توقف کنترل‌شده ساده‌ترین consistency است؛ دیتابیس می‌تواند ابزار native یا snapshot هماهنگ داشته باشد.
چند وقت یک‌بار Restore را تست کنیم؟
بر اساس حساسیت و تغییرات؛ بعد از تغییر عمده schema، storage یا فرایند backup حتماً تکرار شود.
آیا کپی پوشه /var/lib/docker/volumes کافی است؟
نه به‌عنوان روش عمومی؛ به پیاده‌سازی host وابسته است و برای دیتابیس زنده ممکن است ناسازگار باشد.