Website update করার পর homepage ভেঙে গেল। Hosting panel-এ একটি backup আছে, কিন্তু সেটি কবে নেওয়া, database আছে কি না এবং restore করলে নতুন order হারাবে কি না জানা নেই। এই অবস্থায় backup file থাকা স্বস্তির হলেও কাজ শুরু করার জন্য যথেষ্ট তথ্য নয়। Website backup-এর উদ্দেশ্য হলো প্রয়োজনের সময় সঠিক অবস্থায় ফিরে আসা।
এই গাইডে self-hosted WordPress website-এর backup ও restore পরিকল্পনা দেওয়া হলো। সাধারণ blog, service website এবং WooCommerce store-এর চাহিদা এক নয়। তাই শুধু একটি plugin install করে default schedule চালানোর বদলে নিজের data কত দ্রুত বদলায় এবং কতটা হারানো গ্রহণযোগ্য তা আগে নির্ধারণ করতে হবে।
দ্রুত উত্তর: WordPress-এর files ও database দুটোই backup করুন, website server-এর বাইরে একটি কপি রাখুন এবং staging-এ restore করে পরীক্ষা করুন। ব্যস্ত store পুরোনো অবস্থায় ফেরানোর আগে নতুন order, payment ও customer data কীভাবে সংরক্ষণ করবেন পরিকল্পনা করুন।
WordPress Backup ও Restore: Website নিরাপদে ফেরানোর বাংলা গাইড
কোন কোন জিনিস backup-এর মধ্যে থাকবে?
Database-এ post, page, settings এবং বিভিন্ন plugin-এর data থাকে। Files-এর মধ্যে media upload, theme, plugin ও configuration থাকতে পারে। WordPress-এর অফিসিয়াল backup নির্দেশনা typical site পুনরুদ্ধারের জন্য database ও files দুটির গুরুত্ব ব্যাখ্যা করে। শুধু একটি অংশ দিয়ে সম্পূর্ণ site ফেরত নাও পাওয়া যেতে পারে।
একটি inventory লিখুন: website files, database, DNS record, email service configuration ও বাইরের integration। সবকিছু একই backup plugin ধরে না। যেমন domain registrar-এর login বা payment provider dashboard website backup থেকে ফিরে আসবে না। কোন দায়িত্ব কার কাছে আছে লিখে রাখুন।
Export ও full backup-এর পার্থক্য
WordPress-এর Tools → Export থেকে পাওয়া content export post স্থানান্তরের কাজে লাগে। কিন্তু সেটি সম্পূর্ণ hosting account বা চলমান সব service-এর snapshot নয়। Theme configuration, server settings বা বাইরের account ফেরানোর জন্য আলাদা ব্যবস্থা লাগতে পারে।
যে backup tool ব্যবহার করবেন তার restore scope পড়ুন। “Full backup” নামের অন্তর্ভুক্ত অংশও tool ও hosting-ভেদে ভিন্ন হতে পারে। Backup list-এ archive দেখা গেলেই সবকিছু আছে ধরে না নিয়ে ভেতরের অংশ ও restore documentation যাচাই করুন।
কত ঘন ঘন backup নেবেন?
মাসে একটি লেখা যোগ করা website এবং ঘণ্টায় order পাওয়া store-এর প্রয়োজন আলাদা। কী ধরনের data বদলায় সেই অনুযায়ী schedule করুন। নতুন post, form submission, booking, order এবং plugin update—সব পরিবর্তনের গুরুত্ব সমান নয়।
| Website-এর ধরন | পরিকল্পনার মূল প্রশ্ন |
|---|---|
| সাধারণ blog | নতুন লেখা ও media কত ঘন ঘন যোগ হয়? |
| Service website | Lead বা booking কোথায় জমা হয়? |
| Online shop | কত সময়ের order হারানো ব্যবসা মেনে নিতে পারে? |
| Course বা membership site | User progress ও payment কত দ্রুত বদলায়? |
দৈনিক backup মানে দিনের সব data সুরক্ষিত—এমন নয়। Backup-এর পর নতুন data তৈরি হলে সেটি পরের কপির আগ পর্যন্ত ঝুঁকিতে থাকে। সম্ভাব্য ক্ষতির সময়সীমা ও recovery time আপনার ব্যবসার দায়িত্বপ্রাপ্ত ব্যক্তির সঙ্গে ঠিক করুন।
Hosting backup-এর সঙ্গে নিজের কপি রাখুন
Hosting provider-এর backup সুবিধা কাজে লাগতে পারে, কিন্তু account বন্ধ, billing সমস্যা বা panel access হারালে সেটি পাওয়া যাবে কি না জানুন। Backup কোথায় থাকে, retention কতদিন এবং download করা যায় কি না support থেকে নিশ্চিত করুন।
একটি independent copy অন্য storage-এ রাখলে একই server-এর সমস্যায় সব কপি একসঙ্গে অপ্রাপ্য হওয়ার সম্ভাবনা কমে। তবু copy আছে বলেই সুরক্ষা সম্পূর্ণ নয়; access control, encryption ও restore test দরকার। একই password দিয়ে সব account চালালে স্বাধীন storage-এর সুবিধাও কমে যেতে পারে।
Retention কীভাবে ঠিক করবেন?
শুধু সর্বশেষ backup থাকলে দেরিতে ধরা পড়া সমস্যা থেকে বের হওয়া কঠিন হতে পারে। উদাহরণ হিসেবে, গত কয়েক দিন ধরে খারাপ content জমছে অথচ আপনি আজ দেখলেন। আজকের backup-এও সেই সমস্যা থাকতে পারে। তাই বিভিন্ন সময়ের পরিষ্কার copy রাখার প্রয়োজন বিবেচনা করুন।
Retention বেশি হলে storage ও পুরোনো ব্যক্তিগত data ধরে রাখার দায়িত্বও বাড়ে। অযথা অনির্দিষ্টকাল সব কপি না রেখে প্রয়োজনভিত্তিক নীতি করুন। Backup delete করার আগে সেটি একমাত্র ভালো copy কি না এবং কোনো চলমান recovery-এর জন্য দরকার কি না দেখুন।
Backup tool বাছাইয়ের ব্যবহারিক মানদণ্ড
Manual export, scheduled backup, hosting snapshot বা dedicated backup service—প্রতিটির সুবিধা ও সীমা আছে। Tool বাছাইয়ের সময় restore method, storage location, log, notification ও access recovery দেখুন। Dashboard বন্ধ থাকলেও restore শুরু করা যায় কি না জেনে নিন।
- Files ও database একই উপযুক্ত restore point-এর অন্তর্ভুক্ত কি না।
- বড় site-এ archive তৈরি ও restore-এর সীমা কী।
- অন্য server বা staging-এ restore করা যায় কি না।
- ব্যর্থ backup-এর alert কোথায় যায়।
- Subscription শেষ হলে পুরোনো copy কীভাবে পাওয়া যাবে।
একাধিক backup plugin একই সময়ে চালালে resource ব্যবহার বাড়তে পারে। নতুন system নিলে পুরোনো schedule ও storage policy মিলিয়ে নিন। শুধু সব plugin activate করে রাখা একটি backup strategy নয়।
প্রথম backup-এর পর কী যাচাই করবেন?
Run completed দেখানোর পর log দেখুন। Archive-এর size অস্বাভাবিক ছোট কি না এবং প্রত্যাশিত database ও media আছে কি না পরীক্ষা করুন। Backup যে account-এ রাখা হয়েছে সেখানে অন্য অনুমোদিত ব্যক্তি প্রয়োজন হলে ঢুকতে পারবেন কি না নিশ্চিত করুন।
Backup file public web folder-এ খোলা রাখবেন না। Archive-এর মধ্যে database credential বা customer data থাকতে পারে। Download link কাজ করছে বলে সবার সঙ্গে share করবেন না। Transfer ও storage-এর অনুমতি সীমিত রাখুন এবং কাজ শেষে temporary copy পরিষ্কার করুন।
Restore drill: staging-এ কীভাবে পরীক্ষা করবেন?
Production website-এ অপ্রয়োজনীয় restore না করে staging বা বিচ্ছিন্ন test environment ব্যবহার করুন। পুরোনো site ফেরানোর পর outgoing email, payment ও scheduled action বন্ধ বা test mode-এ রাখুন, যাতে বাস্তব customer-এর কাছে duplicate notification না যায়।
Homepage খুললেই পরীক্ষা শেষ নয়। কয়েকটি post, image, form, login, search ও গুরুত্বপূর্ণ workflow চালান। Store হলে sample product, stock display ও test checkout দেখুন। Domain বদলালে link ও stored URL কীভাবে সামলাতে হবে tool-এর নির্দেশনা অনুযায়ী করুন।
Restore করতে কত সময় লেগেছে ও কোথায় বাধা এসেছে লিখুন। Disaster-এর দিন প্রথমবার এসব শেখার চেয়ে আগে ছোট drill করা বেশি কার্যকর। Credentials ও installation note এমন জায়গায় রাখুন যা মূল website বন্ধ হলেও পাওয়া যাবে।
Update-এর আগে recovery point রাখুন
Core, theme বা গুরুত্বপূর্ণ plugin update-এর আগে backup নেওয়া ও প্রস্তুত restore point রাখা কাজে লাগে। একই সঙ্গে অনেক update করলে কোনটিতে সমস্যা হয়েছে বোঝা কঠিন হতে পারে। Staging-এ update করে তারপর প্রয়োজনীয় flow পরীক্ষা করার অভ্যাস করুন।
Backup নেওয়ার পরেও website-এর পরিবর্তন চলতে থাকবে। Busy store-এ update ও rollback-এর সময় live order কীভাবে ধরবেন সেটি পরিকল্পনা করুন। শুধু “backup আছে” বলে নতুন sale overwrite করা উচিত নয়। প্রয়োজনে maintenance window ও specialist সাহায্য নিন।
WooCommerce restore-এ নতুন order-এর ঝুঁকি
পুরোনো database ফেরালে backup-এর পর তৈরি হওয়া order বা customer record হারাতে পারে। Payment provider-এ transaction থাকলেও website-এর order না থাকতে পারে। তাই restore-এর আগে বর্তমান অবস্থার আলাদা copy ও transaction record রাখুন।
Selective restore সব tool-এ একইভাবে কাজ করে না। Product page-এর সমস্যা ঠিক করতে পুরো database ফেরানোর প্রয়োজন আছে কি না আগে নির্ধারণ করুন। Order data merge-এর মতো কাজ দক্ষতা ছাড়া করবেন না; ভুলে duplicate, missing stock movement বা payment mismatch হতে পারে।
Payment event ও order verification বোঝার জন্য WooCommerce payment integration গাইড পড়তে পারেন। Restore-এর পর paid order, stock ও notification আলাদা করে যাচাই করুন।
Malware থাকলে পুরোনো backup সরাসরি ফেরাবেন?
Backup নেওয়ার আগেই website আক্রান্ত হলে সেই copy-তেও সমস্যা থাকতে পারে। পরিষ্কার restore point বাছাই এবং আক্রমণের প্রবেশপথ বন্ধ করা জরুরি। পুরোনো vulnerable component ফেরালে একই সমস্যা আবার আসতে পারে।
Hosting-এর malware scan, access log ও পরিচিত পরিবর্তন মিলিয়ে incident timeline তৈরি করুন। প্রয়োজন হলে security specialist-এর সাহায্য নিন। Password, active session ও secret key-এর ব্যবস্থা পর্যালোচনা করুন। Backup recovery এবং security cleanup আলাদা দায়িত্ব হলেও একসঙ্গে পরিকল্পনা করা দরকার।
Restore ব্যর্থ হলে কীভাবে এগোবেন?
| লক্ষণ | প্রথম অনুসন্ধান |
|---|---|
| Archive খুলছে না | Download সম্পূর্ণ কি না এবং integrity result |
| Database import থামে | Tool log, server limit ও database compatibility |
| Media নেই | Uploads অংশ backup-এ ছিল কি না |
| Site খুলে, login চলে না | URL, cookie/session ও environment configuration |
| Form mail যায় না | Mailer connection ও staging restriction |
আবার চেষ্টা করার আগে failed restore আংশিক পরিবর্তন করেছে কি না দেখুন। একই environment-এ অন্ধভাবে বারবার চালালে troubleshooting কঠিন হয়। Tool-এর নির্দিষ্ট recovery process অনুসরণ করুন এবং support-কে archive, version ও log-এর প্রয়োজনীয় অংশ দিন।
দায়িত্ব ও recovery নোট তৈরি করুন
একটি ছোট নোটে domain provider, hosting, backup location, technical contact ও অনুমোদিত decision maker লিখুন। সেখানে plain password না রেখে password manager বা secure recovery পদ্ধতির উল্লেখ রাখুন। Website বন্ধ হলে কে সিদ্ধান্ত নেবেন তা স্পষ্ট হওয়া দরকার।
Backup alert নিজের কার্যকর inbox-এ নিন। Website-এর ভেতর error হলেও notification যাবে কি না ভাবুন। Delivery setup নিয়ে business email গাইড এবং office document-এর জন্য cloud file management গাইড সহায়ক হতে পারে।
মাসিক backup review-এর ছোট তালিকা
সাম্প্রতিক copy তৈরি হয়েছে কি না, storage capacity আছে কি না এবং failure alert কেউ দেখছেন কি না যাচাই করুন। Scheduled time ব্যবসার ব্যস্ত সময়ের সঙ্গে সংঘর্ষ করছে কি না দেখুন। Plugin বা hosting বদলালে backup plan-ও সংশোধন করুন।
যে ব্যক্তি backup করেছিলেন তিনিই শুধু restore জানেন—এমন পরিস্থিতি এড়াতে প্রয়োজনীয় দায়িত্ব হস্তান্তর রাখুন। Restore drill-এর নোট দিয়ে অন্য অনুমোদিত ব্যক্তি কাজের শুরু করতে পারেন কি না পরীক্ষা করুন। ভালো পরিকল্পনা সবচেয়ে দরকার হয় মূল দায়িত্বপ্রাপ্ত ব্যক্তি অনুপস্থিত থাকলে।
খরচের সঙ্গে recovery-এর মূল্য তুলুন
Backup-এর subscription কম হলেও restore করতে দীর্ঘ সময় লাগলে business বন্ধ থাকার খরচ বেশি হতে পারে। আবার অল্প পরিবর্তন হওয়া site-এ অপ্রয়োজনীয় জটিল system চালানোর maintenance লাগতে পারে। Tool-এর দাম ছাড়াও storage, transfer, support ও আপনার team-এর সময় হিসাব করুন। সবচেয়ে দামি plan সব business-এর জন্য স্বয়ংক্রিয়ভাবে উপযুক্ত নয়।
একটি কাগজে লিখুন website এক ঘণ্টা, একদিন বা কয়েকদিন বন্ধ থাকলে কী কাজ আটকে যাবে। Customer inquiry, order, course access বা brand information—কোনটি জরুরি তা চিহ্নিত করুন। এই মূল্যায়নের ভিত্তিতে backup frequency ও restore support বেছে নিন। Hosting provider কত সময়ে সাহায্য করবেন এবং জরুরি সময়ে কোন যোগাযোগ ব্যবহার করবেন সেটিও আগে জেনে রাখুন।
Backup notification পরীক্ষা করার উপায়
Scheduled backup-এর alert কোন inbox-এ আসে এবং কে দেখেন তা নির্ধারণ করুন। একটি test run দিয়ে completion notice পাওয়া যাচ্ছে কি না দেখুন। Failure-এর notice পাওয়া না গেলে dashboard-এ নিয়মিত status review-এর দায়িত্ব রাখুন। Notification-এর subject বা sender spam-এ যাচ্ছে কি না পরীক্ষাও প্রয়োজন। ভালো backup system নীরবে কয়েক সপ্তাহ ব্যর্থ হয়ে থাকলে তার সুবিধা পাওয়া যায় না।
শুধু mail এসেছে বলেই archive ভালো ধরে নেবেন না। Notification, tool log ও storage copy তিনটি মিলিয়ে দেখুন। কয়েকটি successful run-এর পর একটি sample restore করুন। সেই test-এর date ও result ছোট নোটে রাখুন। পরে system বদলালে পুরোনো test-কে নতুন ব্যবস্থার প্রমাণ হিসেবে ব্যবহার করবেন না। নতুন storage বা encryption settings-এর accessও আবার যাচাই করতে হবে।
Developer পরিবর্তনের সময় backup handover
নতুন developer কাজ ধরলে website কোথায় host করা, backup কোথায় রাখা এবং শেষ successful restore test কবে হয়েছে জানিয়ে দিন। Contract শেষের দিন ব্যক্তিগত cloud account থেকে file share বন্ধ হয়ে গেলে backup অপ্রাপ্য হতে পারে। তাই business-এর নিয়ন্ত্রণে final copy ও প্রয়োজনীয় access রাখুন। আলাদা billing বা subscription developer-এর account-এ আছে কি না দেখুন।
Handover-এর সময় একসঙ্গে সব password plain text-এ পাঠাবেন না। Secure access ব্যবস্থা ব্যবহার করুন এবং কাজ শেষের পর প্রয়োজনমতো permission বদলান। পুরোনো temporary archive public server-এ পড়ে আছে কি না review করুন। নতুন team-কে একটি test environment-এ প্রয়োজনীয় recovery step শুরু করতে বললে documentation-এর ঘাটতি বোঝা যায়। এর ফলে ব্যক্তিনির্ভরতার বদলে প্রতিষ্ঠান একটি ব্যবহারযোগ্য recovery process পায়।
Recovery শুরু করার আগে চারটি প্রশ্ন
প্রথম প্রশ্ন, কোন ঘটনার আগে ফিরতে হবে? দ্বিতীয় প্রশ্ন, সেই সময়ের পরিষ্কার copy আছে কি? তৃতীয় প্রশ্ন, restore-এর কারণে নতুন কোন data হারাতে পারে? চতুর্থ প্রশ্ন, কাজ শেষে সফলতা কীভাবে যাচাই করা হবে? এই উত্তরগুলো না জেনে বড় restore শুরু করলে মূল সমস্যার পাশাপাশি নতুন সমস্যা তৈরি হতে পারে।
একটি ছোট recovery ticket-এ সিদ্ধান্ত, নির্বাচিত backup point এবং দায়িত্বপ্রাপ্ত ব্যক্তির নাম লিখুন। পুরোনো site ফিরে এলে customer-facing page ও গুরুত্বপূর্ণ backend কাজ দুটোই দেখুন। শুধু homepage screenshot দিয়ে recovery সম্পূর্ণ ঘোষণা করবেন না। Mail, login, form বা checkout-এর যে অংশ ব্যবসার জন্য জরুরি, সেগুলোর test result রাখুন। ফল অসম্পূর্ণ হলে বর্তমান অবস্থার নতুন copy রেখে পরের পদক্ষেপ নিন।
সাধারণ প্রশ্ন
একই hosting-এ backup রাখলেই হবে?
প্রাথমিক সুবিধা হতে পারে, কিন্তু একই account বা server-এর সমস্যায় original ও copy একসঙ্গে অপ্রাপ্য হতে পারে। ব্যবসার প্রয়োজনমতো স্বাধীন copy ও access ব্যবস্থা রাখুন।
Backup plugin বন্ধ করলে পুরোনো backup থাকবে?
Tool ও storage policy-র ওপর নির্ভর করে। Deactivate বা subscription cancel করার আগে archive কোথায় আছে এবং পরে কীভাবে restore করবেন তা যাচাই করুন।
দৈনিক backup কি online shop-এর জন্য যথেষ্ট?
Order volume ও গ্রহণযোগ্য data loss-এর ওপর নির্ভর করে। সারাদিনের order হারানো গ্রহণযোগ্য না হলে আরও ঘন backup বা উপযুক্ত recovery ব্যবস্থা বিবেচনা করতে হবে।
কতদিন পর restore test করব?
ব্যবসার ঝুঁকি ও পরিবর্তনের ভিত্তিতে সময় ঠিক করুন। নতুন backup system, migration বা বড় configuration change-এর পর একটি test বিশেষভাবে কাজে লাগে।