بکاپ خودکار وردپرس روی Amazon S3 ؛ فایل، دیتابیس و بازیابی

برای ساخت بکاپ خودکار وردپرس روی S3 باید دو بخش اصلی سایت را هم‌زمان حفظ کنید: فایل‌های وردپرس و پایگاه داده. در این آموزش، روی یک VPS لینوکسی ابتدا با WP-CLI از دیتابیس خروجی می‌گیریم، فایل‌های سایت را با tar فشرده می‌کنیم، نسخه‌ها را با AWS CLI داخل یک Bucket خصوصی در Amazon S3 می‌فرستیم و در پایان با Cron اجرای روزانه را خودکار می‌کنیم. بخش بازیابی یا Restore نیز کامل توضیح داده شده تا بکاپ فقط «فایل ذخیره‌شده» نباشد، بلکه واقعاً قابل استفاده باشد.

بکاپ وردپرس روی S3 دقیقاً چیست؟

وردپرس فقط مجموعه‌ای از فایل‌های PHP نیست. نوشته‌ها، تنظیمات، کاربران، سفارش‌های ووکامرس و داده بسیاری از افزونه‌ها داخل MySQL یا MariaDB ذخیره می‌شوند. از طرف دیگر قالب‌ها، افزونه‌ها، تصاویر رسانه، فایل‌های آپلودی و فایل تنظیمات wp-config.php روی دیسک سرور قرار دارند. اگر فقط یکی از این دو بخش را ذخیره کنید، در زمان خرابی ممکن است سایت کامل برنگردد.

Amazon S3 یک Object Storage است؛ یعنی فایل‌ها به شکل Object داخل Bucket نگهداری می‌شوند. در این آموزش هر اجرای بکاپ در Prefix جداگانه‌ای شبیه wordpress/example.com/2026-10-04T01-30-00Z/ ذخیره می‌شود تا بکاپ‌های مختلف روی هم نوشته نشوند.

پیش‌نیازهای ساخت بکاپ خودکار وردپرس روی S3

مسیر اصلی این آموزش برای WordPress روی VPS یا سرور لینوکسی با دسترسی SSH نوشته شده است. نمونه فرمان‌ها با Ubuntu سازگارند. اگر از cPanel، DirectAdmin یا ساختار سفارشی استفاده می‌کنید، ممکن است مسیر سایت، نام کاربر وب‌سرور یا Permissionها متفاوت باشند.

پیدا کردن مسیر واقعی وردپرس

همه سایت‌ها در /var/www/html قرار ندارند. ابتدا فایل wp-config.php را پیدا کنید. این فرمان فقط جست‌وجو می‌کند و چیزی را تغییر نمی‌دهد:

sudo find /var/www /home -maxdepth 5 -type f -name wp-config.php -print 2>/dev/null

اگر خروجی مثلاً /var/www/example.com/public_html/wp-config.php بود، ریشه وردپرس شما /var/www/example.com/public_html است. در ادامه مقاله همین مسیر را به‌عنوان نمونه استفاده می‌کنیم و شما باید آن را با مسیر واقعی خودتان جایگزین کنید.

حجم سایت و فضای آزاد را بررسی کنید

sudo du -sh /var/www/example.com/public_html
df -h

دستور اول حجم تقریبی فایل‌های سایت و دستور دوم فضای آزاد پارتیشن‌ها را نشان می‌دهد. حجم آرشیو نهایی ممکن است کمتر شود، اما برای فایل‌هایی مثل JPEG، WebP و ویدئو که از قبل فشرده هستند، کاهش حجم همیشه زیاد نیست.

مرحله ۱: ساخت Bucket خصوصی در Amazon S3

Bucket ظرف اصلی نگهداری Objectها در S3 است. برای بکاپ، Bucket نباید Public باشد. در کنسول AWS وارد S3 شوید، یک Bucket جدید بسازید، Region را انتخاب کنید و Block Public Access را فعال نگه دارید.

در این مقاله نام نمونه Bucket برابر my-wordpress-backups و Prefix برابر wordpress/example.com/ است. نام Bucket در AWS باید یکتا باشد؛ بنابراین این نام را عیناً استفاده نکنید.

ساخت IAM User مخصوص بکاپ

اگر VPS شما خارج از AWS است، معمولاً برای AWS CLI به Access Key نیاز دارید. برای این کار یک IAM User اختصاصی بسازید و فقط دسترسی لازم به Prefix بکاپ همان سایت را بدهید. AdministratorAccess برای بکاپ وردپرس لازم نیست و ریسک غیرضروری ایجاد می‌کند.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListBackupPrefix",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::my-wordpress-backups",
      "Condition": {
        "StringLike": {
          "s3:prefix": [
            "wordpress/example.com/*"
          ]
        }
      }
    },
    {
      "Sid": "ReadWriteBackupObjects",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::my-wordpress-backups/wordpress/example.com/*"
    }
  ]
}

در این Policy عمداً مجوز s3:DeleteObject قرار نداده‌ایم. بنابراین Credential بکاپ می‌تواند فایل جدید بنویسد و نسخه‌ها را بخواند، اما برای حذف بکاپ‌های قبلی مجوز مستقیم ندارد. حذف یا انتقال نسخه‌های قدیمی را بهتر است با Lifecycle خود S3 مدیریت کنید.

مرحله ۲: نصب ابزارهای لازم روی Ubuntu

وارد SSH سرور شوید و ابتدا ابزارهای پایه را نصب کنید:

sudo apt update
sudo apt install -y php-cli curl ca-certificates tar gzip unzip default-mysql-client cron acl

بعد از نصب، PHP CLI و Cron را بررسی کنید:

php --version
systemctl status cron --no-pager

اگر Cron فعال نبود:

sudo systemctl enable --now cron

نصب WP-CLI

WP-CLI ابزار خط فرمان وردپرس است. از آن برای Export و Import دیتابیس استفاده می‌کنیم:

cd /tmp
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
php wp-cli.phar --info
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp
wp --info

اگر فرمان آخر اطلاعات WP-CLI و PHP را نمایش داد، نصب انجام شده است.

نصب AWS CLI

AWS CLI ابزار رسمی خط فرمان AWS برای کار با S3 است. اگر Snap روی Ubuntu شما فعال است:

sudo snap install aws-cli --classic
aws --version

اگر Snap در دسترس نیست، از روش رسمی نصب AWS CLI v2 استفاده کنید که لینک آن در بخش منابع آمده است.

مرحله ۳: ساخت کاربر محدود برای اجرای بکاپ

بهتر است Job روزانه را با root اجرا نکنیم. یک System User با نام wpbackup می‌سازیم که Login تعاملی ندارد ولی از طریق Cron می‌تواند اسکریپت بکاپ را اجرا کند.

sudo useradd --system --create-home \
  --home-dir /var/lib/wpbackup \
  --shell /usr/sbin/nologin \
  --groups www-data \
  wpbackup

sudo mkdir -p /var/backups/wordpress/example.com
sudo chown -R wpbackup:wpbackup /var/backups/wordpress
sudo chmod 700 /var/backups/wordpress/example.com

در نمونه بالا فرض شده فایل‌های سایت برای گروه www-data قابل خواندن هستند. قبل از تغییر گروه، مالکیت واقعی فایل تنظیمات وردپرس را ببینید:

stat -c '%U:%G %a %n' /var/www/example.com/public_html/wp-config.php

اکنون خواندن فایل‌ها توسط کاربر بکاپ را تست کنید:

sudo -u wpbackup -H test -r /var/www/example.com/public_html/wp-config.php \
  && echo "wp-config readable"

sudo -u wpbackup -H find /var/www/example.com/public_html \
  -type f ! -readable -print | head

اگر فرمان دوم خروجی نداشت، فایل‌های سایت برای کاربر بکاپ قابل خواندن هستند. اگر فقط فایل خاصی محدود بود، به‌جای chmod -R 777 از Permission یا ACL محدود استفاده کنید.

مرحله ۴: اتصال کاربر wpbackup به Amazon S3

Credential را برای همان کاربر بکاپ ثبت کنید:

sudo -u wpbackup -H aws configure --profile wordpress-backup

AWS CLI از شما Access Key ID، Secret Access Key، Region و Output Format می‌خواهد. Region را مطابق Bucket وارد کنید و برای Output می‌توانید json انتخاب کنید.

sudo chmod 700 /var/lib/wpbackup/.aws
sudo chmod 600 /var/lib/wpbackup/.aws/credentials
sudo chown -R wpbackup:wpbackup /var/lib/wpbackup/.aws

تست دسترسی به S3

sudo -u wpbackup -H aws --profile wordpress-backup s3 ls \
  s3://my-wordpress-backups/wordpress/example.com/

اگر هنوز بکاپی وجود ندارد، خروجی می‌تواند خالی باشد. نکته مهم این است که خطای AccessDenied یا Credential دریافت نکنید.

مرحله ۵: Export دیتابیس را قبل از اتوماسیون تست کنید

ابتدا مطمئن شوید WP-CLI با همان کاربر محدود می‌تواند WordPress و دیتابیس را پیدا کند:

sudo -u wpbackup -H wp \
  --path=/var/www/example.com/public_html \
  db check

سپس یک Export آزمایشی بسازید:

sudo -u wpbackup -H wp \
  --path=/var/www/example.com/public_html \
  db export /var/backups/wordpress/example.com/manual-test.sql \
  --single-transaction \
  --add-drop-table

گزینه –single-transaction برای جدول‌های تراکنشی مانند InnoDB به ساخت Dump سازگارتر کمک می‌کند. –add-drop-table نیز دستور حذف جدول قبلی را در فایل SQL قرار می‌دهد تا Restore قابل پیش‌بینی‌تر شود.

sudo rm -f /var/backups/wordpress/example.com/manual-test.sql

مرحله ۶: ساخت اسکریپت کامل بکاپ وردپرس روی S3

اسکریپت زیر Export دیتابیس، فشرده‌سازی، آرشیو فایل‌ها، Checksum، Upload روی S3 و بررسی اندازه فایل Remote را انجام می‌دهد. اگر هر مرحله شکست بخورد، نسخه موقت روی سرور باقی می‌ماند تا بتوانید خطا را بررسی کنید.

فایل را ایجاد کنید:

sudo nano /usr/local/sbin/wordpress-s3-backup.sh

محتوای زیر را قرار دهید و فقط مقادیر بخش تنظیمات را تغییر دهید:

#!/usr/bin/env bash
set -Eeuo pipefail
umask 077

export HOME="/var/lib/wpbackup"
export PATH="/usr/local/bin:/usr/bin:/bin:/snap/bin"

WP_ROOT="/var/www/example.com/public_html"
BACKUP_ROOT="/var/backups/wordpress/example.com"
S3_BUCKET="my-wordpress-backups"
S3_PREFIX="wordpress/example.com"
AWS_PROFILE="wordpress-backup"

STAMP="$(date -u +'%Y-%m-%dT%H-%M-%SZ')"
RUN_DIR="${BACKUP_ROOT}/${STAMP}"
LOCK_FILE="${BACKUP_ROOT}/backup.lock"

DB_SQL="${RUN_DIR}/database-${STAMP}.sql"
DB_GZ="${DB_SQL}.gz"
FILES_TGZ="${RUN_DIR}/files-${STAMP}.tar.gz"
CHECKSUM_FILE="${RUN_DIR}/SHA256SUMS"

mkdir -p "${RUN_DIR}"

exec 9>"${LOCK_FILE}"
if ! flock -n 9; then
  echo "Another backup is already running."
  exit 0
fi

cleanup_on_error() {
  echo "Backup failed at $(date -u +'%Y-%m-%dT%H:%M:%SZ')."
  echo "Temporary files are kept in: ${RUN_DIR}"
}
trap cleanup_on_error ERR

echo "[1/7] Exporting WordPress database..."
wp --path="${WP_ROOT}" db export "${DB_SQL}" \
  --single-transaction \
  --add-drop-table

echo "[2/7] Compressing database..."
gzip "${DB_SQL}"

echo "[3/7] Archiving WordPress files..."
tar -czf "${FILES_TGZ}" -C "${WP_ROOT}" .

echo "[4/7] Creating SHA-256 checksums..."
(
  cd "${RUN_DIR}"
  sha256sum "$(basename "${DB_GZ}")" "$(basename "${FILES_TGZ}")" > "$(basename "${CHECKSUM_FILE}")"
)

REMOTE_BASE="s3://${S3_BUCKET}/${S3_PREFIX}/${STAMP}"

echo "[5/7] Uploading files to S3..."
aws --profile "${AWS_PROFILE}" s3 cp \
  "${DB_GZ}" "${REMOTE_BASE}/$(basename "${DB_GZ}")" \
  --only-show-errors

aws --profile "${AWS_PROFILE}" s3 cp \
  "${FILES_TGZ}" "${REMOTE_BASE}/$(basename "${FILES_TGZ}")" \
  --only-show-errors

aws --profile "${AWS_PROFILE}" s3 cp \
  "${CHECKSUM_FILE}" "${REMOTE_BASE}/SHA256SUMS" \
  --only-show-errors

echo "[6/7] Verifying remote object sizes..."
LOCAL_DB_SIZE="$(stat -c '%s' "${DB_GZ}")"
REMOTE_DB_SIZE="$(aws --profile "${AWS_PROFILE}" s3api head-object \
  --bucket "${S3_BUCKET}" \
  --key "${S3_PREFIX}/${STAMP}/$(basename "${DB_GZ}")" \
  --query ContentLength \
  --output text)"

LOCAL_FILES_SIZE="$(stat -c '%s' "${FILES_TGZ}")"
REMOTE_FILES_SIZE="$(aws --profile "${AWS_PROFILE}" s3api head-object \
  --bucket "${S3_BUCKET}" \
  --key "${S3_PREFIX}/${STAMP}/$(basename "${FILES_TGZ}")" \
  --query ContentLength \
  --output text)"

if [[ "${LOCAL_DB_SIZE}" != "${REMOTE_DB_SIZE}" ]]; then
  echo "Database size verification failed."
  exit 1
fi

if [[ "${LOCAL_FILES_SIZE}" != "${REMOTE_FILES_SIZE}" ]]; then
  echo "Files archive size verification failed."
  exit 1
fi

echo "[7/7] Removing temporary local backup..."
rm -rf "${RUN_DIR}"

echo "Backup completed successfully: ${REMOTE_BASE}/"

اسکریپت بالا چه نکات امنیتی دارد؟

فایل را ذخیره و Permission آن را تنظیم کنید:

sudo chown root:wpbackup /usr/local/sbin/wordpress-s3-backup.sh
sudo chmod 750 /usr/local/sbin/wordpress-s3-backup.sh

مرحله ۷: اولین بکاپ را دستی اجرا کنید

قبل از فعال کردن Cron، همان اسکریپتی را که قرار است خودکار اجرا شود دستی اجرا کنید:

sudo -u wpbackup -H /usr/local/sbin/wordpress-s3-backup.sh

در اجرای موفق باید مراحل [1/7] تا [7/7] و در پایان پیام Backup completed successfully را ببینید.

بعد از آن S3 را واقعاً بررسی کنید:

sudo -u wpbackup -H aws --profile wordpress-backup s3 ls \
  s3://my-wordpress-backups/wordpress/example.com/ \
  --recursive

برای هر اجرا باید حداقل سه Object ببینید: آرشیو فایل‌ها، دیتابیس فشرده و SHA256SUMS.

مرحله ۸: زمان‌بندی خودکار با Cron

Cron زمان‌بند سیستم‌عامل لینوکس است. برخلاف WP-Cron، برای اجرا منتظر بازدید صفحه وردپرس نمی‌ماند. ابتدا Timezone سرور را ببینید:

timedatectl

Crontab کاربر بکاپ را باز کنید:

sudo crontab -u wpbackup -e

برای اجرای روزانه ساعت 03:15 به وقت خود سرور:

15 3 * * * /usr/local/sbin/wordpress-s3-backup.sh >> /var/backups/wordpress/example.com/cron.log 2>&1

15 3 * * * یعنی هر روز ساعت 03:15. بهتر است زمانی را انتخاب کنید که سایت کمترین ترافیک را دارد.

sudo crontab -u wpbackup -l
tail -n 100 /var/backups/wordpress/example.com/cron.log

مرحله ۹: تنظیم Lifecycle برای کنترل تعداد بکاپ‌ها

هر بار اجرای اسکریپت یک Prefix جدید می‌سازد، بنابراین تعداد Objectها به مرور افزایش پیدا می‌کند. برای جلوگیری از رشد بی‌نهایت هزینه و فضای ذخیره‌سازی، در S3 از Lifecycle Rule استفاده کنید.

در کنسول AWS مسیر Bucket → Management → Lifecycle rules را باز کنید و Rule را فقط روی Prefix wordpress/example.com/ اعمال کنید. تعداد روز مناسب را خودتان بر اساس حساسیت داده، حجم تغییرات و سیاست نگهداری انتخاب کنید. مثلاً نگهداری ۳۰ یا ۶۰ روز فقط نمونه است و نسخه واحد برای همه سایت‌ها وجود ندارد.

مرحله ۱۰: Restore آزمایشی؛ مهم‌ترین بخش بکاپ

بکاپی که هیچ‌وقت Restore نشده، هنوز قابل اعتماد نیست. حداقل یک‌بار روی Staging یا VPS آزمایشی یکی از نسخه‌ها را دانلود، Checksum را بررسی و بازیابی کنید.

دانلود یک نسخه مشخص

mkdir -p /var/backups/wordpress/restore-test
cd /var/backups/wordpress/restore-test

sudo -u wpbackup -H aws --profile wordpress-backup s3 cp \
  s3://my-wordpress-backups/wordpress/example.com/2026-10-04T01-30-00Z/ \
  . \
  --recursive

Timestamp نمونه را با یکی از مسیرهای واقعی داخل S3 جایگزین کنید.

بررسی SHA-256

cd /var/backups/wordpress/restore-test
sha256sum -c SHA256SUMS

برای هر فایل باید OK نمایش داده شود. اگر FAILED دیدید، تا مشخص‌شدن علت از آن نسخه برای Restore استفاده نکنید.

بررسی محتویات آرشیو فایل‌ها

tar -tzf files-2026-10-04T01-30-00Z.tar.gz | head -n 40

باید پوشه‌هایی مانند wp-admin/، wp-includes/ و wp-content/ را ببینید.

بازیابی دیتابیس در Staging

gunzip -k database-2026-10-04T01-30-00Z.sql.gz

wp --path=/var/www/staging.example.com/public_html \
  db import /var/backups/wordpress/restore-test/database-2026-10-04T01-30-00Z.sql

ترتیب صحیح بازیابی سایت اصلی

Rollback: اگر Restore جدید مشکل داشت، سایت را دوباره متوقف کنید، نسخه Restoreشده را کنار بگذارید، پوشه before-restore را به مسیر اصلی برگردانید و دیتابیس اضطراری مرحله اول را Import کنید.

سایت‌های ووکامرس و پرتغییر چه تفاوتی دارند؟

در سایت محتوایی کم‌تغییر، فاصله چند دقیقه‌ای بین Dump دیتابیس و آرشیو فایل‌ها معمولاً مشکل بزرگی ایجاد نمی‌کند. در فروشگاه پرترافیک، ممکن است در همان فاصله سفارش جدید، Upload رسانه یا تغییر داده رخ دهد. در این شرایط باید RPO و RTO مشخص کنید و علاوه بر بکاپ روزانه، روش‌های کوتاه‌تر یا Snapshot زیرساختی را در صورت نیاز در نظر بگیرید.

استفاده از MinIO یا S3-Compatible به‌جای Amazon S3

S3 یک API پرکاربرد برای Object Storage است و سرویس‌های دیگری نیز سازگاری S3 ارائه می‌کنند. اگر قصد دارید مقصد بکاپ را خودتان روی سروری جداگانه نگه دارید، MinIO یکی از گزینه‌های قابل بررسی است. در این حالت Endpoint، TLS، امنیت شبکه، سلامت دیسک مقصد و خود بکاپ MinIO نیز مسئولیت شماست.

برای این سناریو می‌توانید راهنمای ساخت Object Storage سازگار با S3 با MinIO روی VPS را بخوانید. هنگام استفاده از Provider غیر AWS باید Endpoint واقعی همان سرویس را مطابق مستنداتش به AWS CLI بدهید.

اگر فقط هاست وردپرس دارید و SSH در اختیار شما نیست

مسیر WP-CLI + AWS CLI برای VPS مناسب است. روی هاست اشتراکی معمولاً دسترسی ساخت User سیستم، نصب AWS CLI یا مدیریت Cron سیستم محدود است. در چنین شرایطی افزونه بکاپی که مقصد S3 را پشتیبانی کند، گزینه عملی‌تری است.

افزونه‌هایی مانند BackWPup امکان بکاپ فایل و دیتابیس، زمان‌بندی و مقصد Amazon S3 را ارائه می‌کنند. فقط توجه کنید WordPress Cron یا WP-Cron یک سرویس زمان‌بندی دائماً فعال نیست؛ کارهای Due هنگام بارگذاری صفحه بررسی می‌شوند. روی سایت کم‌ترافیک ممکن است Job دقیقاً در زمان تنظیم‌شده اجرا نشود.

خطاهای رایج بکاپ وردپرس روی S3

خطای Unable to locate credentials

AWS CLI برای کاربر اجراکننده Credential پیدا نکرده است. بررسی کنید Profile برای wpbackup ساخته شده باشد:

sudo -u wpbackup -H aws configure list --profile wordpress-backup

خطای AccessDenied

نام Bucket، Prefix و Resourceهای IAM Policy را با مقادیر واقعی اسکریپت مقایسه کنید. برای حل سریع، AdministratorAccess ندهید؛ مشکل Policy را دقیق پیدا کنید.

خطای This does not seem to be a WordPress installation

مقدار WP_ROOT اشتباه است یا کاربر بکاپ فایل‌های وردپرس را نمی‌خواند. وجود wp-config.php و پوشه wp-includes را در مسیر بررسی کنید.

mysqldump پیدا نمی‌شود

command -v mysqldump
mysql --version

اگر ابزار وجود ندارد، Client مناسب MySQL/MariaDB را نصب کنید. اگر ابزار نصب است ولی اتصال خطا می‌دهد، DB_HOST و Permissionهای دیتابیس را در wp-config.php بررسی کنید.

اسکریپت دستی کار می‌کند ولی Cron نه

systemctl status cron --no-pager
sudo crontab -u wpbackup -l
tail -n 100 /var/backups/wordpress/example.com/cron.log

تفاوت Environment میان Shell و Cron علت رایجی است. به همین دلیل PATH و HOME را داخل اسکریپت به‌صورت صریح تعیین کردیم.

حجم بکاپ غیرعادی زیاد شده است

sudo du -xh /var/www/example.com/public_html/wp-content \
  --max-depth=1 | sort -h

گاهی افزونه بکاپ، فایل‌های قدیمی خودش را داخل wp-content نگه می‌دارد و اسکریپت جدید دوباره همان فایل‌ها را در Backup بعدی قرار می‌دهد. قبل از Exclude کردن هر پوشه، مطمئن شوید برای Restore لازم نیست.

چطور اتوماسیون بکاپ را متوقف کنیم؟

اگر می‌خواهید بکاپ‌های قبلی S3 باقی بمانند ولی اجرای خودکار متوقف شود، فقط Cron را حذف کنید:

sudo crontab -u wpbackup -e

خط مربوط به wordpress-s3-backup.sh را حذف کنید. اگر می‌خواهید کل سیستم جمع شود، ابتدا Access Key را در IAM غیرفعال کنید، سپس Credential محلی و کاربر سیستم را حذف کنید. Bucket و Objectهای قدیمی را فقط بعد از بررسی نیاز بازیابی پاک کنید.

سؤالات متداول

آیا فقط wp-content برای بکاپ وردپرس کافی است؟

خیر. فایل‌ها بخش مهمی از سایت هستند، اما نوشته‌ها، کاربران، تنظیمات و بسیاری از داده افزونه‌ها در دیتابیس قرار دارند. برای Restore کامل باید فایل‌ها و دیتابیس را با هم داشته باشید.

آیا وجود فایل در S3 یعنی بکاپ سالم است؟

خیر. باید Checksum را بررسی کنید و Restore آزمایشی انجام دهید. ممکن است فایل Upload شده باشد ولی محتوای بکاپ ناقص یا نامناسب باشد.

هر چند وقت یک‌بار بکاپ بگیریم؟

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

آیا Access Key را داخل اسکریپت قرار دهیم؟

خیر. Secret Key را داخل اسکریپت یا Git نگذارید. روی EC2 از IAM Role استفاده کنید و روی VPS خارج از AWS، Credential محدود را در Home کاربر بکاپ با Permission مناسب نگه دارید.

آیا MinIO می‌تواند جای Amazon S3 استفاده شود؟

اگر سرویس مقصد S3-Compatible باشد، معماری مشابه قابل استفاده است. با این تفاوت که Endpoint، TLS، Region و پارامترهای Client باید طبق مستندات همان سرویس تنظیم شوند.

چرا Cron سیستم بهتر از WP-Cron است؟

برای VPS، Cron سیستم مستقل از بازدید سایت کار می‌کند و زمان‌بندی قابل پیش‌بینی‌تری دارد. WP-Cron هنگام Page Load کارهای موعدرسیده را بررسی می‌کند و روی سایت کم‌ترافیک ممکن است دقیقاً سر ساعت اجرا نشود.

منابع رسمی