🥇আরো একটি ব্যাকআপ - একটি স্ক্রিপ্টের চেয়ে বেশি, একটি সিস্টেমের চেয়ে সহজ

অনেক ব্যাকআপ সিস্টেম আছে, কিন্তু যদি সার্ভিসড সার্ভারগুলি বিভিন্ন অঞ্চল এবং ক্লায়েন্ট জুড়ে ছড়িয়ে ছিটিয়ে থাকে এবং আপনাকে অপারেটিং সিস্টেম টুল ব্যবহার করে পরিচালনা করতে হয়?

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

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

রেডিমেড সমাধানগুলি বিভিন্ন কারণে মানায় না: ব্যাকআপগুলিকে বিকেন্দ্রীকরণ করার প্রয়োজনীয়তার কারণে, ক্লায়েন্টে স্থানীয়ভাবে ব্যাকআপগুলি সঞ্চয় করার বাধ্যবাধকতা, সেটিংসের জটিলতা, আমদানি প্রতিস্থাপন এবং অ্যাক্সেসের বিধিনিষেধ।

আমাদের কাছে মনে হয়েছিল যে আমাদের নিজস্ব কিছু লেখা সহজ। একই সময়ে, আমরা এমন কিছু পেতে চেয়েছিলাম যা পরবর্তী N বছরের জন্য আমাদের পরিস্থিতির জন্য যথেষ্ট হবে, কিন্তু সম্ভাব্যভাবে সুযোগ প্রসারিত করার সম্ভাবনা সহ।

কাজের শর্তগুলি নিম্নরূপ ছিল:

বেস ব্যাকআপ ইনস্ট্যান্স অফলাইন, স্থানীয়ভাবে চলছে
ব্যাকআপ এবং লগের সঞ্চয়স্থান সর্বদা ক্লায়েন্টের নেটওয়ার্কের মধ্যে
উদাহরণটি মডিউল নিয়ে গঠিত - এই ধরনের "কন্সট্রাক্টর"
অপ্রচলিতগুলি সহ ব্যবহৃত লিনাক্স বিতরণগুলির সাথে সামঞ্জস্য, সম্ভাব্য ক্রস-প্ল্যাটফর্ম বাঞ্ছনীয়
উদাহরণের সাথে কাজ করার জন্য ssh অ্যাক্সেস যথেষ্ট, অতিরিক্ত পোর্ট খোলা ঐচ্ছিক
সেটআপ এবং অপারেশন সর্বাধিক সহজ
একটি পৃথক উদাহরণ থাকা সম্ভব (কিন্তু প্রয়োজনীয় নয়) যা আপনাকে কেন্দ্রীয়ভাবে বিভিন্ন সার্ভার থেকে ব্যাকআপের স্থিতি দেখতে দেয়

আমরা যা পেয়েছি তা এখানে দেখা যাবে: github.com/javister/krista-backup
সফ্টওয়্যারটি python3 এ লেখা আছে; Debian, Ubuntu, CentOS, AstraLinux 1.6 এ কাজ করে।

ডকুমেন্টেশন সংগ্রহস্থলের ডক্স ডিরেক্টরিতে পোস্ট করা হয়।

সিস্টেমটি কাজ করে এমন প্রধান ধারণাগুলি:
কর্ম - একটি ক্রিয়া যা একটি পারমাণবিক ক্রিয়াকলাপ প্রয়োগ করে (ডাটাবেস ব্যাকআপ, ডিরেক্টরি ব্যাকআপ, ডিরেক্টরি A থেকে ডিরেক্টরি B তে স্থানান্তর ইত্যাদি)। বিদ্যমান ক্রিয়াগুলি মূল/ক্রিয়া ডিরেক্টরিতে রয়েছে৷
টাস্ক - একটি টাস্ক, ক্রিয়াগুলির একটি সেট যা একটি যৌক্তিক "ব্যাকআপ টাস্ক" বর্ণনা করে
সময়সূচী - সময়সূচী, টাস্ক সম্পাদনের সময়ের ঐচ্ছিক ইঙ্গিত সহ টাস্ক সেট

ব্যাকআপ কনফিগারেশন একটি yaml ফাইলে সংরক্ষণ করা হয়; সাধারণ কনফিগারেশন কাঠামো:

সাধারণ সেটিংস
কর্ম বিভাগ: এই সার্ভারে ব্যবহৃত কর্মের বর্ণনা
সময়সূচী বিভাগ: সমস্ত কাজের বিবরণ (ক্রিয়াগুলির সেট) এবং ক্রোন দ্বারা তাদের লঞ্চের সময়সূচী, যদি এই ধরনের লঞ্চের প্রয়োজন হয়

একটি উদাহরণ কনফিগারেশন এখানে পাওয়া যাবে

এই মুহূর্তে অ্যাপ্লিকেশনটি কী করতে পারে:

আমাদের জন্য প্রধান ক্রিয়াকলাপগুলি সমর্থিত: pg_dump এর মাধ্যমে PostgreSQL ব্যাকআপ, tar এর মাধ্যমে ফাইল সিস্টেম ডিরেক্টরি ব্যাকআপ; বাহ্যিক স্টোরেজ সহ অপারেশন; ডিরেক্টরির মধ্যে rsync; ব্যাকআপ ঘূর্ণন (পুরানো কপি মুছে ফেলা)
একটি বহিরাগত স্ক্রিপ্ট কলিং
একটি একক কাজের ম্যানুয়াল সঞ্চালন
```
/opt/KristaBackup/KristaBackup.py run make_full_dump
```
আপনি ক্রনট্যাবে একটি পৃথক টাস্ক বা সম্পূর্ণ সময়সূচী যোগ (বা সরাতে) করতে পারেন
```
/opt/KristaBackup/KristaBackup.py enable all
```
ব্যাকআপ ফলাফলের উপর ভিত্তি করে ফাইল জেনারেশন ট্রিগার করুন। এই বৈশিষ্ট্যটি ব্যাকআপ নিরীক্ষণের জন্য Zabbix-এর সাথে একত্রে উপযোগী।
ওয়েবাপি বা ওয়েব মোডে ব্যাকগ্রাউন্ডে কাজ করতে পারে
```
/opt/KristaBackup/KristaBackup.py web start [--api]
```

মোডগুলির মধ্যে পার্থক্য হল যে ওয়েবাপির একটি সঠিক ওয়েব ইন্টারফেস নেই, তবে অ্যাপ্লিকেশনটি অন্য একটি উদাহরণের অনুরোধে সাড়া দেয়। ওয়েব মোডের জন্য, আপনাকে ফ্লাস্ক এবং কয়েকটি অতিরিক্ত প্যাকেজ ইনস্টল করতে হবে এবং এটি সর্বত্র গ্রহণযোগ্য নয়, উদাহরণস্বরূপ, প্রত্যয়িত AstraLinux SE-তে।

ওয়েব ইন্টারফেসের মাধ্যমে, আপনি সংযুক্ত সার্ভারগুলির ব্যাকআপগুলির স্থিতি এবং লগগুলি দেখতে পারেন: "ওয়েব ইনস্ট্যান্স" API এর মাধ্যমে "ব্যাকআপ দৃষ্টান্ত" থেকে ডেটা অনুরোধ করে৷ ওয়েব অ্যাক্সেসের জন্য অনুমোদনের প্রয়োজন, ওয়েবপি অ্যাক্সেস নেই।

ভুলভাবে অতীতের ব্যাকআপগুলির লগগুলি একটি রঙ দিয়ে চিহ্নিত করা হয়েছে: সতর্কতা - হলুদ, ত্রুটি - লাল৷

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

আমরা এই ইউটিলিটিটি মূলত Ansible-এর মাধ্যমে বিতরণ করি, এটিকে প্রথমে কিছু কম গুরুত্বপূর্ণ সার্ভারে রোল আউট করি, এবং বাকি সকলে পরীক্ষা করার পরে।

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

উত্স: www.habr.com

আরেকটি ব্যাকআপ - একটি স্ক্রিপ্টের চেয়ে বেশি, একটি সিস্টেমের চেয়ে সহজ

একটি মন্তব্য জুড়ুন উত্তর বাতিল