WordPress Backup

ওয়ার্ডপ্রেস ওয়েবসাইটের ব্যাকআপ নেওয়ার সহজ নিয়ম

দ্বারা

ওয়েবসাইট ভালো চলছে বলে ব্যাকআপের দরকার নেই—এই ধারণাই অনেক সময় সবচেয়ে বড় বিপদের কারণ হয়। ভুল update, plugin conflict, malware, hosting failure, accidental deletion কিংবা মানবিক ভুলে কয়েক বছরের লেখা, order এবং customer data মুহূর্তে অদৃশ্য হতে পারে। নির্ভরযোগ্য WordPress Backup থাকলে এমন ঘটনার পর আতঙ্কিত না হয়ে পরিচিত একটি ভালো অবস্থায় site ফিরিয়ে নেওয়া যায়। ব্যাকআপ তাই কেবল technical কাজ নয়; এটি website continuity, আয় এবং পাঠকের আস্থা রক্ষার ব্যবস্থা।

নতুনদের কাছে backup মানে প্রায়ই শুধু public_html folder-এর ZIP file। কিন্তু WordPress site-এর অন্তত দুটি অপরিহার্য অংশ আছে—server-এর files এবং MySQL/MariaDB database। একটিকে বাদ দিলে সম্পূর্ণ site পুনরুদ্ধার নাও হতে পারে। এই গাইডে manual, hosting এবং plugin—তিন পদ্ধতি, কত ঘন ঘন copy নেবেন, কোথায় রাখবেন, restore পরীক্ষা করবেন কীভাবে এবং কোন ভুলগুলো এড়াবেন—সবকিছু সহজ ভাষায় দেখানো হয়েছে।

ধাপগুলো self-hosted WordPress site ধরে লেখা। Managed WordPress বা proprietary hosting dashboard-এ button-এর নাম ভিন্ন হতে পারে, কিন্তু মূল নীতি একই: সম্পূর্ণ data সংগ্রহ, আলাদা নিরাপদ স্থানে রাখা, copy যাচাই এবং বাস্তবে restore করার প্রস্তুতি। কাজের আগে আপনার hosting provider-এর documentation ও retention policy মিলিয়ে নিন।

দ্রুত উত্তর: পূর্ণ WordPress Backup-এ website files এবং database—দুটিই থাকতে হবে। অন্তত একটি automatic schedule চালু করুন, hosting account-এর বাইরে encrypted copy রাখুন এবং নিয়মিত staging বা test location-এ restore করে দেখুন। বড় update, migration বা code পরিবর্তনের ঠিক আগে আলাদা on-demand backup নিলে দ্রুত rollback করা যায়।

Table of Contents

এই গাইডে যা জানবেন

WordPress Backup কী এবং এতে কী কী থাকতে হবে?

Backup হলো নির্দিষ্ট সময়ে website-এর পুনরুদ্ধারযোগ্য copy। WordPress core files, theme, plugin, child-theme customization, uploaded media, configuration file এবং বিশেষ custom code file অংশে থাকে। অন্যদিকে post, page, comment, user, WooCommerce order, settings, menu এবং অনেক plugin-এর configuration database-এ থাকে। কেবল files download করলে লেখা ও order বাদ পড়তে পারে; শুধু database export করলে image, theme এবং plugin ফিরে আসবে না।

একটি “backup set” বলতে একই সময়ের file copy ও database export-কে বোঝানো ভালো। উদাহরণ হিসেবে সোমবার রাত ২টার database-এর সঙ্গে শুক্রবারের files রাখলে মাঝের media বা plugin version মিলবে না। তাই backup tool-এর timestamp, timezone এবং কোন অংশ অন্তর্ভুক্ত হয়েছে তা লিখে রাখুন। Multisite, large media library, external object storage বা আলাদা order table ব্যবহার করলে tool সব data ধরছে কি না provider-এর নির্দেশনায় যাচাই করুন।

Backup আর snapshot একই উদ্দেশ্যে কাজে লাগলেও এক নয়। Server snapshot দ্রুত পুরো virtual machine ফিরিয়ে দিতে পারে, কিন্তু অনেক shared host-এ granular file বা একটি post ফেরানো কঠিন। আবার staging copy production backup-এর বিকল্প নয়, কারণ staging-ও একই hosting failure-এ হারাতে পারে। ভালো পরিকল্পনায় daily operational backup, update-পূর্ব restore point এবং দীর্ঘমেয়াদি archive আলাদা ভূমিকা পালন করে।

কত ঘন ঘন ব্যাকআপ নেবেন: পরিবর্তনের হার দিয়ে সিদ্ধান্ত নিন

সব website-এর একই schedule দরকার হয় না। মাসে একবার নতুন লেখা প্রকাশ করা portfolio site-এর weekly database ও monthly full backup যথেষ্ট হতে পারে। প্রতিদিন content update হওয়া news site-এর daily full এবং ঘন database backup দরকার। WooCommerce shop-এ প্রতি ঘণ্টায় order এলে দৈনিক copy নিলে crash-এর সময় প্রায় এক দিনের transaction হারাতে পারেন; সেখানে real-time বা hourly database protection বিবেচনা করা উচিত।

Recovery Point Objective বা RPO সহজ ভাষায় হলো—সর্বোচ্চ কত সময়ের data হারানো আপনি মেনে নিতে পারবেন। Recovery Time Objective বা RTO হলো—কত সময়ের মধ্যে site সচল দরকার। একটি hobby blog-এর RPO ২৪ ঘণ্টা ও RTO এক দিন হতে পারে; online store-এর জন্য তা অনেক কম। এই দুই প্রশ্নের উত্তর দিলে backup frequency, storage budget এবং managed service-এর প্রয়োজন পরিষ্কার হয়।

নিয়মিত schedule-এর বাইরেও WordPress core, theme বা plugin update; PHP version পরিবর্তন; নতুন payment gateway; bulk import; database optimization; DNS বা hosting migration-এর আগে on-demand backup নিন। পরিবর্তনের কারণ, সময় এবং backup file-এর নাম change log-এ লিখুন। সমস্যা হলে কোন restore point বেছে নেবেন তা তখন অনুমানের ওপর থাকবে না।

৩-২-১ নীতি: একই server-এ backup রাখলেই কেন যথেষ্ট নয়

৩-২-১ নীতিতে গুরুত্বপূর্ণ data-এর মোট তিনটি copy, অন্তত দুই ধরনের storage এবং একটি copy অন্য location-এ রাখা হয়। Production site একটি copy; hosting backup দ্বিতীয়; encrypted cloud storage বা offline drive তৃতীয় হতে পারে। একই hosting account-এর backup folder ransomware, account takeover, disk failure কিংবা provider-level incident থেকে সব সময় রক্ষা করবে না। তাই offsite copy অত্যন্ত গুরুত্বপূর্ণ।

Cloud destination বাছার সময় শুধু storage space নয়, access control, encryption, versioning, data region, download speed এবং recovery cost দেখুন। backup plugin-কে পুরো cloud drive-এর permission না দিয়ে সম্ভব হলে নির্দিষ্ট folder-এর সীমিত access দিন। shared Google Drive বা ব্যক্তিগত account-এ business backup রাখলে কর্মী চলে গেলে ownership সমস্যা হতে পারে; প্রতিষ্ঠানের নিয়ন্ত্রিত account ও documented recovery method ব্যবহার করুন।

Local computer-এ copy রাখলে disk encryption, antivirus এবং physical security নিশ্চিত করুন। USB drive সব সময় computer-এ লাগানো থাকলে malware সেটিও ক্ষতিগ্রস্ত করতে পারে; archive drive কাজ শেষে বিচ্ছিন্ন রাখা যায়। অত্যন্ত সংবেদনশীল backup file password-protected বা encrypted করুন, কিন্তু encryption key হারালে recovery অসম্ভব হবে—তাই key-এর আলাদা, সুরক্ষিত copy এবং দায়িত্বপ্রাপ্ত ব্যক্তির নাম নথিভুক্ত রাখুন।

Hosting control panel দিয়ে WordPress Backup নেওয়ার ধাপ

প্রথমে hosting dashboard-এ Backup, Backup Wizard, JetBackup বা সমজাতীয় menu খুঁজুন। Full Account Backup থাকলে website files, database, email ও account setting একসঙ্গে ধরা পড়তে পারে; তবে অন্য server-এ restore করতে provider assistance লাগতে পারে। Home directory এবং database আলাদা download option থাকলে দুটিই নিন। কোন domain বা database site-এর সঙ্গে যুক্ত বুঝতে wp-config.php-এর database name দেখা যায়, কিন্তু password বা secret key কখনো screenshot কিংবা public note-এ রাখবেন না।

File Manager দিয়ে manual copy নিলে WordPress root-এর hidden file, বিশেষ করে .htaccess, বাদ পড়ছে কি না নিশ্চিত করুন। root folder archive করুন এবং তৈরি ZIP hosting account-এর বাইরে download করুন। তারপর phpMyAdmin বা dashboard-এর database backup tool দিয়ে সংশ্লিষ্ট database export করুন। সাধারণ site-এ quick SQL export কাজ করে; বড় database-এ compressed export, command line বা provider tool বেশি নির্ভরযোগ্য হতে পারে। Export শেষ হওয়ার আগে tab বন্ধ করবেন না।

Download করা archive খুলে অন্তত file list দেখুন এবং database file শূন্য byte কি না যাচাই করুন। media folder, active theme ও plugin directory উপস্থিত আছে কি না দেখুন। File ও database-এর নামের সঙ্গে domain, UTC বা Dhaka সময় এবং backup type লিখুন—যেমন example-com_full_2026-10-25_0200। Hosting-generated backup কত দিন রাখা হয় তা জানুন; অনেক provider পুরোনো copy স্বয়ংক্রিয়ভাবে মুছে দেয়।

Plugin দিয়ে automatic backup: সেটিং কীভাবে করবেন

Plugin পদ্ধতি নতুনদের জন্য সুবিধাজনক, কারণ dashboard থেকে schedule, remote destination এবং retention নির্ধারণ করা যায়। তবে plugin বাছার সময় active installation সংখ্যার চেয়ে update history, WordPress/PHP compatibility, restore workflow, multisite বা WooCommerce support, encryption এবং support policy দেখুন। অচেনা source থেকে premium plugin download করলে backup-এর ভেতরেই malware বা credential theft-এর ঝুঁকি তৈরি হয়।

Install করার পর প্রথমে remote storage connect করুন। Files ও database-এর পৃথক schedule দিন; content পরিবর্তনের হারের সঙ্গে frequency মিলিয়ে নিন। Retention এমন রাখুন যাতে সাম্প্রতিক কয়েকটি daily, কয়েকটি weekly এবং প্রয়োজন হলে monthly copy থাকে। সব revision অনির্দিষ্টকাল রাখলে storage bill বাড়ে। Backup চলার সময় server resource বেশি লাগে, তাই traffic কম এমন সময় schedule করুন এবং বড় uploads folder incremental backup সমর্থন করে কি না দেখুন।

Success notification চালু করলেই কাজ শেষ নয়। Email filter বা notification failure-এর কারণে alert চোখ এড়াতে পারে। সপ্তাহে dashboard ও remote folder দেখে সর্বশেষ timestamp মিলিয়ে নিন। “completed” লেখা থাকলেও archive অসম্পূর্ণ হতে পারে; log-এ skipped file, timeout, storage quota ও authentication error দেখুন। Plugin update-এর পর connection token কার্যকর আছে কি না যাচাই করুন।

FTP/SFTP ও database export দিয়ে manual backup

Manual পদ্ধতিতে আপনি backup-এর ভেতরের জিনিস বুঝতে পারেন এবং plugin ছাড়াই copy নিতে পারেন। SFTP বা hosting-provided secure file connection ব্যবহার করে WordPress root download করুন। সাধারণ FTP password plaintext-এ যেতে পারে, তাই সম্ভব হলে এড়িয়ে চলুন। Large site-এ হাজার হাজার ছোট file download ধীর হয়; control panel-এ archive বানিয়ে SFTP-তে এক file download করা দ্রুত হতে পারে। Server-এ archive রেখে না দিয়ে যাচাই শেষে মুছে ফেলুন, কারণ public path-এ backup leak গুরুতর ঝুঁকি।

Database-এর জন্য phpMyAdmin export বা host-এর command-line tool ব্যবহার করা যায়। Character set ও compression ঠিক রাখুন। খুব বড় database browser export-এ timeout হলে host support বা WP-CLI সম্পর্কে জিজ্ঞাসা করুন। Database export-এ user email, password hash, order address এবং API setting থাকতে পারে, তাই file-টিকে public share link-এ রাখবেন না। Team member-কে পাঠালে encrypted channel ও expiry ব্যবহার করুন।

Manual backup-এর দুর্বলতা হলো ভুলে যাওয়া এবং human error। তাই calendar reminder, লিখিত checklist এবং দ্বিতীয় ব্যক্তির review সহায়ক। কোন folder custom, কোন external service data রাখে এবং restore-এর dependency কী—একটি recovery document-এ লিখুন। Developer চলে গেলেও যাতে owner বা নতুন administrator প্রক্রিয়াটি বুঝতে পারেন, document hosting credential-এর নিরাপদ location ও support contact নির্দেশ করবে; password সরাসরি document-এ লেখা উচিত নয়।

Restore test না করলে backup অসম্পূর্ণ কেন

Backup file থাকা আর site ফিরিয়ে আনতে পারা এক কথা নয়। Archive corrupt, database export অসম্পূর্ণ, encryption key অনুপস্থিত বা plugin license unavailable হলে জরুরি মুহূর্তে copy কাজে নাও লাগতে পারে। তাই production-এর ওপর পরীক্ষা না করে staging, local environment বা temporary protected subdomain-এ restore করুন। Search engine indexing বন্ধ রাখুন এবং real customer email/payment যেন test site থেকে না যায় সেজন্য outgoing mail ও gateway sandbox করুন।

Restore-এর পরে শুধু homepage দেখা যথেষ্ট নয়। Admin login, কয়েকটি পুরোনো ও নতুন post, image, search, contact form, user role, checkout, order detail, scheduled task, permalink এবং HTTPS পরীক্ষা করুন। Console ও server log-এ error দেখুন। যদি domain বদলে test করেন, serialization-safe search-replace tool ছাড়া raw SQL replace করবেন না; ভুল length-এ widget বা configuration নষ্ট হতে পারে। Test শেষে sensitive staging data মুছে দিন।

Restore সময় মাপুন এবং বাধা লিখে রাখুন। Download ধীর হলে nearer storage বা emergency local copy দরকার হতে পারে। Provider ছাড়া full account restore করা না গেলে support-এর service hour ও response time জানা জরুরি। বছরে অন্তত কয়েকবার recovery drill করলে team বুঝতে পারে কে incident ঘোষণা করবেন, কে DNS/hosting সামলাবেন এবং visitor-কে status জানাবেন।

Backup-এর নিরাপত্তা ও গোপনীয়তা রক্ষার নিয়ম

Backup production site-এর সমান বা কখনো আরও সংবেদনশীল। এতে database credential, salts, user information, order history এবং unpublished content থাকতে পারে। Storage account-এ unique password, MFA, minimum necessary permission এবং activity alert চালু করুন। Public bucket, guessable ZIP URL বা email attachment হিসেবে পূর্ণ backup পাঠানো এড়িয়ে চলুন। Agency কাজ করলে contract-এ backup ownership, retention, deletion ও breach notification স্পষ্ট করুন।

Encryption at rest ও transit আছে কি না যাচাই করুন। Client-side encryption ব্যবহার করলে key management plan দরকার। পুরোনো কর্মী বা vendor-এর access দ্রুত revoke করুন এবং quarterly access review করুন। Cloud share link তৈরি করলে expiry ও download restriction দিন। Backup log-এ secret বা full path প্রকাশ পেলে log-ও সুরক্ষিত করুন। Data protection obligation অনুযায়ী অপ্রয়োজনীয় পুরোনো customer data অনির্দিষ্টকাল রাখা ঠিক নয়।

Production server আক্রান্ত হলে clean backup আলাদা রাখা জরুরি। Malware ঢোকার আগের তারিখ শনাক্ত না করে সর্বশেষ copy restore করলে infection ফিরে আসতে পারে। Restore-এর আগে files scan, core checksum compare, compromised password ও API key rotate এবং vulnerability patch করুন। শুধু site ফিরিয়ে online করাই recovery নয়; intrusion-এর মূল কারণ বন্ধ না করলে একই ঘটনা আবার ঘটবে।

WordPress Backup নেওয়ার সাধারণ ভুল ও বাস্তব সমাধান

প্রথম ভুল হলো host “backup দেয়” শুনে policy না পড়া। Copy একই infrastructure-এ থাকতে পারে, retention মাত্র কয়েক দিন হতে পারে কিংবা restore-এর fee থাকতে পারে। দ্বিতীয় ভুল—database বাদ দেওয়া। তৃতীয় ভুল—automatic job মাসের পর মাস fail করলেও notification না দেখা। প্রতিটির সমাধান হলো written policy, independent offsite copy এবং নিয়মিত restore test।

আরেক ভুল হলো backup file website-এর public folder-এ রাখা। Search engine, directory listing বা leaked link দিয়ে এটি download হতে পারে। Download শেষ করে server copy সরিয়ে দিন অথবা web-accessible root-এর বাইরে রাখুন। একই নাম overwrite করলে শুধু সর্বশেষ copy থাকে; malware দেরিতে ধরা পড়লে clean version পাওয়া যায় না। তাই versioned retention দরকার।

Update-এর পরে site ঠিক দেখালেই pre-update backup সঙ্গে সঙ্গে মুছবেন না। Background job, checkout বা email failure কয়েক দিন পরে ধরা পড়তে পারে। আবার সব copy চিরকাল রাখলে privacy ও cost সমস্যা বাড়ে। দৈনিক, সাপ্তাহিক ও মাসিক স্তরের rational retention ঠিক করুন। Backup status owner, technical contact ও last-tested date একটি ছোট register-এ রাখলে দায়িত্ব অস্পষ্ট থাকে না।

ছোট ব্যবসার জন্য সহজ Disaster Recovery পরিকল্পনা

এক পাতার recovery plan-এ domain registrar, DNS, hosting, WordPress admin, backup storage ও status communication-এর দায়িত্ব আলাদা করে লিখুন। কোন পরিস্থিতিতে site maintenance mode-এ যাবে, কোন restore point নেওয়া হবে এবং customer transaction কীভাবে reconcile করবেন তা আগে ঠিক করুন। Emergency-তে password chat group-এ পাঠানোর বদলে approved password manager ব্যবহার করুন।

Incident হলে প্রথমে পরিবর্তন বন্ধ করুন, evidence ও বর্তমান state-এর forensic copy রাখুন, তারপর clean environment-এ recovery করুন। Hacked site-এর ক্ষেত্রে শুধু পুরোনো backup restore যথেষ্ট নয়; credential rotation, malware investigation এবং vulnerable component update করতে হবে। ভুল update হলে latest clean backup ও change log দিয়ে দ্রুত rollback করা যায়। প্রতিটি ক্ষেত্রে DNS TTL, cache এবং CDN-এর কারণে visitor ভিন্ন version দেখতে পারেন—এটি support message-এ বিবেচনা করুন।

Recovery শেষে form, payment, analytics এবং indexing পরীক্ষা করে incident review করুন। কী ঘটেছে, detection কেন দেরি হয়েছে, কত data হারিয়েছে এবং কোন control বদলানো দরকার লিখুন। এই review দোষারোপের জন্য নয়; পরের incident ছোট করার জন্য। একটি বিস্তারিত performance ও maintenance পরিকল্পনার জন্য WordPress Speed Optimization-এর ১৫টি উপায় পড়তে পারেন—কারণ safe update ও optimized setup recovery risk-ও কমায়।

কাজ শুরুর আগে সংক্ষিপ্ত চেকলিস্ট

  • Website files এবং database—দুটিই একই সময়ের backup set-এ আছে।
  • Automatic schedule-এর পাশাপাশি update বা migration-এর আগে on-demand copy নেওয়া হয়েছে।
  • Hosting-এর বাইরে অন্তত একটি encrypted offsite copy রাখা হয়েছে।
  • Backup status, retention, storage quota এবং notification নিয়মিত পরীক্ষা করা হয়।
  • Staging বা local environment-এ restore test সফল হয়েছে এবং সময় নথিভুক্ত আছে।
  • Storage access-এ unique password, MFA ও minimum permission ব্যবহার করা হয়েছে।
  • Recovery contact, ownership এবং জরুরি ধাপ লিখিতভাবে সংরক্ষিত আছে।

সম্পর্কিত আরও গাইড

Backup নেওয়ার পর restore-এর সবচেয়ে বড় বাস্তব ব্যবহার হলো server পরিবর্তন। ধাপে ধাপে প্রস্তুতির জন্য বাংলাদেশে সেরা Web Hosting নির্বাচন করার গাইড এবং WordPress পরিচালনার panel তুলনা বুঝতে WordPress-এর জন্য সেরা control panel পড়ুন।

সাধারণ প্রশ্ন ও উত্তর

শুধু uploads folder নিলে কি পূর্ণ WordPress Backup হবে?

না। uploads-এ media থাকে, কিন্তু post, page, user, order ও settings database-এ এবং theme/plugin আলাদা folder-এ থাকে। সম্পূর্ণ recovery-এর জন্য files ও database দুটিই দরকার।

প্রতিদিন backup নেওয়া কি সব site-এর জন্য জরুরি?

পরিবর্তনের হার অনুযায়ী frequency ঠিক করুন। স্থির portfolio-তে weekly যথেষ্ট হতে পারে, কিন্তু প্রতিদিন order বা content হওয়া site-এ daily, hourly বা real-time protection প্রয়োজন হতে পারে।

Hosting backup থাকলে plugin backup দরকার?

অবশ্যই দরকার—এমন নয়; কিন্তু একই provider-এর ওপর একক নির্ভরতা ঝুঁকিপূর্ণ। অন্তত একটি স্বাধীন offsite copy এবং restore করার স্পষ্ট পদ্ধতি থাকা ভালো।

Backup কত দিন রাখব?

ব্যবসার ঝুঁকি, storage budget ও privacy obligation দেখে policy বানান। সাধারণভাবে কয়েকটি daily, weekly ও monthly version রাখলে সাম্প্রতিক এবং দেরিতে ধরা সমস্যার recovery point পাওয়া যায়।

Backup সফল হয়েছে কীভাবে বুঝব?

Tool-এর success message-এর পাশাপাশি file size, database export, remote destination ও log পরীক্ষা করুন। সবচেয়ে নির্ভরযোগ্য প্রমাণ হলো নিরাপদ test environment-এ restore করে গুরুত্বপূর্ণ function চালানো।

Restore করার আগে কী সতর্কতা নেব?

বর্তমান অবস্থার copy নিন, incident-এর কারণ বোঝার চেষ্টা করুন, correct timestamp বাছুন এবং production-এর বদলে staging-এ test করুন। Hacking হলে password ও key rotate এবং vulnerability patch করুন।

শেষ কথা

ভালো WordPress Backup ব্যবস্থা অদৃশ্য থাকলেও বিপদের দিনে website-এর সবচেয়ে মূল্যবান সম্পদ হয়ে ওঠে। পূর্ণ files ও database, পরিবর্তনের সঙ্গে মানানসই schedule, offsite copy, শক্ত access control এবং নিয়মিত restore test—এই পাঁচটি স্তম্ভ অনুসরণ করলে সাধারণ ভুল, update failure থেকে বড় security incident—সব ক্ষেত্রেই ক্ষতি ও downtime কমানো যায়। আজই একটি on-demand backup নিন, সেটি hosting-এর বাইরে রাখুন এবং calendar-এ প্রথম restore drill-এর তারিখ লিখুন।

WordPress, backup plugin ও hosting dashboard-এর interface, storage limit এবং retention policy সময়ের সঙ্গে বদলাতে পারে। কাজের আগে ব্যবহৃত provider ও tool-এর বর্তমান official documentation, privacy policy এবং restore নির্দেশনা যাচাই করুন।

মন্তব্য করুন