مقایسهٔ کامل افزونههای بکاپ وردپرس؛ کدام برای شما مناسب است؟
- افزونه بکاپ وردپرس را با چه منطقی مقایسه کنیم؟
- کلاس اول؛ پوشش کامل سایت یا فقط دیتابیس
- کلاس دوم؛ مقصد ذخیره، همان سرور یا بیرون از آن
- کلاس سوم؛ نسخهٔ کامل، افزایشی و ریتم زمانبندی
- جدول تصمیم؛ کدام ترکیب برای کدام سایت
- آزمون بازگردانی؛ معیاری که مقایسه را تمام میکند
- هزینهها؛ چه چیزی واقعاً پول میبرد؟
- جمعبندی؛ انتخاب بر اساس اندازهٔ سایت
نسخهٔ پشتیبان تنها چیزی است که تا روز حادثه، هیچکس به اندازهٔ کافی دربارهاش فکر نمیکند. وردپرس حدود ۴۳٪ کل سایتهای وب را پشتیبانی میکند (W3Techs، تاریخ گردآوری: آبان ۱۴۰۵) و سهم بزرگی از همین سایتها، نسخهای دارند که هرگز بازگردانی نشده یا اصلاً بیرون از سرور نمیرود. مقایسهٔ درست افزونهٔ بکاپ از همینجا شروع میشود؛ نه با رتبهبندی فروشگاه افزونه، با فهم کلاسها.
چرا مقایسهٔ ناممحور را کنار گذاشتهایم؟ چون فروشندهها عوض میشوند، پلنها تغییر میکنند و ویژگیهای تبلیغشده در نسخههای مختلف جابهجا میشود؛ ولی کلاسها ثابت میمانند. این مقایسه کنار دو همخانوادهٔ خودش معنا دارد: آموزش گامبهگام ایمنسازی صفحه ورود وردپرس لایهٔ پیشگیری است و بکاپ لایهٔ آخر همان زنجیره؛ بقیهٔ انتخابهای افزونهای هم در هاب افزونهها و قالبها جمع است. اگر به وضعیت امروز دامنهتان شک دارید، ممیزی رایگان دامنه را قبل از انتخاب افزونه اجرا کنید.
افزونه بکاپ وردپرس را با چه منطقی مقایسه کنیم؟

بازار افزونههای بکاپ با سه سؤال شکل میگیرد و هر افزونه در واقع یک جواب از هر سؤال است. سؤال اول: چه چیزی ذخیره میشود؛ کل سایت یا فقط دیتابیس؟ سؤال دوم: کجا ذخیره میشود؛ روی همان سرور یا بیرون از آن؟ سؤال سوم: چگونه ذخیره میشود؛ در هر بار یک نسخهٔ کامل، یا نسخهٔ افزایشی از تغییرات؟ جواب این سه سؤال، کلاس افزونه را میسازد و کلاس است که باید با سناریوی سایت شما خوانده شود.
با این منطق، دو افزونهای که در فهرستهای مقایسه کنار هم نشستهاند، ممکن است کلاسهای متفاوتی باشند و مقایسهشان بیمعنا؛ و دو افزونهٔ متفاوت از دو فروشنده، ممکن است دقیقاً یک کلاس باشند و انتخاب بینشان به جزئیات اجرا برگردد. سه بخش بعدی هر تفکیک را با معنی عملیاش باز میکند و در پایان، جدول تصمیم سناریوها را میبندد. این نگاه کلاسمحور یک فایدهٔ دیگر هم دارد: وقتی فروشنده تغییر کرد یا پلنش جابهجا شد، معیارهای شما سر جایشان میمانند و مهاجرت بین ابزارها فقط جابهجایی کلاس است، نه از نو فکر کردن.
کلاس اول؛ پوشش کامل سایت یا فقط دیتابیس
پوشش کامل یعنی فایلها و دیتابیس با هم: قالب و افزونهها و تصاویر آپلودی در یک سمت، محتوا و تنظیمات و کاربران و سفارشها در سمت دیگر. بازگردانی از نسخهٔ کامل، سایت را همانطور که بود برمیگرداند و برای حادثههای بزرگ — هک، خرابی دیسک، بازطراحی شکسته — تنها جواب کامل است. هر سایتی، در هر اندازه، به نسخهٔ کامل نیاز دارد؛ اختلاف فقط در ریتم آن است. سنجهٔ عملی برای تشخیص نیاز، فهرست چیزهایی است که روزانه عوض میشوند؛ اگر فقط محتوا و سفارشها میچرخند سهم دیتابیس پررنگ است و اگر قالب و افزونهها هم در دست ساختاند، سهم فایلها.
پوشش فقط دیتابیس سبکتر است و برای سایتهایی که فایلهایشان کم تغییر میکند، بهعنوان لایهٔ پرتکرار جا دارد؛ ولی دقت کنید قالب و افزونهها مدام آپدیت میشوند و هر آپدیت، فایلها را هم تغییر میدهد. اگر نسخهٔ دیتابیس با فایلهای روز ناسازگار شود، بازگردانی ناتمام میماند. قاعدهٔ ما ساده است: نسخهٔ کامل را پایهٔ چرخه بگذارید و نسخهٔ دیتابیس را لایهٔ پرتکرارِ داخل همان چرخه؛ این دو جایگزین هم نیستند و سهم هر یک از ریتم تغییر سایت شما درمیآید.
کلاس دوم؛ مقصد ذخیره، همان سرور یا بیرون از آن
مقصد ذخیره، تفکیکی است که بیشتر سایتها اشتباه میگیرند. نسخهای که کنار خود سایت روی همان سرور میماند، برای بازگشت از اشتباهات روزمره — ویرایش اشتباه، آپدیت خراب — سریع و کافی است؛ ولی در حادثهٔ سرور، با خود سرور میسوزد. هک، خرابی دیسک و گاهی اشتباه خود کاربر در پاکسازی، هر سه دقیقاً همانجا رد میشوند و نسخهٔ محلی را هم با خود میبرند. از خودتان بپرسید اگر همین امشب سرور در دسترس نباشد، چه چیزی از دست میرود و از کجا برمیگردد؛ جواب همین سؤال، تصمیم مقصد دوم را میسازد.
مقصد بیرونی دو شکل سنجیده میشود: سرویس ابری یا فضای روی یک سرور و دامنهٔ دیگرِ خودتان. در بازار ایران یک واقعیت را هم روی میز بگذارید: به تجربهٔ ما، دسترسپذیری برخی سرویسهای ابری خارجی از شبکههای داخل کشور نوسان دارد؛ پس مقصد بیرونی را یا داخلی انتخاب کنید یا پیش از خرید مطمئن شوید مسیر بازیابیاش در روز مبادا باز میماند. قاعدهٔ ثابت ما دو مقصد مستقل است؛ یکی نزدیک برای سرعت بازگردانی، یکی دور برای روز حادثه.
کلاس سوم؛ نسخهٔ کامل، افزایشی و ریتم زمانبندی
نسخهٔ کامل هر بار کل سایت را بستهبندی میکند؛ ساده، قابلاتکا و سنگین. نسخهٔ افزایشی فقط تغییرات از آخرین نسخه را میگیرد؛ سبک و منظم، ولی وابسته به زنجیرهٔ نسخههای قبلی — اگر حلقهای از زنجیره خراب باشد، بازگردانی کامل در خطر است. برای همین نسخهٔ افزایشی را فقط وقتی انتخاب کنید که ریتم تغییرات سنگین است و افزونه، آزمون بازگردانی چرخهاش را پاس کرده باشد؛ حرف آخر را بخش ششم میزند.
ریتم زمانبندی را از ریتم تغییر سایت بسازید، نه از تنظیمات پیشفرض. فروشگاه با سفارش لحظهای، دیتابیس را روزانه یا هر چند ساعت میخواهد؛ بلاگ کمتغییر با هفتگی جلو میرود و نسخهٔ کامل فایلها را ماهانه یا بعد از هر آپدیت قالب بگیرد. یادتان باشد بکاپ خودش روی منابع هاست بار میگذارد؛ روی هاست اشتراکی ساعت اجرا را به ساعات خلوت بگذارید و فایلهای موقتی و کش را از بستهبندی خارج کنید تا بستهها تمیز و سبک بمانند و خود فرایند بکاپ، سنگینتر از سودی که میدهد نشود.
جدول تصمیم؛ کدام ترکیب برای کدام سایت
حالا سه تفکیک را کنار هم میگذاریم و برای چهار سناریوی رایج، ترکیب پیشفرض پیشنهاد میدهیم. این ترکیبها نقطهٔ شروع انتخاباند، نه نسخهٔ ثابت؛ با ریتم تغییر خودتان تنظیمشان کنید.
| سناریو | ترکیب پیشنهادی | ریتم پیشنهادی | مرز و هشدار |
|---|---|---|---|
| بلاگ کمتغییر | نسخهٔ کامل + یک مقصد بیرونی | هفتگی کامل؛ ماهانه فایلها | پوشهٔ آپلودها را از بستهبندی خارج نکنید |
| فروشگاه ووکامرس | دیتابیس افزایشی + کامل هفتگی + دو مقصد | دیتابیس روزانه یا چند ساعت | پنجرهٔ بکاپ را کوتاه بگیرید تا سفارشها کامل بمانند |
| سایت شرکتی چندنویسنده | نسخهٔ کامل + مقصد ابری | روزانه دیتابیس؛ هفتگی کامل | پیش از هر آپدیت قالب، یک نسخهٔ دستی هم بگیرید |
| سایت در مهاجرت یا بازطراحی | کاملِ دستی قبل از هر تغییر + خودکار هفتگی | قبل و بعد از هر مرحله | بدون آزمون بازگردانی وارد مرحلهٔ بعد نشوید |
ترکیبها با کمهزینهترین کلاسِ قابلاتکا نوشته شدهاند؛ اگر تغییرات شما سنگینتر است، ریتم را فشردهتر کنید. مرز هر ردیف را قبل از حادثه تست کنید، نه بعد از آن.
یک ستون پنهان هم در همین جدول است: سند نسخهها. برای هر نسخه، تاریخ، کلاس و مقصد را ثبت کنید تا در روز حادثه بدانید آخرین نسخهٔ سالم کجاست. سندی که در سه ثانیه خوانده شود، در روز مبادا بیشتر میارزد تا گزارشهای مفصل.
آزمون بازگردانی؛ معیاری که مقایسه را تمام میکند

مقایسهٔ افزونهها با یک معیار تمام میشود: نسخهای که بازگردانی نشده، نسخه نیست. افزونهها در بکاپگیری نزدیک هماند و در بازگردانی از هم جدا میشوند؛ برای همین قبل از تعهد به هر ابزاری، یک چرخهٔ کامل بکاپ و بازگردانی در محیط آزمایشی اجرا کنید. محیط آزمایشی میتواند زیردامنهای جدا باشد؛ مهم این است که بیرون از سایت اصلی باشد و خرابیاش هیزم حادثهٔ تازه نشود.
سه سنجهٔ موفقیت آزمون را از قبل بنویسید: سایت بالا میآید؛ یک سفارش یا فرم آزمایشی واقعاً ثبت میشود؛ و دادههای تازهٔ بعد از تاریخ نسخه، سر جای درستشان هستند. اگر یکی از این سه شکست خورد، مشکل یا در تنظیمات افزونه است یا در ناسازگاری نسخهٔ دیتابیس با فایلهای روز؛ هر دو را قبل از حادثه فهمیدن بهتر است. عیبیابی بعد از بازگردانی ناقص را هم خانوادهٔ نگهداری باز کرده است: آموزش گامبهگام خطای اتصال دیتابیس وردپرس و آموزش گامبهگام صفحهٔ سفید وردپرس.
آزمون را هر فصل و بعد از هر تغییر بزرگ تکرار کنید؛ افزونهها آپدیت میشوند و رفتار بازگردانی با آپدیت عوض میشود. تقویم ثابت آزمون، تنها چیزی است که در روز حادثه اعتماد میسازد و انتخاب شما را از حدس به سند تبدیل میکند.
هزینهها؛ چه چیزی واقعاً پول میبرد؟
هزینهٔ کلاسها را با «بازهٔ برآورد بازار» ببینید، نه قیمت قطعی؛ سه جزء اصلی فاکتورند: فضای ذخیرهسازی بیرونی، اشتراک نسخهٔ پرداختی افزونه و زمان تیم. برای سایت کوچک، به تجربهٔ ما ترکیب افزونهٔ رایگان با یک مقصد بیرونی کمحجم معمولاً سبکترین فاکتور را میسازد و برای فروشگاههای پرتغییر، هزینهٔ اصلی روی فضای ابری و نسخههای افزایشی جمع میشود؛ عدد دقیق به حجم و ریتم شما بستگی دارد و باید با استعلام بسته شود.
به تجربهٔ ما گرانترین نسخهٔ پشتیبان، نسخهای است که در روز حادثه بازنگردد؛ چون کل هزینهٔ تولید محتوا و سفارشهای از دست رفته را یکجا میسوزاند. پس بودجه را اول به مقصد بیرونی و آزمون بازگردانی برسانید و بعد سراغ امکانات جانبی افزونه بروید. این ترتیب، بیشترین پوشش را به ازای هر تومان میدهد و از پرداخت برای قابلیتهای بیاستفاده جلوگیری میکند.
زمان تیم را هم واقعی حساب کنید؛ بکاپ دستی هفتگی برای یک سایت کوچک ده دقیقه است و برای یک فروشگاه، نیم ساعت کاری با چکلیست. هر جا زمانِ تکرارشونده بالا رفت، خودکارسازی زمانبندیشده ارزانتر تمام میشود و خطای فراموشی را هم حذف میکند.
جمعبندی؛ انتخاب بر اساس اندازهٔ سایت
انتخاب را از اندازه و ریتم تغییر سایت شروع کنید: بلاگ کمتغییر با نسخهٔ کامل هفتگی و یک مقصد بیرونی جلو میرود؛ فروشگاه با دیتابیس پرتکرار، نسخهٔ افزایشی و دو مقصد؛ و هر سایتی که در آستانهٔ بازطراحی یا مهاجرت است، قبل از هر چیز به نسخهٔ کامل دستی نیاز دارد. سه تفکیک را روی کاغذ بنویسید و بعد سراغ فروشندهها بروید؛ آنوقت مقایسهٔ افزونهها ساده میشود، چون فقط بین کلاسهای همگروه انتخاب میکنید.
اگر چرخهٔ محتوایی و فنی سایت را یکجا میخواهید، قابلیتهای پلتفرم نشان میدهد انتشار امن و پایش چگونه در یک ریتم میافتد. بکاپ، بیمهٔ همهٔ کارهای سئو است؛ محتوایی که با زحمت رتبه گرفته، بدون نسخهٔ سالم فقط یک آپدیت با صفر فاصله دارد.
سه پرسش کوتاه برای جمعبندی انتخاب: آخرین نسخهٔ سالم کجاست و چه تاریخی دارد؟ اگر امروز همهچیز از دست برود، چند ساعت تا بازگشت فاصله است؟ و آخرین آزمون بازگردانی کی بوده است؟ اگر جواب هر سه روی یک برگه بنشیند، انتخاب افزونه تمام است؛ بقیه اجراست.
رصد ما، رشد شما.
سؤالات پرتکرار
بکاپ روی همان هاست کافی است؟
برای بازگشت از اشتباهات روزمره بله، برای حادثهٔ سرور خیر. قاعدهٔ ما دو مقصد مستقل است؛ یکی نزدیک برای سرعت بازگردانی و یکی بیرون از سرور برای روزی که خود سرور در دسترس نباشد.
هر چند وقت یکبار بکاپ بگیریم؟
با ریتم تغییر بسنجید؛ فروشگاه با سفارش لحظهای دیتابیس را روزانه میخواهد و بلاگ کمتغییر با هفتگی جلو میرود. نسخهٔ کامل فایلها را هم ماهانه یا بعد از هر آپدیت قالب بگیرید.
افزونهٔ رایگان کافی است یا باید نسخهٔ پولی بخریم؟
برای بیشتر سایتهای کوچک، نسخهٔ رایگان با زمانبندی و مقصد بیرونی کافی است؛ پول وقتی میارزد که به نسخهٔ افزایشی، مقاصد بیشتر یا پشتیبانی نیاز داشته باشید. اول مقصد بیرونی و آزمون بازگردانی را کامل کنید.
چطور مطمئن شویم نسخهٔ پشتیبان واقعاً برمیگردد؟
با آزمون بازگردانی در محیط آزمایشی؛ سایت بالا بیاید، سفارش آزمایشی ثبت شود و دادههای تازه سر جایشان باشند. این آزمون را هر فصل و بعد از هر آپدیت بزرگ تکرار کنید.