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

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

اگر روی یک هاست یا سرور دایرکت ادمین کار می‌کنید، همهٔ ابزار لازم را از قبل دارید. بکاپ گرفتن در دایرکت ادمین هم می‌تواند دستی و همان لحظه انجام شود و هم زمان‌بندی‌شده و خودکار. در ادامه سه کار را کامل انجام می‌دهیم: زمان‌بندی خودکار بکاپ همهٔ اکانت‌ها و بازگردانی آن‌ها، یک اسکریپت جداگانه برای بکاپ همهٔ دیتابیس‌های MySQL، و وارد کردن بکاپ سی‌پنل به سرور دایرکت ادمین.

بکاپ خودکار از همهٔ اکانت‌ها با Admin Backup/Transfer

بکاپ گرفتن اتوماتیک از هاست در دایرکت ادمین کار پیچیده‌ای نیست و همه‌اش از یک صفحه انجام می‌شود. با کاربر admin وارد پنل شوید و سراغ Admin Backup/Transfer بروید. جای این گزینه در پوسته‌های مختلف فرق می‌کند؛ اگر پیدایش نکردید، مسیر /CMD_ADMIN_BACKUP را مستقیم در آدرس پنل باز کنید.

این صفحه دو بخش دارد: Create Backup برای ساختن بکاپ و Restore Backup برای بازگرداندن آن. فعلاً Create Backup را باز کنید.

ظاهر صفحه بین پوسته‌ها و نسخه‌های مختلف دایرکت ادمین کمی فرق دارد، اما مراحل و نام فیلدها همان است: Who (از چه کسی)، When (چه زمانی) و Where (کجا ذخیره شود).

گام Who: از کدام اکانت‌ها بکاپ گرفته شود

برای بکاپ کامل سرور گزینهٔ All Users را انتخاب کنید تا از تمام اکانت‌ها بکاپ گرفته شود. اگر فقط چند اکانت خاص مدنظرتان است، Selected Users را بزنید و از فهرست انتخاب کنید. گزینهٔ «همهٔ کاربران به‌جز موارد انتخاب‌شده» هم وجود دارد که برای کنار گذاشتن یکی دو اکانت خیلی حجیم به کار می‌آید.

گام When: همین حالا یا طبق زمان‌بندی

دو حالت دارید. اگر Now را انتخاب کنید، کار بلافاصله در صف اجرای دایرکت ادمین قرار می‌گیرد و در پس‌زمینه انجام می‌شود؛ پس اگر بلافاصله فایلی ندیدید نگران نشوید، بکاپ گرفتن از یک سرور پر می‌تواند ده‌ها دقیقه طول بکشد.

برای بکاپ خودکار، گزینهٔ Cron Schedule را فعال کنید. آن‌وقت فیلدهای استاندارد کران در اختیارتان قرار می‌گیرد: Minute، Hour، Day of Month، Month و Day of Week.

اینجا یک نکته هست که در بسیاری از راهنماهای قدیمی فارسی اشتباه نوشته شده و باید تصحیح شود: برای بکاپ روزانه نباید در Day of Month عدد ۱ بگذارید. عدد ۱ در این فیلد یعنی «روز اول هر ماه»، یعنی ماهی یک بار، نه هر ۲۴ ساعت. معنی درست فیلدها این است:

• بکاپ روزانه، هر شب ساعت ۳ بامداد: Minute = 0 ، Hour = 3 ، Day of Month = * ، Month = * ، Day of Week = *
• بکاپ هفتگی، جمعه‌ها ساعت ۳ بامداد: Minute = 0 ، Hour = 3 ، Day of Month = * ، Month = * ، Day of Week = 5 (در کران شمارهٔ روزهای هفته از یکشنبه شروع می‌شود: ۰ یکشنبه، ۱ دوشنبه، ۲ سه‌شنبه، ۳ چهارشنبه، ۴ پنجشنبه، ۵ جمعه، ۶ شنبه؛ عدد ۷ هم مثل ۰ یکشنبه است)
• بکاپ ماهانه، روز اول ماه: Day of Month = 1 و Day of Week = *

نکتهٔ مهم دیگر: اگر هم‌زمان Day of Month و Day of Week را عدد بگذارید، کران این دو شرط را «و» نمی‌کند، بلکه «یا» می‌کند. یعنی اگر ۱ و ۵ بگذارید، کار هم روز اول هر ماه اجرا می‌شود و هم تمام جمعه‌ها — نه فقط جمعهٔ اول ماه. پس این تصور که «هر دو کادر را پر کنیم تا هم روزانه و هم هفتگی بکاپ بگیرد» درست نیست. برای داشتن نسخهٔ روزانه و نسخهٔ هفتگی، ساده‌ترین راه این است که بکاپ روزانه را به دایرکت ادمین بسپارید و نگه‌داری و چرخش نسخه‌های هفتگی و ماهانه را روی سرور مقصد بکاپ انجام دهید.

گام Where: ذخیره روی همان سرور یا انتقال به سرور دیگر

گزینهٔ Local بکاپ‌ها را روی خود همین سرور و در مسیری که مشخص می‌کنید نگه می‌دارد (مسیری که دایرکت ادمین پیشنهاد می‌دهد معمولاً زیر /home/admin/admin_backups است). این حالت برای بازگرداندن سریع یک اکانت که کاربرش خرابکاری کرده عالی است، ولی به‌تنهایی بکاپ حساب نمی‌شود: اگر دیسک یا کل سرور از دست برود، بکاپ‌ها هم با آن می‌روند. ضمناً حواستان به فضای دیسک باشد، چون فایل‌های بکاپ به‌سرعت پارتیشن /home را پر می‌کنند و پر شدن دیسک، خودش سرور را از کار می‌اندازد.

گزینهٔ FTP بکاپ‌ها را بعد از ساخته شدن به سرور دیگری منتقل می‌کند. باید آدرس یا IP سرور مقصد، نام کاربری، رمز، پورت و مسیر مقصد را وارد کنید. دو نکته: مسیر مقصد باید از قبل روی سرور بکاپ ساخته شده باشد و کاربر FTP اجازهٔ نوشتن در آن را داشته باشد؛ و اگر نسخهٔ دایرکت ادمین شما گزینهٔ FTP امن (FTPS) دارد، حتماً فعالش کنید، چون FTP ساده نام کاربری، رمز و کل محتوای بکاپ را رمزنگاری‌نشده روی شبکه می‌فرستد.

در نسخه‌های امروزی دایرکت ادمین، پایین همین فرم بخشی برای انتخاب محتوای بکاپ هم می‌بینید تا مشخص کنید چه بخش‌هایی از اکانت (فایل‌ها، دیتابیس‌ها، ایمیل‌ها، تنظیمات DNS و مانند آن) داخل فایل بکاپ برود. مگر اینکه دلیل روشنی داشته باشید، همه را انتخاب کنید؛ بکاپی که دیتابیس ندارد، در روز حادثه به درد نمی‌خورد.

بازگرداندن بکاپ در دایرکت ادمین

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

بازگردانی در سطح ادمین

در همان صفحهٔ Admin Backup/Transfer، تب Restore Backup را باز کنید. اول مشخص می‌کنید فایل‌های بکاپ روی همین سرور (Local) هستند یا باید از یک سرور FTP خوانده شوند، و مسیرشان را می‌دهید. بعد فهرست بکاپ‌های موجود نمایش داده می‌شود و اکانت‌های موردنظر را انتخاب می‌کنید.

اگر IP سرور مقصد با سرور مبدأ فرق دارد، در همین مرحله باید IP جدید را برای اکانت‌ها انتخاب کنید، وگرنه اکانت با IP قدیمی ساخته می‌شود. و حواستان باشد که بازگردانی روی اکانت موجود، محتوای فعلی آن را بازنویسی می‌کند؛ روی سرور زنده اول از وضعیت فعلی بکاپ بگیرید، بعد بازگردانی کنید.

بازگردانی در سطح ریسلر با Manage User Backups

وقتی یک فایل بکاپ را دستی روی سرور آورده‌اید (مثلاً از سرور دیگری کپی کرده‌اید یا خروجی تبدیل بکاپ سی‌پنل است)، مسیر استاندارد این است که فایل را در پوشهٔ user_backups ریسلر بگذارید:

mkdir -p /home/RESELLER/user_backups
mv backup-file.tar.gz /home/RESELLER/user_backups/
chown RESELLER:RESELLER /home/RESELLER/user_backups
chown RESELLER:RESELLER /home/RESELLER/user_backups/*.tar.gz

به‌جای RESELLER نام کاربری ریسلر را بگذارید. مرحلهٔ chown را جدی بگیرید: اگر مالک فایل، کاربر ریسلر نباشد، دایرکت ادمین آن را در فهرست نشان نمی‌دهد و بیشتر «چرا بکاپم دیده نمی‌شود؟»ها دقیقاً همین است.

حالا با کاربر ریسلر وارد پنل شوید، به بخش Manage User Backups بروید (مسیر مستقیمش /CMD_USER_BACKUP است)، فایل را از فهرست انتخاب کنید و بازگردانی را شروع کنید.

بکاپ جداگانه از همهٔ دیتابیس‌ها با یک اسکریپت

بکاپ کامل اکانت سنگین است و معمولاً شبی یک بار گرفته می‌شود. اما چیزی که هر ساعت تغییر می‌کند دیتابیس است، نه فایل‌های سایت. یک خروجی سبک mysqldump از همهٔ دیتابیس‌ها، هر چند ساعت یک بار، فاصلهٔ از دست رفتن داده را از یک روز به چند ساعت کاهش می‌دهد و بازگرداندن یک دیتابیس تکی را هم بسیار ساده‌تر می‌کند. این کار جایگزین بکاپ کامل نیست، مکمل آن است.

اول یک فایل اعتبارنامه بسازید

در نمونه‌های قدیمی، نام کاربری و رمز مستقیم داخل اسکریپت و روی خط فرمان نوشته می‌شد. این کار دو ایراد دارد: رمز در خروجی ps برای همهٔ کاربران سرور دیده می‌شود، و نسخه‌های امروزی MySQL و MariaDB هم بابتش هشدار می‌دهند. راه درست، یک فایل اعتبارنامه با دسترسی محدود است. اول فایل خالی را بسازید و قبل از نوشتن رمز دسترسی‌اش را ببندید، تا حتی برای چند ثانیه هم رمز دیتابیس برای بقیهٔ کاربران سرور خواندنی نباشد:

touch /root/.my.cnf
chmod 600 /root/.my.cnf

حالا فایل /root/.my.cnf را باز کنید و این محتوا را در آن بگذارید:

[client]
user=da_admin
password="رمز-کاربر-da_admin"

نام کاربری و رمز کاربر da_admin را دایرکت ادمین در فایل mysql.conf زیر مسیر /usr/local/directadmin/conf/ نگه می‌دارد. یک نکتهٔ ریز که وقت زیادی از آدم می‌گیرد: نام کلید در آن فایل passwd است، ولی در .my.cnf باید password بنویسید؛ مقدار را کپی کنید، نه نام کلید را.

اسکریپت بکاپ

این اسکریپت را در /root/db-backup.sh ذخیره کنید:

#!/bin/bash
set -uo pipefail
umask 077

# اگر mysql و mysqldump جای دیگری نصب شده‌اند، مسیرشان را اینجا اضافه کنید
PATH=/usr/local/mysql/bin:/usr/local/bin:/usr/bin:/bin

CNF=/root/.my.cnf
BASE=/home/sqlbackup
DEST="$BASE/$(date +%Y-%m-%d_%H-%M-%S)"
KEEP_DAYS=7

SKIP='^(information_schema|performance_schema|sys|mysql|da_roundcube)$'

LIST=$(mysql --defaults-extra-file="$CNF" -N -B -e 'SHOW DATABASES') || {
  echo "اتصال به MySQL ناموفق بود؛ هیچ کاری انجام نشد." >&2
  exit 1
}
LIST=$(printf '%sn' "$LIST" | grep -Ev "$SKIP") || true
[ -n "$LIST" ] || { echo "فهرست دیتابیس‌ها خالی است." >&2; exit 1; }

mkdir -p "$DEST"
chmod 700 "$DEST"

FAILED=0
while read -r db; do
  mysqldump --defaults-extra-file="$CNF" 
    --single-transaction --quick --routines 
    "$db" | gzip > "$DEST/$db.sql.gz" 
    || { echo "خطا در دامپ $db" >&2; FAILED=1; }
done <<< "$LIST"

# فقط اگر بکاپ این نوبت کامل موفق بود، نسخه‌های قدیمی حذف شوند
if [ "$FAILED" -eq 0 ]; then
  find "$BASE" -mindepth 1 -maxdepth 1 -type d -mtime +"$KEEP_DAYS" -exec rm -rf {} +
else
  echo "به دلیل خطا، پاک‌سازی نسخه‌های قدیمی انجام نشد." >&2
  exit 1
fi

چند نکته دربارهٔ تفاوت‌های این نسخه با اسکریپت‌های قدیمی که در اینترنت می‌بینید:

• در نسخه‌های قدیمی دیتابیس‌های سیستمی با grep -v mysql کنار گذاشته می‌شدند. این خطرناک است، چون هر دیتابیسی که کلمهٔ mysql در نامش باشد (مثلاً user_mysqldata یکی از مشتریان) هم از بکاپ حذف می‌شود. اینجا با الگوی ^(...)$ فقط نام‌های دقیق کنار گذاشته می‌شوند.
• علاوه بر information_schema و mysql و da_roundcube، دیتابیس‌های performance_schema و sys هم کنار گذاشته شده‌اند. این‌ها در نسخه‌های جدید MySQL و MariaDB وجود دارند، دامپ‌شان معنایی ندارد و معمولاً خطا هم می‌دهد.
• --single-transaction باعث می‌شود از جدول‌های InnoDB خروجی سازگار گرفته شود بدون اینکه سایت در حین بکاپ قفل شود. اگر هنوز جدول MyISAM دارید، این گزینه برای آن‌ها سازگاری تضمین نمی‌کند.
• umask 077 در ابتدای اسکریپت باعث می‌شود فایل‌های خروجی از همان لحظهٔ ساخته شدن فقط برای root خواندنی باشند. این مهم‌تر از آن است که به نظر می‌رسد: اگر بعد از پایان کار دسترسی را ببندید، در تمام مدتی که دامپ در حال نوشته شدن است، دادهٔ کامل مشتریان شما روی یک سرور اشتراکی برای همهٔ کاربران خواندنی بوده است.
• مهم‌ترین تفاوت، رفتار خط پاک‌سازی است. در نمونه‌های رایج، حذف نسخه‌های قدیمی بی‌قید و شرط اجرا می‌شود؛ یعنی اگر رمز da_admin عوض شده باشد و اتصال شکست بخورد، اسکریپت بدون گرفتن هیچ بکاپی، بکاپ‌های سالم قبلی را هم پاک می‌کند و شما تازه یک هفته بعد متوجه می‌شوید. اینجا اگر اتصال یا حتی دامپ یک دیتابیس شکست بخورد، هیچ چیزی حذف نمی‌شود و اسکریپت با کد خطا تمام می‌شود.
• دقت کنید که -mtime +7 یعنی پوشه‌هایی که بیش از ۷ شبانه‌روز کامل از آخرین تغییرشان گذشته؛ عملاً حدود ۸ نسخهٔ روزانه نگه داشته می‌شود. اگر اصلاً نمی‌خواهید چیزی خودکار پاک شود، کل بلوک if انتهایی را بردارید.

زمان‌بندی اسکریپت

اسکریپت را اجرایی کنید و یک بار دستی اجرا کنید تا از سالم بودن خروجی مطمئن شوید:

chmod 700 /root/db-backup.sh
/root/db-backup.sh
ls -lh /home/sqlbackup/*/

بعد با crontab -e این خط را اضافه کنید تا هر ۶ ساعت اجرا شود:

0 */6 * * * /root/db-backup.sh >> /var/log/db-backup.log 2>&1

و در نهایت، این پوشه را هم مثل بقیهٔ بکاپ‌ها از سرور خارج کنید؛ خروجی‌ای که کنار خود دیتابیس روی همان دیسک مانده، در سناریوی از دست رفتن سرور هیچ کمکی نمی‌کند. یک rsync شبانه به سرور بکاپ یا همان مقصد FTP، این مشکل را حل می‌کند.

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

فرمت بکاپ سی‌پنل و دایرکت ادمین یکی نیست، بنابراین نمی‌شود فایل cpmove را مستقیم در Restore Backup داد. باید اول آن را تبدیل کرد و بعد مثل یک بکاپ عادی دایرکت ادمین بازگرداند.

گام ۱: گرفتن بکاپ روی سرور سی‌پنل

با کاربر root از طریق SSH وارد سرور سی‌پنل شوید و برای اکانت موردنظر بکاپ بگیرید:

/usr/local/cpanel/scripts/pkgacct username

به‌جای username نام کاربری اکانت را بنویسید. در راهنماهای قدیمی این دستور به شکل /scripts/pkgacct نوشته می‌شد؛ /scripts هنوز پیوندی به /usr/local/cpanel/scripts است و کار می‌کند، اما نوشتن مسیر کامل مطمئن‌تر است. همچنین لازم نیست قبلش cd /home کنید؛ محل ساخته شدن خروجی به دایرکتوری جاری ربطی ندارد. خروجی معمولاً در /home و با نامی شبیه cpmove-username.tar.gz ساخته می‌شود؛ مسیر دقیق را در خطوط پایانی خروجی خود دستور می‌بینید، پس آنجا را بخوانید و حدس نزنید. اگر می‌خواهید جای مشخصی ساخته شود، مسیر را به‌عنوان آرگومان دوم بدهید (این مسیر باید از قبل وجود داشته باشد و فضای کافی هم داشته باشد):

/usr/local/cpanel/scripts/pkgacct username /backup

حالا این فایل را با scp یا rsync به سرور دایرکت ادمین منتقل کنید.

گام ۲: تبدیل بکاپ روی سرور دایرکت ادمین

با کاربر root وارد SSH سرور دایرکت ادمین شوید و بستهٔ تبدیل را دانلود و باز کنید:

cd /root
wget https://blog.onlineserver.ir/wp-content/uploads/2017/05/cp2da.tar.gz
tar -xzf cp2da.tar.gz

داخل این بسته دو فایل هست: da.cpanel.import.pl و defaults.conf. حالا:

• فایل cpmove-username.tar.gz را داخل پوشهٔ import کپی کنید (اگر این پوشه وجود ندارد، خودتان بسازید).
• فایل defaults.conf را ویرایش کنید و IP و نیم‌سرورهای سرور جدید را در آن بنویسید. اگر اینجا مقدار اشتباه بگذارید، اکانت با IP و نیم‌سرور غلط ساخته می‌شود و باید بعداً دستی اصلاحش کنید.
• اسکریپت را اجرا کنید:

perl da.cpanel.import.pl

بعد از پایان کار، فایل بکاپ با ساختار دایرکت ادمین داخل پوشهٔ export ساخته می‌شود.

یک هشدار صادقانه: این مبدل قدیمی است و برای بکاپ‌های سی‌پنل همان دوره نوشته شده. اگر بکاپ شما از نسخه‌ای خیلی جدیدتر گرفته شده، ممکن است بعضی بخش‌ها (مثلاً برخی تنظیمات ایمیل، فیلترها یا رکوردهای DNS) کامل منتقل نشوند. پیش از مهاجرت اکانت اصلی، یک اکانت آزمایشی را کامل ببرید و نتیجه را بررسی کنید، و مستندات جاری دایرکت ادمین دربارهٔ مهاجرت را هم ببینید، چون ابزارهای رسمی مهاجرت به‌مرور به‌روزتر شده‌اند.

گام ۳: بازگرداندن اکانت تبدیل‌شده

فایل داخل پوشهٔ export را به مسیر /home/RESELLER/user_backups منتقل کنید، مالکیتش را با chown به ریسلر بدهید و از بخش Manage User Backups در سطح ریسلر بازگردانی کنید — دقیقاً همان کاری که در بخش بازگردانی توضیح داده شد.

بعد از بازگردانی، این موارد را جداگانه بررسی کنید: نسخهٔ PHP سایت (اکانت‌های قدیمی سی‌پنل معمولاً روی نسخه‌های قدیمی PHP بوده‌اند)، رکوردهای DNS و نیم‌سرورها، رسیدن و ارسال ایمیل، کران‌جاب‌ها و گواهی SSL. و تا وقتی سایت روی سرور جدید کامل سالم بالا نیامده، اکانت را روی سرور قدیمی پاک نکنید.

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

چند نکته که بکاپ را واقعاً قابل‌اتکا می‌کند

• یک بار بازگردانی آزمایشی بگیرید. هر چند وقت یک بار یک بکاپ را روی یک اکانت تستی برگردانید. تنها راه فهمیدن اینکه بکاپ سالم است همین است، و بهتر است این را در یک روز آرام بفهمید نه وسط بحران.
• حداقل یک نسخه بیرون از سرور باشد. بکاپ Local و سرور اصلی، یک نقطهٔ شکست مشترک دارند.
• چند نسخه نگه دارید. اگر فقط آخرین بکاپ را داشته باشید و مشکل (مثلاً آلودگی سایت) از سه روز پیش شروع شده باشد، بکاپ شما هم آلوده است.
• مسیر بکاپ را داخل پوشهٔ خانگی هیچ کاربر هاستینگی نگذارید. وگرنه بکاپ‌ها هم داخل بکاپ بعدی همان کاربر می‌روند و خود کاربر هم به آن‌ها دسترسی دارد. (مسیر پیش‌فرض /home/admin/admin_backups از این نظر ایرادی ندارد، چون admin کاربر مدیریتی سرور است نه یک اکانت مشتری؛ حرف ما دربارهٔ اکانت‌های کاربران است.)
• فضای دیسک را رصد کنید. با df -h /home قبل و بعد از فعال کردن بکاپ خودکار وضعیت را بسنجید. پر شدن دیسک، رایج‌ترین دلیل شکست بی‌سروصدای بکاپ‌هاست.

وقتی بکاپ اجرا نمی‌شود

• سرویس کران را بررسی کنید. روی AlmaLinux و Rocky Linux با systemctl status crond و روی Debian و Ubuntu با systemctl status cron. دستور قدیمی service crond status روی توزیع‌های امروزی معمولاً به همان systemctl هدایت می‌شود و کار می‌کند، اما شکل استاندارد امروز systemctl است و خروجی کامل‌تری هم می‌دهد. در عوض /etc/init.d/crond روی این توزیع‌ها دیگر وجود ندارد.
• سرویس دایرکت ادمین: اگر لازم شد آن را راه‌اندازی مجدد کنید، شکل درست امروزی systemctl restart directadmin است. توجه کنید که ری‌استارت دایرکت ادمین کارهای در حال اجرای صف (از جمله بکاپی که نیمه‌کاره است) را قطع می‌کند، پس وسط یک بکاپ بزرگ این کار را نکنید.
• لاگ‌ها را بخوانید. لاگ‌های دایرکت ادمین زیر /var/log/directadmin/ هستند و دلیل شکست بکاپ معمولاً همان‌جا نوشته شده است.
• خطای FTP: بررسی کنید مسیر مقصد روی سرور بکاپ واقعاً وجود داشته باشد و کاربر FTP اجازهٔ نوشتن در آن را داشته باشد.
• فایل در سطح ریسلر دیده نمی‌شود: مالکیت فایل و پوشهٔ user_backups را با chown به کاربر ریسلر بدهید.
• سیستم‌عامل قدیمی: اگر هنوز روی CentOS 6 یا CentOS 7 هستید، هر دو به پایان پشتیبانی رسیده‌اند و دیگر به‌روزرسانی امنیتی نمی‌گیرند. برنامهٔ مهاجرت به AlmaLinux یا Rocky Linux (یا Debian/Ubuntu) را جدی بگیرید. حواستان به فرق ابزارها باشد: روی AlmaLinux و Rocky Linux مدیریت بسته با dnf انجام می‌شود (نه yum)، ولی روی Debian و Ubuntu ابزار درست apt است و dnf اصلاً وجود ندارد.

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