آموزش بکاپ خودکار سرور MTA با Cron

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

به‌جای اینکه هر بار به‌صورت دستی از سرور نسخه پشتیبان تهیه کنیم، می‌توان یک اسکریپت Bash ساخت و با Cron آن را به‌صورت روزانه و خودکار اجرا کرد.

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

از چه اطلاعاتی باید در سرور MTA بکاپ بگیریم؟

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

فایل یا پوشه	کاربرد	اهمیت بکاپ
mtaserver.conf	تنظیمات اصلی سرور	بسیار مهم
acl.xml	کاربران، گروه‌ها و دسترسی‌ها	بسیار مهم
internal.db	حساب‌ها و Account Data	بسیار مهم
registry.db	دیتابیس داخلی MTA	مهم
resources/	گیم‌مود و Resourceهای پروژه	بسیار مهم
MySQL Database	اطلاعات گیم‌مودهای متصل به MySQL	بسیار مهم
logs/	Logهای سرور	اختیاری

internal.db چیست؟

فایل internal.db دیتابیس داخلی حساب‌های MTA است و اطلاعاتی مانند Accountها، رمزهای Hash شده و داده‌هایی که با setAccountData ذخیره شده‌اند در آن قرار می‌گیرند.

mods/deathmatch/internal.db

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

registry.db چیست؟

registry.db دیتابیس داخلی دیگری در MTA است و اطلاعاتی که اسکریپت‌ها از سیستم دیتابیس داخلی MTA استفاده می‌کنند در آن ذخیره می‌شود.

mods/deathmatch/registry.db

حتی اگر پروژه اصلی از MySQL استفاده می‌کند، بهتر است registry.db نیز در بکاپ قرار داشته باشد.

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

فرض می‌کنیم MTA Server در مسیر زیر نصب شده است:

/home/mta/multitheftauto_linux_x64

بکاپ‌ها را در مسیر زیر نگهداری می‌کنیم:

/home/mta/backups

هر بار اجرای اسکریپت یک پوشه جداگانه با تاریخ و ساعت می‌سازد؛ برای مثال:

/home/mta/backups/2026-08-16_04-00-01/

داخل آن می‌تواند فایل‌هایی مشابه زیر وجود داشته باشد:

mta-files.tar.gz
mysql-database.sql.gz
backup-info.txt

مرحله اول: ساخت پوشه بکاپ

sudo mkdir -p /home/mta/backups

اگر اسکریپت با root اجرا می‌شود، این مسیر برای ذخیره بکاپ کافی است. درصورت استفاده از کاربر دیگری، Permission پوشه باید متناسب با همان کاربر تنظیم شود.

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

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

sudo nano /usr/local/sbin/mta-backup.sh

کل اسکریپت زیر را داخل آن قرار دهید:

#!/usr/bin/env bash

set -Eeuo pipefail

# ===============================
# KimiaGame - MTA Backup Script
# ===============================

MTA_DIR="/home/mta/multitheftauto_linux_x64"
DEATHMATCH_DIR="$MTA_DIR/mods/deathmatch"

BACKUP_ROOT="/home/mta/backups"
RETENTION_DAYS=14

# نام Service در systemd
MTA_SERVICE="mtaserver"

# MySQL Backup
# اگر MySQL ندارید مقدار 0 باقی بماند.
MYSQL_BACKUP=0
MYSQL_DATABASE="kimia_mta"
MYSQL_CONFIG="/root/.my.cnf"

DATE="$(date '+%Y-%m-%d_%H-%M-%S')"
BACKUP_DIR="$BACKUP_ROOT/$DATE"

MTA_ARCHIVE="$BACKUP_DIR/mta-files.tar.gz"
MYSQL_ARCHIVE="$BACKUP_DIR/mysql-database.sql.gz"
INFO_FILE="$BACKUP_DIR/backup-info.txt"

SERVICE_WAS_RUNNING=0

log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $*"
}

start_mta_if_needed() {
    if [[ "$SERVICE_WAS_RUNNING" -eq 1 ]]; then
        log "Starting MTA service..."
        systemctl start "$MTA_SERVICE" || true
    fi
}

trap start_mta_if_needed EXIT

log "Starting MTA backup..."

mkdir -p "$BACKUP_DIR"

if [[ ! -d "$DEATHMATCH_DIR" ]]; then
    log "ERROR: MTA deathmatch directory not found:"
    log "$DEATHMATCH_DIR"
    exit 1
fi

# بررسی وضعیت سرور
if systemctl is-active --quiet "$MTA_SERVICE"; then
    SERVICE_WAS_RUNNING=1

    log "Stopping MTA service for a consistent backup..."
    systemctl stop "$MTA_SERVICE"
else
    log "MTA service is not running."
fi

# ---------------------------------
# انتخاب فایل‌های موجود برای Backup
# ---------------------------------

BACKUP_ITEMS=()

for ITEM in \
    "mtaserver.conf" \
    "acl.xml" \
    "internal.db" \
    "registry.db" \
    "resources"
do
    if [[ -e "$DEATHMATCH_DIR/$ITEM" ]]; then
        BACKUP_ITEMS+=("$ITEM")
    else
        log "WARNING: $ITEM not found - skipped."
    fi
done

if [[ "${#BACKUP_ITEMS[@]}" -eq 0 ]]; then
    log "ERROR: Nothing found to backup."
    exit 1
fi

# -----------------------------
# ساخت Backup فایل‌های MTA
# -----------------------------

log "Creating compressed MTA archive..."

tar -czf "$MTA_ARCHIVE" \
    -C "$DEATHMATCH_DIR" \
    "${BACKUP_ITEMS[@]}"

log "MTA archive created:"
log "$MTA_ARCHIVE"

# -----------------------------
# Backup اختیاری MySQL
# -----------------------------

if [[ "$MYSQL_BACKUP" -eq 1 ]]; then

    if [[ ! -f "$MYSQL_CONFIG" ]]; then
        log "ERROR: MySQL config file not found:"
        log "$MYSQL_CONFIG"
        exit 1
    fi

    log "Creating MySQL dump..."

    mysqldump \
        --defaults-extra-file="$MYSQL_CONFIG" \
        --databases "$MYSQL_DATABASE" \
        --routines \
        --events \
        --triggers \
        | gzip > "$MYSQL_ARCHIVE"

    log "MySQL backup created:"
    log "$MYSQL_ARCHIVE"
else
    log "MySQL backup is disabled."
fi

# -----------------------------
# اطلاعات Backup
# -----------------------------

{
    echo "KimiaGame MTA Backup"
    echo
    echo "Created: $(date)"
    echo "MTA Path: $MTA_DIR"
    echo "Service: $MTA_SERVICE"
    echo "MySQL Backup: $MYSQL_BACKUP"
    echo
    echo "Included MTA items:"
    printf '%s\n' "${BACKUP_ITEMS[@]}"
} > "$INFO_FILE"

# -----------------------------
# کنترل سلامت Archive
# -----------------------------

log "Testing MTA archive..."

tar -tzf "$MTA_ARCHIVE" > /dev/null

if [[ "$MYSQL_BACKUP" -eq 1 ]]; then
    log "Testing compressed MySQL backup..."
    gzip -t "$MYSQL_ARCHIVE"
fi

# -----------------------------
# حذف Backupهای قدیمی
# -----------------------------

log "Removing old backup directories..."

find "$BACKUP_ROOT" \
    -mindepth 1 \
    -maxdepth 1 \
    -type d \
    -mtime +"$RETENTION_DAYS" \
    -exec rm -rf -- {} +

log "Backup completed successfully."

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

یک پوشه جدید با تاریخ و ساعت می‌سازد.
وضعیت Service سرور MTA را بررسی می‌کند.
درصورت فعال بودن، MTA را موقتاً Stop می‌کند.
از تنظیمات، ACL، دیتابیس‌ها و Resourceها بکاپ می‌گیرد.
فایل‌ها را در یک tar.gz فشرده می‌کند.
درصورت فعال بودن گزینه MySQL از دیتابیس Dump می‌گیرد.
سلامت فایل‌های فشرده را آزمایش می‌کند.
بکاپ‌های قدیمی را حذف می‌کند.
در پایان MTA را دوباره Start می‌کند.

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

Resourceها و به‌خصوص فایل‌های دیتابیس ممکن است هنگام فعالیت سرور در حال تغییر باشند. توقف کوتاه MTA باعث می‌شود نسخه‌ای که کپی می‌کنیم در یک وضعیت ثابت قرار داشته باشد.

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

تنظیم مدت نگهداری بکاپ‌ها

در اسکریپت مقدار زیر وجود دارد:

RETENTION_DAYS=14

می‌توانید آن را براساس فضای دیسک تغییر دهید؛ برای نمونه:

RETENTION_DAYS=7

یا:

RETENTION_DAYS=30

قبل از افزایش مدت نگهداری، فضای خالی VPS را بررسی کنید.

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

sudo chmod 750 /usr/local/sbin/mta-backup.sh

Permission فایل را بررسی کنید:

ls -lh /usr/local/sbin/mta-backup.sh

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

قبل از اضافه‌کردن Cron حتماً اسکریپت را دستی آزمایش کنید:

sudo /usr/local/sbin/mta-backup.sh

در پایان باید پیام زیر را مشاهده کنید:

Backup completed successfully.

بررسی فایل بکاپ ساخته‌شده

ls -lah /home/mta/backups

سپس وارد جدیدترین پوشه شوید و فایل‌ها را ببینید:

ls -lah \
/home/mta/backups/DATE-AND-TIME/

مشاهده محتوای بکاپ MTA بدون Extract

tar -tzf \
/home/mta/backups/DATE-AND-TIME/mta-files.tar.gz

باید فایل‌هایی مانند موارد زیر را مشاهده کنید:

mtaserver.conf
acl.xml
internal.db
registry.db
resources/

بررسی دوباره اجرای MTA

پس از پایان بکاپ وضعیت سرور را بررسی کنید:

sudo systemctl status mtaserver

اگر Service قبل از بکاپ فعال بوده است، باید دوباره در وضعیت active قرار گرفته باشد.

فعال‌کردن بکاپ MySQL

اگر گیم‌مود از MySQL استفاده می‌کند، مقدار زیر را در اسکریپت تغییر دهید:

MYSQL_BACKUP=1

نام دیتابیس را نیز وارد کنید:

MYSQL_DATABASE="kimia_mta"

به‌جای kimia_mta نام واقعی دیتابیس پروژه را قرار دهید.

رمز MySQL را داخل اسکریپت ننویسید

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

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

sudo nano /root/.my.cnf

محتوا:

[client]
host=127.0.0.1
user=kimia_mta_user
password=CHANGE-THIS-PASSWORD

سپس دسترسی فایل را محدود کنید:

sudo chmod 600 /root/.my.cnf

اکنون اسکریپت می‌تواند اطلاعات اتصال را از این فایل دریافت کند.

تست دستی mysqldump

sudo mysqldump \
--defaults-extra-file=/root/.my.cnf \
--databases kimia_mta \
> /tmp/mta-test.sql

فایل خروجی را بررسی کنید:

ls -lh /tmp/mta-test.sql

پس از تأیید:

rm /tmp/mta-test.sql

مرحله پنجم: ساخت Cron Job

چون اسکریپت برای Stop و Start کردن Service به دسترسی مدیریتی نیاز دارد، Cron مربوط به root را باز کنید:

sudo crontab -e

برای اجرای روزانه ساعت ۴ صبح خط زیر را اضافه کنید:

0 4 * * * /usr/bin/flock -n /run/mta-backup.lock /usr/local/sbin/mta-backup.sh >> /var/log/mta-backup.log 2>&1

این Cron هر روز ساعت 04:00 اسکریپت را اجرا می‌کند و خروجی را در فایل mta-backup.log ثبت می‌کند.

flock در Cron چه کاربردی دارد؟

flock کمک می‌کند اگر یک عملیات بکاپ هنوز تمام نشده است، نسخه دوم همان Job هم‌زمان شروع نشود.

فایل Lock این مثال:

/run/mta-backup.lock

ساختار زمان‌بندی Cron

MINUTE HOUR DAY MONTH WEEKDAY COMMAND

برای نمونه:

0 4 * * *

یعنی اجرای Job در دقیقه صفر ساعت چهار هر روز.

نمونه زمان‌بندی‌های دیگر

زمان‌بندی	Cron
هر روز ساعت 04:00	0 4 * * *
هر روز ساعت 06:30	30 6 * * *
هر 12 ساعت	0 /12 * *
هر یکشنبه ساعت 05:00	0 5 * * 0
اول هر ماه ساعت 03:00	0 3 1 * *

برای گیم‌سروری که اطلاعات آن مرتب تغییر می‌کند، بکاپ روزانه معمولاً نقطه شروع مناسب‌تری از بکاپ هفتگی است.

مشاهده Cronهای ثبت‌شده

sudo crontab -l

باید خط mta-backup.sh را در خروجی مشاهده کنید.

بررسی اجرای Cron

Log اختصاصی اسکریپت را مشاهده کنید:

sudo tail -f /var/log/mta-backup.log

برای مشاهده صد خط آخر:

sudo tail -n 100 /var/log/mta-backup.log

بررسی فضای مصرف‌شده بکاپ‌ها

du -sh /home/mta/backups

برای مشاهده حجم هر Backup:

du -sh /home/mta/backups/*

بررسی فضای خالی VPS

df -h

اگر پارتیشن سرور به فضای خالی کمی رسیده است، تعداد بکاپ‌های نگهداری‌شده و حجم Resourceها را بررسی کنید.

چرا بکاپ را فقط روی همان VPS نگه نداریم؟

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

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

چه بکاپ‌هایی را خارج از VPS نگهداری کنیم؟

آخرین بکاپ روزانه
یک یا چند بکاپ هفتگی
بکاپ قبل از بروزرسانی MTA
بکاپ قبل از تغییر گیم‌مود
بکاپ قبل از تغییر دیتابیس
نسخه پایدار قبل از تغییرات بزرگ پروژه

بکاپ قبل از بروزرسانی MTA

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

sudo /usr/local/sbin/mta-backup.sh

سپس وجود فایل بکاپ را تأیید و بعد عملیات بروزرسانی را آغاز کنید.

روش کامل بروزرسانی در مقاله آموزش بروزرسانی سرور MTA در لینوکس توضیح داده شده است.

بازیابی فایل‌های MTA از بکاپ

قبل از Restore، از وضعیت فعلی سرور نیز بکاپ بگیرید. بازیابی اشتباه می‌تواند تغییرات جدیدتر را بازنویسی کند.

ابتدا MTA را متوقف کنید:

sudo systemctl stop mtaserver

پوشه deathmatch:

cd /home/mta/multitheftauto_linux_x64/mods/deathmatch

سپس بکاپ موردنظر را Extract کنید:

sudo tar -xzf \
/home/mta/backups/DATE-AND-TIME/mta-files.tar.gz \
-C /home/mta/multitheftauto_linux_x64/mods/deathmatch

بعد مالکیت فایل‌ها را درصورت نیاز اصلاح کنید:

sudo chown -R mta:mta \
/home/mta/multitheftauto_linux_x64

و سرور را دوباره اجرا کنید:

sudo systemctl start mtaserver

بازیابی MySQL

اگر بکاپ MySQL با اسکریپت این مقاله ساخته شده است، می‌توان فایل فشرده را مستقیماً به mysql ارسال کرد:

gunzip -c \
/home/mta/backups/DATE-AND-TIME/mysql-database.sql.gz \
| mysql --defaults-extra-file=/root/.my.cnf

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

تست بکاپ مهم‌تر از صرفاً ساختن آن است

وجود یک فایل با پسوند tar.gz یا sql.gz به‌تنهایی اثبات نمی‌کند که بازیابی کامل پروژه امکان‌پذیر است.

لیست فایل‌های داخل Archive را بررسی کنید.
حجم بکاپ را با دفعات قبلی مقایسه کنید.
خروجی اسکریپت را در Log بررسی کنید.
فایل MySQL را با gzip -t آزمایش کنید.
هر چند وقت یک‌بار Restore را روی محیط آزمایشی انجام دهید.
وجود Resourceهای اختصاصی را کنترل کنید.
وجود internal.db و acl.xml را بررسی کنید.

بررسی سلامت فایل tar.gz

tar -tzf \
/home/mta/backups/DATE-AND-TIME/mta-files.tar.gz \
> /dev/null

اگر دستور بدون Error تمام شود، ساختار Archive قابل خواندن است.

بررسی سلامت فایل MySQL فشرده

gzip -t \
/home/mta/backups/DATE-AND-TIME/mysql-database.sql.gz

خطای Permission denied در بکاپ

اگر Cron یا اسکریپت امکان خواندن فایل‌های MTA را ندارد، این موارد را بررسی کنید:

اسکریپت از root Crontab اجرا شده باشد.
مسیر MTA صحیح باشد.
فایل mta-backup.sh قابلیت اجرا داشته باشد.
پوشه Backup قابل نوشتن باشد.
Permission دیتابیس و Resourceها صحیح باشد.

خطای mysqldump: command not found

ابتدا وجود دستور را بررسی کنید:

which mysqldump

اگر خروجی نداشت، ابزار Client مربوط به MySQL یا MariaDB روی سیستم نصب نیست و باید بسته مناسب توزیع لینوکس نصب شود.

MySQL Access denied هنگام بکاپ

نام کاربری داخل /root/.my.cnf را بررسی کنید.
رمز را بررسی کنید.
Host حساب MySQL را بررسی کنید.
Permission کاربر روی دیتابیس را بررسی کنید.
نام دیتابیس داخل اسکریپت را بررسی کنید.

Cron اجرا نمی‌شود؛ چه مواردی را بررسی کنیم؟

وجود Job را با sudo crontab -l بررسی کنید.
مسیر کامل اسکریپت را استفاده کنید.
Permission اجرا را بررسی کنید.
Log فایل /var/log/mta-backup.log را بخوانید.
ساعت و Timezone VPS را بررسی کنید.
سرویس Cron سیستم را بررسی کنید.

در Ubuntu و Debian:

systemctl status cron

در بعضی توزیع‌ها نام Service ممکن است crond باشد:

systemctl status crond

بکاپ بیش‌ازحد طول می‌کشد

اگر پوشه Resourceها بسیار بزرگ است یا فایل‌های غیرضروری داخل آن نگهداری می‌شوند، عملیات فشرده‌سازی می‌تواند طولانی شود.

حجم resources را با du بررسی کنید.
فایل‌های موقت غیرضروری را حذف کنید.
Logهای بزرگ را داخل Backup اصلی قرار ندهید.
فضای I/O و دیسک VPS را بررسی کنید.
بکاپ را در ساعت کم‌ترافیک اجرا کنید.

مشاهده حجم Resourceها

du -sh \
/home/mta/multitheftauto_linux_x64/mods/deathmatch/resources

اشتباهات رایج در بکاپ سرور MTA

بکاپ گرفتن فقط از پوشه resources
فراموش‌کردن internal.db
فراموش‌کردن acl.xml
فراموش‌کردن MySQL
ذخیره تمام بکاپ‌ها فقط روی همان VPS
نداشتن سیستم حذف فایل‌های قدیمی
پر شدن دیسک به‌خاطر Backupهای قدیمی
نداشتن Log برای Cron
تست نکردن Restore
نوشتن Password دیتابیس در اسکریپت عمومی
استفاده از مسیر نسبی در Cron
بکاپ‌گیری بدون بررسی وضعیت فایل‌های دیتابیس

چک‌لیست بکاپ خودکار MTA

مسیر MTA در اسکریپت صحیح است.
مسیر Backup ساخته شده است.
mtaserver.conf داخل بکاپ است.
acl.xml داخل بکاپ است.
internal.db داخل بکاپ است.
registry.db داخل بکاپ است.
resources داخل بکاپ است.
MySQL درصورت استفاده فعال شده است.
اطلاعات MySQL خارج از اسکریپت نگهداری می‌شود.
اسکریپت دستی با موفقیت اجرا شده است.
Cron ثبت شده است.
Log اجرای Cron وجود دارد.
بکاپ‌های قدیمی حذف می‌شوند.
فضای دیسک بررسی می‌شود.
نسخه‌ای خارج از VPS نگهداری می‌شود.
Restore آزمایشی انجام شده است.

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

مشخص کنید چه اطلاعاتی باید بکاپ شوند.
پوشه Backup را ایجاد کنید.
اسکریپت mta-backup.sh را بسازید.
مسیر نصب MTA را اصلاح کنید.
مدت نگهداری Backup را مشخص کنید.
MySQL را درصورت نیاز فعال کنید.
اسکریپت را قابل اجرا کنید.
یک Backup دستی بگیرید.
Archive را بررسی کنید.
وضعیت MTA را بعد از Backup بررسی کنید.
Cron را ثبت کنید.
Log اجرای خودکار را کنترل کنید.
فضای دیسک را مرتب بررسی کنید.
نسخه‌ای از Backup را خارج از VPS نگهداری کنید.
Restore را در محیط آزمایشی تست کنید.

جمع‌بندی

برای بکاپ خودکار سرور MTA در لینوکس می‌توان یک اسکریپت Bash ساخت و اجرای آن را با Cron زمان‌بندی کرد.

یک بکاپ کامل MTA فقط شامل Resourceها نیست؛ mtaserver.conf، acl.xml، internal.db، registry.db و در پروژه‌های متصل به MySQL، دیتابیس خارجی نیز باید در برنامه پشتیبان‌گیری قرار بگیرند.

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

برای اجرای MTA به‌صورت Service، مقاله آموزش اجرای خودکار سرور MTA با systemd در لینوکس را مطالعه کنید.

برای بروزرسانی امن نیز راهنمای آموزش بروزرسانی سرور MTA در لینوکس را ببینید.

اگر پروژه از MySQL استفاده می‌کند، مقاله آموزش اتصال سرور MTA به MySQL و رفع خطاهای دیتابیس را بررسی کنید.

برای بررسی Backup، دیتابیس و زیرساخت پروژه می‌توانید از خدمات پشتیبانی فنی گیم‌سرور و راه‌اندازی و کانفیگ سرور MTA استفاده کنید.

پرسش‌های متداول

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

بازه مناسب به میزان تغییر اطلاعات پروژه بستگی دارد. برای بسیاری از سرورهای فعال، بکاپ روزانه نقطه شروع مناسبی است و قبل از تغییرات مهم نیز بهتر است Backup دستی گرفته شود.

آیا بکاپ پوشه resources کافی است؟

خیر. تنظیمات، ACL، internal.db، registry.db و دیتابیس خارجی پروژه نیز ممکن است برای بازیابی کامل سرور لازم باشند.

حساب‌های MTA در کدام فایل قرار دارند؟

حساب‌های داخلی MTA و Account Data در فایل internal.db نگهداری می‌شوند.

آیا Cron می‌تواند بکاپ MTA را خودکار اجرا کند؟

بله. پس از آزمایش اسکریپت می‌توان آن را در Crontab ثبت کرد تا در ساعت مشخص به‌صورت خودکار اجرا شود.

چگونه از پر شدن دیسک توسط بکاپ‌ها جلوگیری کنیم؟

برای Backupها مدت نگهداری تعریف کنید و فایل‌های قدیمی را به‌صورت خودکار حذف کنید. فضای آزاد VPS نیز باید مرتب بررسی شود.

آیا باید MySQL را جداگانه بکاپ بگیریم؟

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

چگونه بفهمیم بکاپ سالم است؟

Archive را با tar -tzf و فایل فشرده MySQL را با gzip -t بررسی کنید و به‌صورت دوره‌ای Restore آزمایشی انجام دهید.