ব্যাকআপ পার্ট 7: উপসংহার

এই নোট ব্যাকআপ সম্পর্কে চক্র সম্পূর্ণ করে। এটি একটি ডেডিকেটেড সার্ভারের (বা VPS) যৌক্তিক সংগঠন নিয়ে আলোচনা করবে, ব্যাকআপের জন্য সুবিধাজনক, এবং দুর্যোগের ক্ষেত্রে খুব বেশি ডাউনটাইম ছাড়াই একটি ব্যাকআপ থেকে দ্রুত একটি সার্ভার পুনরুদ্ধার করার জন্য একটি বিকল্প অফার করবে৷

কাঁচা তথ্য

একটি ডেডিকেটেড সার্ভারে প্রায়শই কমপক্ষে দুটি হার্ড ড্রাইভ থাকে যা একটি প্রথম-স্তরের RAID অ্যারে (মিরর) সংগঠিত করতে পরিবেশন করে। একটি ডিস্ক ব্যর্থ হলে সার্ভার পরিচালনা চালিয়ে যেতে সক্ষম হওয়ার জন্য এটি প্রয়োজনীয়। এটি একটি নিয়মিত ডেডিকেটেড সার্ভার হলে, SSD-তে সক্রিয় ক্যাশিং প্রযুক্তি সহ একটি পৃথক হার্ডওয়্যার RAID কন্ট্রোলার থাকতে পারে, যাতে নিয়মিত হার্ড ড্রাইভ ছাড়াও, এক বা একাধিক SSD সংযুক্ত করা যায়। কখনও কখনও ডেডিকেটেড সার্ভার দেওয়া হয়, যেখানে শুধুমাত্র স্থানীয় ডিস্কগুলি হল SATADOM (ছোট ডিস্ক, কাঠামোগতভাবে একটি SATA পোর্টের সাথে সংযুক্ত একটি ফ্ল্যাশ ড্রাইভ), বা এমনকি একটি সাধারণ ছোট (8-16GB) ফ্ল্যাশ ড্রাইভ একটি বিশেষ অভ্যন্তরীণ পোর্টের সাথে সংযুক্ত, এবং ডেটা স্টোরেজ সিস্টেম থেকে নেওয়া হয়, একটি ডেডিকেটেড স্টোরেজ নেটওয়ার্কের (ইথারনেট 10G, FC, ইত্যাদি) মাধ্যমে সংযুক্ত, এবং সেখানে ডেডিকেটেড সার্ভার রয়েছে যা স্টোরেজ সিস্টেম থেকে সরাসরি লোড করা হয়। আমি এই জাতীয় বিকল্পগুলি বিবেচনা করব না, যেহেতু এই জাতীয় ক্ষেত্রে সার্ভারের ব্যাক আপ করার কাজটি সঞ্চয়স্থান সিস্টেম বজায় রাখা বিশেষজ্ঞের কাছে চলে যায়; সাধারণত স্ন্যাপশট তৈরি করার জন্য বিভিন্ন মালিকানা প্রযুক্তি রয়েছে, বিল্ট-ইন ডিডপ্লিকেশন এবং সিস্টেম অ্যাডমিনিস্ট্রেটরের অন্যান্য আনন্দ। , এই সিরিজের আগের অংশে আলোচনা করা হয়েছে. সার্ভারের সাথে সংযুক্ত ডিস্কের সংখ্যা এবং আকারের উপর নির্ভর করে একটি ডেডিকেটেড সার্ভারের ডিস্ক অ্যারের ভলিউম কয়েক দশ টেরাবাইটে পৌঁছাতে পারে। VPS-এর ক্ষেত্রে, ভলিউমগুলি আরও শালীন: সাধারণত 100GB-এর বেশি নয় (কিন্তু আরও কিছু আছে), এবং এই ধরনের VPS-এর জন্য ট্যারিফগুলি একই হোস্টারের সবচেয়ে সস্তা ডেডিকেটেড সার্ভারের তুলনায় সহজেই বেশি ব্যয়বহুল হতে পারে। একটি VPS প্রায়শই একটি ডিস্ক থাকে, কারণ এটির নীচে একটি স্টোরেজ সিস্টেম (বা হাইপারকনভার্জড কিছু) থাকবে। কখনও কখনও একটি ভিপিএসের বিভিন্ন বৈশিষ্ট্য সহ বিভিন্ন ডিস্ক থাকে, বিভিন্ন উদ্দেশ্যে:

• ছোট সিস্টেম - অপারেটিং সিস্টেম ইনস্টল করার জন্য;
• বড় - ব্যবহারকারীর ডেটা সংরক্ষণ করা

যখন আপনি নিয়ন্ত্রণ প্যানেল ব্যবহার করে সিস্টেমটি পুনরায় ইনস্টল করেন, ব্যবহারকারীর ডেটা সহ ডিস্কটি ওভাররাইট করা হয় না, তবে সিস্টেম ডিস্কটি সম্পূর্ণরূপে পুনরায় পূরণ করা হয়। এছাড়াও, একটি ভিপিএসের ক্ষেত্রে, হোস্টার একটি বোতাম অফার করতে পারে যা ভিপিএস (বা ডিস্ক) এর অবস্থার একটি স্ন্যাপশট নেয়, তবে আপনি যদি নিজের অপারেটিং সিস্টেম ইনস্টল করেন বা ভিপিএস-এর ভিতরে পছন্দসই পরিষেবা সক্রিয় করতে ভুলে যান, কিছু তথ্য এখনও হারিয়ে যেতে পারে. বোতাম ছাড়াও, একটি ডেটা স্টোরেজ পরিষেবা সাধারণত অফার করা হয়, প্রায়শই খুব সীমিত। সাধারণত এটি FTP বা SFTP-এর মাধ্যমে অ্যাক্সেস সহ একটি অ্যাকাউন্ট, কখনও কখনও SSH-এর সাথে, একটি স্ট্রাইপ-ডাউন শেল (উদাহরণস্বরূপ, rbash), অথবা অনুমোদিত_কি (ForcedCommand এর মাধ্যমে) এর মাধ্যমে কমান্ড চালানোর উপর সীমাবদ্ধতা।

একটি ডেডিকেটেড সার্ভার 1 জিবিপিএস গতি সহ দুটি পোর্ট দ্বারা নেটওয়ার্কের সাথে সংযুক্ত থাকে, কখনও কখনও এগুলি 10 জিবিপিএস গতির কার্ড হতে পারে। VPS প্রায়ই একটি নেটওয়ার্ক ইন্টারফেস আছে. প্রায়শই, ডেটা সেন্টারগুলি ডেটা সেন্টারের মধ্যে নেটওয়ার্কের গতি সীমাবদ্ধ করে না, তবে তারা ইন্টারনেট অ্যাক্সেসের গতি সীমিত করে।

এই ধরনের একটি ডেডিকেটেড সার্ভার বা VPS এর সাধারণ লোড হল একটি ওয়েব সার্ভার, একটি ডাটাবেস এবং একটি অ্যাপ্লিকেশন সার্ভার। কখনও কখনও ওয়েব সার্ভার বা ডাটাবেস সহ: সার্চ ইঞ্জিন, মেল সিস্টেম ইত্যাদির জন্য বিভিন্ন অতিরিক্ত সহায়ক পরিষেবা ইনস্টল করা হতে পারে।

একটি বিশেষভাবে প্রস্তুত সার্ভার ব্যাকআপ কপি সংরক্ষণের জন্য একটি স্থান হিসাবে কাজ করে; আমরা এটি সম্পর্কে পরে আরও বিশদে লিখব।

ডিস্ক সিস্টেমের যৌক্তিক সংগঠন

আপনার যদি একটি RAID কন্ট্রোলার থাকে, বা একটি ডিস্ক সহ একটি VPS থাকে এবং ডিস্ক সাবসিস্টেম পরিচালনার জন্য কোন বিশেষ পছন্দ না থাকে (উদাহরণস্বরূপ, ডাটাবেসের জন্য একটি পৃথক দ্রুত ডিস্ক), সমস্ত ফাঁকা স্থান নিম্নরূপ বিভক্ত করা হয়: একটি পার্টিশন তৈরি করা হয়, এবং এর উপরে একটি LVM ভলিউম গ্রুপ তৈরি করা হয়, এতে বেশ কয়েকটি ভলিউম তৈরি করা হয়: একই আকারের 2টি ছোট, রুট ফাইল সিস্টেম হিসাবে ব্যবহৃত হয় (দ্রুত রোলব্যাকের সম্ভাবনার জন্য আপডেটের সময় একে একে পরিবর্তন করা হয়, ধারণাটি ক্যালকুলেট লিনাক্স ডিস্ট্রিবিউশন থেকে নেওয়া হয়েছিল), আরেকটি হল অদলবদল পার্টিশনের জন্য, বাকি ফাঁকা স্থানটি ছোট ভলিউমে বিভক্ত, পূর্ণাঙ্গ পাত্রে রুট ফাইল সিস্টেম হিসাবে ব্যবহৃত হয়, ভার্চুয়াল মেশিনের জন্য ডিস্ক, ফাইল /home-এ অ্যাকাউন্টগুলির জন্য সিস্টেম (প্রতিটি অ্যাকাউন্টের নিজস্ব ফাইল সিস্টেম আছে), অ্যাপ্লিকেশন কন্টেইনারগুলির জন্য ফাইল সিস্টেম।

গুরুত্বপূর্ণ নোট: ভলিউম সম্পূর্ণরূপে স্বয়ংসম্পূর্ণ হতে হবে, যেমন একে অপরের উপর বা রুট ফাইল সিস্টেমের উপর নির্ভর করা উচিত নয়। ভার্চুয়াল মেশিন বা পাত্রের ক্ষেত্রে, এই পয়েন্টটি স্বয়ংক্রিয়ভাবে পরিলক্ষিত হয়। যদি এগুলি অ্যাপ্লিকেশন কন্টেইনার বা হোম ডিরেক্টরি হয়, তাহলে আপনার ওয়েব সার্ভার এবং অন্যান্য পরিষেবাগুলির কনফিগারেশন ফাইলগুলিকে এমনভাবে আলাদা করার বিষয়ে চিন্তা করা উচিত যাতে যতটা সম্ভব ভলিউমের মধ্যে নির্ভরতা দূর করা যায়। উদাহরণস্বরূপ, প্রতিটি সাইট তার নিজস্ব ব্যবহারকারী থেকে চলে, সাইট কনফিগারেশন ফাইলগুলি ব্যবহারকারীর হোম ডিরেক্টরিতে থাকে, ওয়েব সার্ভার সেটিংসে, সাইট কনফিগারেশন ফাইলগুলি /etc/nginx/conf.d/ এর মাধ্যমে অন্তর্ভুক্ত করা হয় না.conf, এবং, উদাহরণস্বরূপ, /home//configs/nginx/*.conf

যদি বেশ কয়েকটি ডিস্ক থাকে তবে আপনি একটি সফ্টওয়্যার RAID অ্যারে তৈরি করতে পারেন (এবং প্রয়োজন এবং সুযোগ থাকলে এটির ক্যাশিং একটি SSD-তে কনফিগার করতে পারেন), যার উপরে আপনি উপরে প্রস্তাবিত নিয়ম অনুসারে LVM তৈরি করতে পারেন। এছাড়াও এই ক্ষেত্রে, আপনি ZFS বা BtrFS ব্যবহার করতে পারেন, তবে আপনার এটি সম্পর্কে দুবার চিন্তা করা উচিত: উভয়ের জন্যই সংস্থানগুলির জন্য আরও গুরুতর পদ্ধতির প্রয়োজন, এবং পাশাপাশি, ZFS লিনাক্স কার্নেলের সাথে অন্তর্ভুক্ত নয়।

স্কিম ব্যবহার করা যাই হোক না কেন, ডিস্কে পরিবর্তন লেখার আনুমানিক গতি আগে থেকে অনুমান করা এবং তারপর স্ন্যাপশট তৈরির জন্য সংরক্ষিত খালি স্থানের পরিমাণ গণনা করা সর্বদা মূল্যবান। উদাহরণস্বরূপ, যদি আমাদের সার্ভার প্রতি সেকেন্ডে 10 মেগাবাইট গতিতে ডেটা লেখে এবং পুরো ডেটা অ্যারের আকার 10 টেরাবাইট হয় - সিঙ্ক্রোনাইজেশন সময় একদিনে পৌঁছাতে পারে (22 ঘন্টা - এটি কতটা এই ধরনের ভলিউম স্থানান্তরিত হবে) নেটওয়ার্কে 1 জিবিপিএস) - এটি প্রায় 800 জিবি সংরক্ষণের মূল্য। বাস্তবে, চিত্রটি ছোট হবে; আপনি নিরাপদে লজিক্যাল ভলিউমের সংখ্যা দ্বারা ভাগ করতে পারেন।

ব্যাকআপ স্টোরেজ সার্ভার ডিভাইস

ব্যাকআপ কপি সংরক্ষণের জন্য একটি সার্ভারের মধ্যে প্রধান পার্থক্য হল এর বড়, সস্তা এবং অপেক্ষাকৃত ধীরগতির ডিস্ক। যেহেতু আধুনিক HDDগুলি ইতিমধ্যেই একটি ডিস্কে 10TB বার অতিক্রম করেছে, তাই চেকসাম সহ ফাইল সিস্টেম বা RAID ব্যবহার করা প্রয়োজন, কারণ অ্যারের পুনর্নির্মাণ বা ফাইল সিস্টেম পুনরুদ্ধারের সময় (বেশ কয়েক দিন!) দ্বিতীয় ডিস্কটি ব্যর্থ হতে পারে। বর্ধিত লোডের জন্য। 1TB পর্যন্ত ক্ষমতা সম্পন্ন ডিস্কে এটি এতটা সংবেদনশীল ছিল না। বর্ণনার সরলতার জন্য, আমি অনুমান করি যে ডিস্কের স্থানটি প্রায় সমান আকারের দুটি অংশে বিভক্ত (আবার, উদাহরণস্বরূপ, LVM ব্যবহার করে):

• ব্যবহারকারীর ডেটা সঞ্চয় করার জন্য ব্যবহৃত সার্ভারের সাথে সম্পর্কিত ভলিউম (যার শেষ ব্যাকআপটি যাচাইকরণের জন্য তাদের উপর স্থাপন করা হবে);
• BorgBackup সংগ্রহস্থল হিসাবে ব্যবহৃত ভলিউম (ব্যাকআপের জন্য ডেটা সরাসরি এখানে যাবে)।

অপারেশন নীতি হল BorgBackup সংগ্রহস্থলের জন্য প্রতিটি সার্ভারের জন্য পৃথক ভলিউম তৈরি করা হয়, যেখানে যুদ্ধ সার্ভার থেকে ডেটা যাবে। রিপোজিটরিগুলি শুধুমাত্র-সংযোজন মোডে কাজ করে, যা ইচ্ছাকৃতভাবে ডেটা মুছে ফেলার সম্ভাবনাকে বাদ দেয় এবং পুরানো ব্যাকআপগুলি থেকে সংগ্রহস্থলগুলির অনুলিপি এবং পর্যায়ক্রমিক পরিষ্কারের কারণে (বার্ষিক অনুলিপিগুলি থাকে, গত বছরের জন্য মাসিক, গত মাসের জন্য সাপ্তাহিক, প্রতিদিনের জন্য গত সপ্তাহে, সম্ভবত বিশেষ ক্ষেত্রে - শেষ দিনের জন্য প্রতি ঘণ্টায়: মোট 24 + 7 + 4 + 12 + বার্ষিক - প্রতিটি সার্ভারের জন্য প্রায় 50 কপি)।
BorgBackup সংগ্রহস্থলগুলি শুধুমাত্র-সংযোজন মোড সক্ষম করে না; পরিবর্তে, .ssh/authorized_keys-এ একটি ForcedCommand এইরকম কিছু ব্যবহার করা হয়:

from="адрес сервера",command="/usr/local/bin/borg serve --append-only --restrict-to-path /home/servername/borgbackup/",no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-user-rc AAAAA.......

নির্দিষ্ট পথটিতে বোর্গের উপরে একটি র‍্যাপার স্ক্রিপ্ট রয়েছে, যা প্যারামিটার সহ বাইনারি চালু করার পাশাপাশি ডেটা সরানোর পরে ব্যাকআপ কপি পুনরুদ্ধার করার প্রক্রিয়া শুরু করে। এটি করার জন্য, র্যাপার স্ক্রিপ্ট সংশ্লিষ্ট সংগ্রহস্থলের পাশে একটি ট্যাগ ফাইল তৈরি করে। শেষ ব্যাকআপটি স্বয়ংক্রিয়ভাবে ডেটা পূরণের প্রক্রিয়া সম্পন্ন হওয়ার পরে সংশ্লিষ্ট লজিক্যাল ভলিউমে পুনরুদ্ধার করা হয়।

এই ডিজাইনটি আপনাকে পর্যায়ক্রমে অপ্রয়োজনীয় ব্যাকআপগুলি পরিষ্কার করার অনুমতি দেয় এবং ব্যাকআপ স্টোরেজ সার্ভারে কিছু মুছে ফেলা থেকে লড়াইয়ের সার্ভারগুলিকেও বাধা দেয়।

ব্যাকআপ প্রক্রিয়া

ব্যাকআপের সূচনাকারী হল ডেডিকেটেড সার্ভার বা ভিপিএস, যেহেতু এই স্কিমটি এই সার্ভারের অংশে ব্যাকআপ প্রক্রিয়ার উপর আরও নিয়ন্ত্রণ দেয়। প্রথমে, সক্রিয় রুট ফাইল সিস্টেমের অবস্থার একটি স্ন্যাপশট নেওয়া হয়, যা মাউন্ট করা হয় এবং ব্যাকআপ স্টোরেজ সার্ভারে BorgBackup ব্যবহার করে আপলোড করা হয়। ডেটা ক্যাপচার সম্পন্ন হওয়ার পরে, স্ন্যাপশটটি আনমাউন্ট করা হয় এবং মুছে ফেলা হয়।

যদি একটি ছোট ডাটাবেস থাকে (প্রতিটি সাইটের জন্য 1 গিগাবাইট পর্যন্ত), একটি ডাটাবেস ডাম্প তৈরি করা হয়, যা উপযুক্ত লজিক্যাল ভলিউমে সংরক্ষিত হয়, যেখানে একই সাইটের জন্য বাকি ডেটা অবস্থিত থাকে, কিন্তু যাতে ডাম্প হয় ওয়েব সার্ভারের মাধ্যমে অ্যাক্সেসযোগ্য নয়। যদি ডাটাবেসগুলি বড় হয়, তাহলে আপনাকে "হট" ডেটা অপসারণ কনফিগার করতে হবে, উদাহরণস্বরূপ, MySQL-এর জন্য xtrabackup ব্যবহার করে, অথবা PostgreSQL-এ archive_command সহ WAL-এর সাথে কাজ করুন৷ এই ক্ষেত্রে, ডেটাবেস সাইট ডেটা থেকে আলাদাভাবে পুনরুদ্ধার করা হবে।

যদি কন্টেইনার বা ভার্চুয়াল মেশিন ব্যবহার করা হয়, তাহলে আপনাকে qemu-অতিথি-এজেন্ট, CRIU বা অন্যান্য প্রয়োজনীয় প্রযুক্তি কনফিগার করতে হবে। অন্যান্য ক্ষেত্রে, অতিরিক্ত সেটিংস প্রায়শই প্রয়োজন হয় না - আমরা কেবল লজিক্যাল ভলিউমের স্ন্যাপশট তৈরি করি, যা তারপরে রুট ফাইল সিস্টেমের অবস্থার স্ন্যাপশটের মতো একইভাবে প্রক্রিয়া করা হয়। ডেটা নেওয়ার পরে, ছবিগুলি মুছে ফেলা হয়।

ব্যাকআপ স্টোরেজ সার্ভারে আরও কাজ করা হয়:

• প্রতিটি সংগ্রহস্থলে তৈরি শেষ ব্যাকআপ চেক করা হয়,
• একটি মার্ক ফাইলের উপস্থিতি পরীক্ষা করা হয়, ইঙ্গিত করে যে ডেটা সংগ্রহ প্রক্রিয়া সম্পন্ন হয়েছে,
• ডেটা সংশ্লিষ্ট স্থানীয় ভলিউমে প্রসারিত হয়,
• ট্যাগ ফাইল মুছে ফেলা হয়

সার্ভার পুনরুদ্ধার প্রক্রিয়া

যদি প্রধান সার্ভার মারা যায়, তাহলে একটি অনুরূপ ডেডিকেটেড সার্ভার চালু হয়, যা কিছু স্ট্যান্ডার্ড ইমেজ থেকে বুট হয়। সম্ভবত ডাউনলোডটি নেটওয়ার্কের মাধ্যমে সঞ্চালিত হবে, তবে সার্ভার সেট আপ করা ডেটা সেন্টার প্রযুক্তিবিদ অবিলম্বে এই মানক চিত্রটিকে একটি ডিস্কে অনুলিপি করতে পারেন। ডাউনলোডটি RAM এ ঘটে, যার পরে পুনরুদ্ধার প্রক্রিয়া শুরু হয়:

• মৃত সার্ভারের রুট ফাইল সিস্টেম ধারণকারী লজিক্যাল ভলিউমের সাথে iscsinbd বা অন্য অনুরূপ প্রোটোকলের মাধ্যমে একটি ব্লক ডিভাইস সংযুক্ত করার জন্য একটি অনুরোধ করা হয়; যেহেতু রুট ফাইল সিস্টেম ছোট হতে হবে, এই ধাপটি কয়েক মিনিটের মধ্যে সম্পন্ন করা উচিত। বুটলোডারটিও পুনরুদ্ধার করা হয়েছে;
• স্থানীয় লজিক্যাল ভলিউমগুলির গঠন পুনরায় তৈরি করা হয়, লজিক্যাল ভলিউমগুলি ব্যাকআপ সার্ভার থেকে dm_clone কার্নেল মডিউল ব্যবহার করে সংযুক্ত করা হয়: ডেটা পুনরুদ্ধার শুরু হয়, এবং পরিবর্তনগুলি স্থানীয় ডিস্কগুলিতে অবিলম্বে লেখা হয়
• সমস্ত উপলব্ধ শারীরিক ডিস্কগুলির সাথে একটি ধারক চালু করা হয়েছে - সার্ভারের কার্যকারিতা সম্পূর্ণরূপে পুনরুদ্ধার করা হয়েছে, তবে কর্মক্ষমতা হ্রাস সহ;
• ডেটা সিঙ্ক্রোনাইজেশন সম্পন্ন হওয়ার পরে, ব্যাকআপ সার্ভার থেকে লজিক্যাল ভলিউমগুলি সংযোগ বিচ্ছিন্ন করা হয়, ধারকটি বন্ধ করা হয় এবং সার্ভারটি পুনরায় বুট করা হয়;

রিবুট করার পরে, সার্ভারে ব্যাকআপ তৈরির সময় থাকা সমস্ত ডেটা থাকবে এবং পুনরুদ্ধার প্রক্রিয়া চলাকালীন করা সমস্ত পরিবর্তনগুলিও এতে অন্তর্ভুক্ত থাকবে।

সিরিজের অন্যান্য নিবন্ধ

ব্যাকআপ, পার্ট 1: কেন ব্যাকআপ প্রয়োজন, পদ্ধতি, প্রযুক্তি পর্যালোচনা
ব্যাকআপ পার্ট 2: rsync-ভিত্তিক ব্যাকআপ টুল পর্যালোচনা এবং পরীক্ষা করা
ব্যাকআপ পার্ট 3: ডুপ্লিসিটির রিভিউ এবং টেস্টিং, ডুপ্লিকাটি
ব্যাকআপ পার্ট 4: Zbackup, restic, borgbackup পর্যালোচনা এবং পরীক্ষা
ব্যাকআপ পার্ট 5: লিনাক্সের জন্য ব্যাকুলা এবং ভিম ব্যাকআপ পরীক্ষা করা
ব্যাকআপ: পাঠকদের অনুরোধে অংশ: AMANDA, UrBackup, BackupPC-এর পর্যালোচনা
ব্যাকআপ পার্ট 6: ব্যাকআপ টুলের তুলনা
ব্যাকআপ পার্ট 7: উপসংহার

আমি আপনাকে মন্তব্যে প্রস্তাবিত বিকল্প নিয়ে আলোচনা করার জন্য আমন্ত্রণ জানাই, আপনার মনোযোগের জন্য আপনাকে ধন্যবাদ!

উত্স: www.habr.com