ব্যাকআপ পার্ট 3: ডুপ্লিসিটির রিভিউ এবং টেস্টিং, ডুপ্লিকাটি

এই নোটটি ব্যাকআপ সরঞ্জামগুলি নিয়ে আলোচনা করে যা একটি ব্যাকআপ সার্ভারে সংরক্ষণাগার তৈরি করে ব্যাকআপ সম্পাদন করে৷

যেগুলি প্রয়োজনীয়তা পূরণ করে তাদের মধ্যে রয়েছে ডুপ্লিসিটি (যার দেজা ডুপ আকারে একটি চমৎকার ইন্টারফেস রয়েছে) এবং ডুপ্লিকাটি।

আরেকটি খুব উল্লেখযোগ্য ব্যাকআপ টুল হল ডার, কিন্তু যেহেতু এটিতে বিকল্পগুলির একটি খুব বিস্তৃত তালিকা রয়েছে - পরীক্ষা পদ্ধতিটি যা করতে সক্ষম তার মাত্র 10% কভার করে - আমরা বর্তমান চক্রের অংশ হিসাবে এটি পরীক্ষা করছি না।

প্রত্যাশিত ফলাফল

যেহেতু উভয় প্রার্থীই কোনো না কোনো উপায়ে সংরক্ষণাগার তৈরি করে, তাই নিয়মিত টারকে গাইড হিসেবে ব্যবহার করা যেতে পারে।

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

ব্যাকআপ তৈরি করার সময় আচরণ:

1. ব্যাকআপ স্টোরেজ সার্ভারে তুলনামূলকভাবে অল্প সংখ্যক ফাইল (ব্যাকআপ কপির সংখ্যা বা GB তে ডেটার আকারের সাথে তুলনীয়), কিন্তু তাদের আকার বেশ বড় (দশ থেকে কয়েকশ মেগাবাইট)।
2. সংগ্রহস্থলের আকার শুধুমাত্র পরিবর্তনগুলি অন্তর্ভুক্ত করবে - কোনো সদৃশ সংরক্ষণ করা হবে না, তাই সংগ্রহস্থলের আকার rsync-ভিত্তিক সফ্টওয়্যারের তুলনায় ছোট হবে।
3. কম্প্রেশন এবং/অথবা এনক্রিপশন ব্যবহার করার সময় ভারী CPU লোড আশা করুন, এবং যদি সংরক্ষণাগার এবং/অথবা এনক্রিপশন প্রক্রিয়া ব্যাকআপ স্টোরেজ সার্ভারে চলমান থাকে তবে সম্ভবত বেশ উচ্চ নেটওয়ার্ক এবং ডিস্ক লোড হবে।

একটি রেফারেন্স মান হিসাবে নিম্নলিখিত কমান্ড রান করা যাক:

cd /src/dir; tar -cf - * | ssh backup_server "cat > /backup/dir/archive.tar"

মৃত্যুদন্ডের ফলাফল নিম্নরূপ ছিল:

কার্যকর করার সময় 3m12s। এটি দেখা যায় যে গতি ব্যাকআপ স্টোরেজ সার্ভারের ডিস্ক সাবসিস্টেম দ্বারা সীমিত, যেমন উদাহরণে rsync. শুধু একটু দ্রুত, কারণ... রেকর্ডিং একটি ফাইলে যায়।

এছাড়াও, কম্প্রেশন মূল্যায়ন করতে, আসুন একই বিকল্পটি চালাই, তবে ব্যাকআপ সার্ভারের দিকে কম্প্রেশন সক্ষম করুন:

cd /src/dir; tar -cf - * | ssh backup_server "gzip > /backup/dir/archive.tgz"

ফলাফল হল:

কার্যকর করার সময় 10m11s। সম্ভবত বটলনেক হল রিসিভিং এন্ডে একক-ফ্লো কম্প্রেসার।

একই কমান্ড, কিন্তু কম্প্রেশনের সাথে মূল ডেটা সহ সার্ভারে স্থানান্তরিত করে হাইপোথিসিস পরীক্ষা করার জন্য যে বটলনেক একটি একক-থ্রেডেড কম্প্রেসার।

cd /src/dir; tar -czf - * | ssh backup_server "cat > /backup/dir/archive.tgz"

এটি এই মত পরিণত হয়েছে:

মৃত্যুদন্ড কার্যকর করার সময় ছিল 9m37s। কম্প্রেসার দ্বারা একটি কোর উপর লোড স্পষ্টভাবে দৃশ্যমান, কারণ নেটওয়ার্ক স্থানান্তর গতি এবং সোর্স ডিস্ক সাবসিস্টেমের লোড একই রকম।

এনক্রিপশন মূল্যায়ন করতে, আপনি একটি অতিরিক্ত কমান্ড সংযুক্ত করে openssl বা gpg ব্যবহার করতে পারেন openssl বা gpg পাইপে রেফারেন্সের জন্য এই মত একটি কমান্ড থাকবে:

cd /src/dir; tar -cf - * | ssh backup_server "gzip | openssl enc -e -aes256 -pass pass:somepassword -out /backup/dir/archive.tgz.enc"

ফলাফল এই মত বেরিয়ে এসেছে:

সঞ্চালনের সময়টি 10m30s হতে দেখা গেছে, যেহেতু 2টি প্রসেস প্রাপ্তির দিকে চলছিল - বটলনেক আবার একটি একক-থ্রেডেড কম্প্রেসার, প্লাস ছোট এনক্রিপশন ওভারহেড।

ইউপিডি: bliznezz এর অনুরোধে আমি pigz এর সাথে পরীক্ষা যোগ করছি। আপনি যদি শুধুমাত্র কম্প্রেসার ব্যবহার করেন, তাহলে এটি 6m30s লাগবে, যদি আপনি এনক্রিপশন যোগ করেন, তাহলে এটি প্রায় 7m হবে। নীচের গ্রাফে ডিপ হল একটি আনফ্লুশড ডিস্ক ক্যাশে:

ডুপ্লিকেট টেস্টিং

ডুপ্লিসিটি হল টার ফরম্যাটে এনক্রিপ্ট করা আর্কাইভ তৈরি করে ব্যাকআপের জন্য একটি পাইথন সফটওয়্যার।

ক্রমবর্ধমান সংরক্ষণাগারগুলির জন্য, librsync ব্যবহার করা হয়, যাতে আপনি বর্ণিত আচরণ আশা করতে পারেন সিরিজের আগের পোস্ট.

ব্যাকআপগুলি gnupg ব্যবহার করে এনক্রিপ্ট করা এবং স্বাক্ষর করা যেতে পারে, যা ব্যাকআপ সংরক্ষণের জন্য বিভিন্ন প্রদানকারী ব্যবহার করার সময় গুরুত্বপূর্ণ (s3, ব্যাকব্লেজ, জিড্রাইভ, ইত্যাদি)

চলুন দেখে নেওয়া যাক ফলাফল কিঃ

এনক্রিপশন ছাড়াই চালানোর সময় আমরা এই ফলাফলগুলি পেয়েছি৷

স্পয়লার

প্রতিটি পরীক্ষার রানিং সময়:

লঞ্চ 1
লঞ্চ 2
লঞ্চ 3

16 মি 33 এস
17 মি 20 এস
16 মি 30 এস

8 মি 29 এস
9 মি 3 এস
8 মি 45 এস

5 মি 21 এস
6 মি 04 এস
5 মি 53 এস

এবং 2048 বিটের কী আকারের সাথে gnupg এনক্রিপশন সক্রিয় করা হলে ফলাফলগুলি এখানে রয়েছে:

এনক্রিপশন সহ একই ডেটাতে অপারেটিং সময়:

লঞ্চ 1
লঞ্চ 2
লঞ্চ 3

17 মি 22 এস
17 মি 32 এস
17 মি 28 এস

8 মি 52 এস
9 মি 13 এস
9 মি 3 এস

5 মি 48 এস
5 মি 40 এস
5 মি 30 এস

ব্লকের আকার নির্দেশিত হয়েছিল - 512 মেগাবাইট, যা গ্রাফগুলিতে স্পষ্টভাবে দৃশ্যমান; প্রসেসর লোড আসলে 50% এ রয়ে গেছে, যার মানে প্রোগ্রামটি একটির বেশি প্রসেসর কোর ব্যবহার করে না।

প্রোগ্রামটির অপারেশনের নীতিটিও বেশ স্পষ্টভাবে দৃশ্যমান: তারা ডেটার একটি অংশ নিয়েছিল, এটি সংকুচিত করেছিল এবং এটি একটি ব্যাকআপ স্টোরেজ সার্ভারে পাঠিয়েছিল, যা বেশ ধীর হতে পারে।
আরেকটি বৈশিষ্ট্য হল প্রোগ্রামের অনুমানযোগ্য চলমান সময়, যা শুধুমাত্র পরিবর্তিত ডেটার আকারের উপর নির্ভর করে।

এনক্রিপশন সক্রিয় করা প্রোগ্রামের চলমান সময়কে উল্লেখযোগ্যভাবে বৃদ্ধি করেনি, তবে এটি প্রসেসরের লোড প্রায় 10% বাড়িয়েছে, যা বেশ চমৎকার বোনাস হতে পারে।

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

ডুপ্লিকেট টেস্টিং

এই সফ্টওয়্যারটি C# এ লেখা এবং Mono থেকে লাইব্রেরির একটি সেট ব্যবহার করে চলে। একটি GUI পাশাপাশি একটি CLI সংস্করণ রয়েছে।

প্রধান বৈশিষ্ট্যগুলির আনুমানিক তালিকা বিভিন্ন ব্যাকআপ স্টোরেজ প্রদানকারী সহ ডুপ্লিসিটির অনুরূপ, তবে, সদৃশতার বিপরীতে, বেশিরভাগ বৈশিষ্ট্য তৃতীয়-পক্ষের সরঞ্জাম ছাড়াই উপলব্ধ। এটি একটি প্লাস বা বিয়োগ কিনা তা নির্দিষ্ট ক্ষেত্রে নির্ভর করে, তবে নতুনদের জন্য, পাইথনের জন্য অতিরিক্ত প্যাকেজগুলি ইনস্টল করার পরিবর্তে তাদের সামনে একযোগে সমস্ত বৈশিষ্ট্যের একটি তালিকা রাখা সম্ভবত সহজ। ডুপ্লিসিটির সাথে কেস।

আরেকটি ছোট সূক্ষ্মতা - প্রোগ্রামটি ব্যাকআপ শুরুকারী ব্যবহারকারীর পক্ষে সক্রিয়ভাবে একটি স্থানীয় স্কলাইট ডাটাবেস লেখে, তাই আপনাকে অতিরিক্ত নিশ্চিত করতে হবে যে প্রতিটি সময় cli ব্যবহার করে প্রক্রিয়া শুরু করার সময় প্রয়োজনীয় ডাটাবেস সঠিকভাবে নির্দিষ্ট করা হয়েছে। GUI বা WEBGUI এর মাধ্যমে কাজ করার সময়, ব্যবহারকারীর কাছ থেকে বিস্তারিত লুকানো হবে।

আসুন দেখি এই সমাধানটি কী সূচক তৈরি করতে পারে:

আপনি যদি এনক্রিপশন বন্ধ করেন (এবং WEBGUI এটি করার পরামর্শ দেয় না), ফলাফলগুলি নিম্নরূপ:

কাজের সময়:

লঞ্চ 1
লঞ্চ 2
লঞ্চ 3

20 মি 43 এস
20 মি 13 এস
20 মি 28 এস

5 মি 21 এস
5 মি 40 এস
5 মি 35 এস

7 মি 36 এস
7 মি 54 এস
7 মি 49 এস

এনক্রিপশন সক্ষম করে, aes ব্যবহার করে, এটি এইরকম দেখায়:

কাজের সময়:

লঞ্চ 1
লঞ্চ 2
লঞ্চ 3

29 মি 9 এস
30 মি 1 এস
29 মি 54 এস

5 মি 29 এস
6 মি 2 এস
5 মি 54 এস

8 মি 44 এস
9 মি 12 এস
9 মি 1 এস

এবং যদি আপনি বহিরাগত প্রোগ্রাম gnupg ব্যবহার করেন, নিম্নলিখিত ফলাফলগুলি বেরিয়ে আসে:

লঞ্চ 1
লঞ্চ 2
লঞ্চ 3

26 মি 6 এস
26 মি 35 এস
26 মি 17 এস

5 মি 20 এস
5 মি 48 এস
5 মি 40 এস

8 মি 12 এস
8 মি 42 এস
8 মি 15 এস

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

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

সামগ্রিকভাবে, নবাগতদের সাথে মোটামুটি বন্ধুত্বপূর্ণ হওয়া সহ প্রোগ্রামটির মোটামুটি ইতিবাচক প্রভাব।

Результаты

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

তথ্যও

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

ভিত্তিক সমাধান তুলনা rsync - কর্মক্ষমতা কয়েকগুণ খারাপ হতে পারে, যদিও এর বিশুদ্ধ আকারে tar rsync এর চেয়ে 20-30% দ্রুত কাজ করেছে।
সংগ্রহস্থলের আকারের উপর সঞ্চয় আছে, কিন্তু শুধুমাত্র সদৃশ সঙ্গে.

ঘোষণা

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

কারো দ্বারা কোন কিছু ডাকঘরে পাঠানো: পাভেল ডেমকোভিচ

উত্স: www.habr.com