استراتژی پشتیبان‌گیری پست‌گرس‌اس‌کیوال: زمان استفاده از pg_dump، پشتیبان فیزیکی و آرشیو WAL چیست؟
تفاوت‌های پشتیبان‌گیری منطقی و فیزیکی، بازگردانی به نقطه زمانی مشخص (PITR)، نسخه‌های دوردست، رمزگذاری و برنامه‌ای کاربردی برای تست بازیابی به همراه دستورات نمونه در پست‌گرس‌اس‌کیوال.
باارزش‌ترین جزء یک برنامه سازمانی که روی پست‌گرس‌اس‌کیوال اجرا می‌شود، داده‌های آن است؛ سرور را می‌توان دوباره راه‌اندازی کرد، کد را از مخزن کشید، اما داده‌های از دست رفته بازنمی‌گردند. در این مقاله، روش‌های پشتیبان‌گیری برای پست‌گرس‌اس‌کیوال، کاربرد هر یک و شیوه‌های عملی تبدیل عبارت «پشتیبان داریم» به عبارت «می‌توانیم بازیابی کنیم» را شرح می‌دهیم.
دو روش اصلی
پشتیبان منطقی: pg_dump / pg_dumpall
محتوای پایگاه داده را به صورت SQL یا قالب آرشیو ویژه صادر می‌کند. قابلیت جابجایی بین نسخه‌ها را دارد، بازیابی یک جدول واحد آسان است و برای پایگاه‌های داده کوچک و متوسط کفایت می‌کند. نقطه ضعف آن این است که تغییرات بین لحظه پشتیبان‌گیری و لحظه وقوع رویداد از دست می‌روند و روی پایگاه‌های داده بزرگ ممکن است زمان‌بر باشد.
# Özel formatta, sıkıştırılmış, tek veritabanı
pg_dump -Fc -Z 6 -d app -f /backups/app_$(date +%F_%H%M).dump
# Küme genelindeki roller ve ayarlar (ayrıca alınmalı)
pg_dumpall --globals-only -f /backups/globals_$(date +%F).sqlپشتیبان فیزیکی: pg_basebackup + آرشیو WAL
یک کپی سازگار از فهرست داده‌ها تهیه می‌کند؛ هنگامی که آرشیو WAL (ثبت از پیش نوشته‌شده) به آن اضافه شود، امکان بازگردانی به یک نقطه زمانی دلخواه (PITR) فراهم می‌شود. سناریوی «جدولی که ساعت ۱۴:۳۲ به اشتباه حذف شده را به ۱۴:۳۱ برگردان» فقط از این طریق ممکن است. این رویکرد استاندارد برای پایگاه‌های داده بزرگ و تحمل پایین از دست رفتن داده است.
# postgresql.conf
wal_level = replica
archive_mode = on
archive_command = 'test ! -f /wal_archive/%f && cp %p /wal_archive/%f'
# Temel yedek
pg_basebackup -D /backups/base_$(date +%F) -Ft -z -Xs -Pدر محیط‌های سازمانی، ابزارهایی مانند pgBackRest یا Barman این فرایند را مدیریت می‌کنند: پشتیبان کامل/تدریجی، سیاست نگهداری، اعتبارسنجی و پشتیبانی از مخزن دوردست را ارائه می‌دهند.
کدام روش، در چه شرایطی؟
نیازپیشنهاد پایگاه داده کوچک، قابل قبول بودن گم شدن داده روزانهپشتیبان روزانه pg_dump + کپی دوردست تحمل از دست رفتن داده در حد دقایقپشتیبان فیزیکی + آرشیو WAL (PITR) نیاز به بازیابی تک جدول / شماقالب آرشیو pg_dump (بازیابی انتخابی) قبل از ارتقای نسخههر دو روش با همقانون ۳-۲-۱ و تغییرناپذیری
سه نسخه، دو محیط مختلف، یک نسخه در مکانی دیگر. برای کپی دوردست، فضای ذخیره‌سازی ابری (خدمات سازگار با S3 یا راه‌اندازی شخصی MinIO) انتخابی رایج است؛ ویژگی‌هایی مانند «قفل شیء» (object lock) که مانع از حذف پشتیبان‌ها برای مدت مشخصی می‌شوند، در سناریوی باج‌افزار تعیین‌کننده هستند. کپی دوردست باید با دسترسی‌های جداگانه محافظت شود تا با اعتبارنامه‌های سرور تولیدی قابل حذف نباشد.
رمزگذاری
فایل‌های پشتیبان حاوی داده‌های شخصی و مالی هستند؛ رمزگذاری در حین انتقال و در حالت ذخیره‌سازی الزامی است. کلید نباید در همان مکان پشتیبان نگهداری شود؛ در غیر این صورت رمزگذاری صرفاً ظاهری خواهد بود. از دست رفتن کلید به معنای از دست رفتن پشتیبان است؛ مدیریت کلید بخشی از این برنامه است.
پشتیبانی که تست بازیابی روی آن انجام نشده، فقط یک امید است. تست نباید در روزی انجام شود که برای اولین بار واقعاً به پشتیبان نیاز است.
تست بازیابی: RTO و RPO را اندازه‌گیری کنید
در فواصل زمانی منظم، پشتیبان را روی یک سرور جداگانه (یا یک کانتینر موقت) بازیابی کنید، برنامه را به آن متصل کنید، عملیات اصلی را اجرا کنید و زمان صرف‌شده را ثبت کنید. اگر زمان اندازه‌گیری‌شده از هدف بازیابی شما (RTO) فراتر رفت، روش باید تغییر کند. در محیط‌های مبتنی بر Docker، تست را می‌توان خودکار کرد:
docker run --rm -d --name pg_restore_test -e POSTGRES_PASSWORD=test postgres:16
docker cp /backups/app_latest.dump pg_restore_test:/tmp/app.dump
docker exec pg_restore_test pg_restore -U postgres -d postgres --create /tmp/app.dump
docker exec pg_restore_test psql -U postgres -d app -c "select max(created_at) from orders;"مراقبت و مانیتورینگ: آگاهی از شکست پشتیبان
باید بررسی شود که وظیفه پشتیبان‌گیری نه تنها اجرا شده، بلکه با موفقیت به پایان رسیده و اندازه فایل مورد انتظار است. قانون «آخرین پشتیبان موفق قدیمی‌تر از ۲۴ ساعت است» باید به یک هشدار متصل شود. پشتیبان‌هایی که در سکوت شکست می‌خورند، رایج‌ترین سناریوی فاجعه‌بار هستند.
نکته‌ای درباره میزبانی شخصی Supabase
اگر Supabase را روی سرور خود اجرا می‌کنید، پشتیبان پست‌گرس‌اس‌کیوال به تنهایی کافی نیست: اجزای ذخیره‌سازی (storage)، پیکربندی و کلیدهای مخفی نیز باید پشتیبان‌گیری شوند؛ در غیر این صورت پایگاه داده برمی‌گردد اما فایل‌ها و پیکربندی احراز هویت بازنمی‌گردند.
پیشنهاد برنامه حداقلی
- پشتیبان شبانه pg_dump + آرشیو مداوم WAL
- پشتیبان پایه فیزیکی هفتگی
- کپی دوردست رمزگذاری‌شده، با دسترسی جداگانه و محافظت‌شده در برابر حذف
- آزمایش بازیابی هر سه ماه یک‌بار با ثبت زمان‌ها
- هشدار برای خرابی پشتیبان
بازگردانی به نقطه زمانی مشخص (PITR) گام به گام
اگر پشتیبان فیزیکی و آرشیو WAL موجود باشد، بازگشت به یک لحظه خاص امکان‌پذیر است. جریان مفهومی به این شکل است:
# 1. Temel yedeği yeni veri dizinine açın
mkdir /var/lib/postgresql/restore && tar -xzf /backups/base_2026-10-01/base.tar.gz -C /var/lib/postgresql/restore
# 2. Kurtarma hedefini ve WAL kaynağını belirtin (postgresql.conf veya postgresql.auto.conf)
restore_command = 'cp /wal_archive/%f %p'
recovery_target_time = '2026-10-03 14:31:00+03'
recovery_target_action = 'promote'
# 3. recovery.signal dosyasını oluşturun ve sunucuyu bu dizinle başlatın
touch /var/lib/postgresql/restore/recovery.signalسرور رکوردهای WAL را تا زمان هدف اعمال می‌کند و سپس به کار عادی خود ادامه می‌دهد. این فرایند نباید برای اولین بار در یک حادثه واقعی، بلکه باید در محیط آزمایشی امتحان شود؛ شایع‌ترین نقطه شکست PITR، وجود یک فایل ناقص در آرشیو WAL است که تنها آزمایش آن را آشکار می‌کند.
سیاست نگهداری: تا چه زمانی به عقب برگردیم؟
نگهداری پشتیبان‌های روزانه به مدت یک ماه، هفتگی به مدت سه ماه و ماهانه به مدت یک سال، نقطه شروع رایجی است؛ مقررات (مدت نگهداری اسناد حسابداری) و قوانین نگهداری داده‌های شخصی این سیاست را شکل می‌دهند. توجه: هنگامی که داده‌های شخصی باید حذف شوند، باید برنامه‌ای نیز برای نسخه‌های باقی‌مانده در پشتیبان‌ها وجود داشته باشد؛ بیشتر سازمان‌ها این مسئله را با قانون «حذف پشتیبان پس از اتمام دوره نگهداری» و تطابق این مدت با سیاست داده‌های شخصی حل می‌کنند.
نکات کاربردی در پایگاه‌های داده بزرگ
- اجرای موازی pg_dump (قالب دایرکتوری و گزینه -j) زمان را کاهش می‌دهد.
- برای جداول بزرگ (گزارش‌ها، ثبت رویدادها) می‌توان فرکانس پشتیبان‌گیری جداگانه‌ای تعریف کرد؛ لازم نیست هر شب تمام سوابق تاریخی پشتیبان‌گیری شوند.
- پشتیبان نباید در ساعات اوج مصرف سرور تولیدی، بلکه در زمان بار کم گرفته شود؛ در پشتیبان فیزیکی این تأثیر کمتر است.
- فشرده‌سازی و رمزگذاری پشتیبان از پردازنده (CPU) استفاده می‌کند؛ این موضوع باید در برنامه‌ریزی منابع سرور لحاظ شود.
تکثیر (Replication) پشتیبان نیست
پشتیبان داغ (streaming replication) دسترسی پذیری بالا فراهم می‌کند؛ اما جدولی که به اشتباه حذف شده، ظرف چند ثانیه در نسخه تکثیرشده نیز منعکس می‌شود. تکثیر و پشتیبان‌گیری مکمل یکدیگرند و جایگزین یکدیگر نمی‌شوند. به همین ترتیب، اسنپ‌شات‌های دیسک امکان بازگشت سریع را فراهم می‌کنند اما برای سازگاری باید با پایگاه داده هماهنگ شده و در مکان دیگری کپی شوند.
پشتیبان‌گیری در محیط Docker
در پست‌گرس‌اس‌کیوال که با Docker Compose اجرا می‌شود، پشتیبان نباید از داخل کانتینر، بلکه باید توسط یک کانتینر پشتیبان جداگانه یا یک وظیفه زمان‌بندی‌شده روی میزبان (host) گرفته شود؛ تا زمانی که حجم داده (volume) متصل است، pg_dump از طریق شبکه کانتینر کار می‌کند. سازگاری نسخه ایمیج کانتینر با قالب پشتیبان (نسخه pg_dump نباید از نسخه پایگاه داده قدیمی‌تر باشد) باید رصد شود.
# Örnek: Compose ortamında zamanlanmış pg_dump (ana makine cron'u)
0 2 * * * docker exec app_db pg_dump -U app -Fc app | gpg --encrypt -r backup@ornek > /backups/app_$(date +%F).dump.gpgمستندسازی
برنامه پشتیبان‌گیری باید مکتوب باشد: چه چیزی، با چه فرکانسی، کجا، توسط چه کسی و چگونه بازیابی می‌شود. مراحل بازیابی باید به اندازه کافی واضح نوشته شوند تا فردی که سیستم را نمی‌شناسد بتواند آنها را دنبال کند؛ در هنگام بروز فاجعه، ممکن است شخصی که سیستم را بهتر می‌شناسد در دسترس نباشد.
در خدمات زیرساخت سرور و ابر شرکت Cy Logic، استراتژی پشتیبان‌گیری یک جزء تعریف‌شده است، نه یک پیوست اختیاری.