ব্যাকআপ পার্ট 6: ব্যাকআপ টুলের তুলনা

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

তথ্য পুনরুদ্ধার

rsync এবং tar থেকে একটি রেফারেন্স পয়েন্ট হিসাবে ব্যবহার করা হবে তারা সাধারণত তাদের উপর ভিত্তি করে ব্যাকআপ কপি তৈরির জন্য সহজ স্ক্রিপ্ট।

rsync 4 মিনিট এবং 28 সেকেন্ডে সেট করা পরীক্ষার ডেটার সাথে মোকাবিলা করা, দেখানো হচ্ছে

যেমন একটি লোড

পুনরুদ্ধারের প্রক্রিয়াটি ব্যাকআপ স্টোরেজ সার্ভারের (sawtooth গ্রাফ) ডিস্ক সাবসিস্টেমের একটি সীমাবদ্ধতাকে আঘাত করে। আপনি কোনো সমস্যা ছাড়াই একটি কার্নেলের লোডিং পরিষ্কারভাবে দেখতে পারেন (নিম্ন iowait এবং softirq - যথাক্রমে ডিস্ক এবং নেটওয়ার্কে কোনো সমস্যা নেই)। যেহেতু অন্য দুটি প্রোগ্রাম, যথা rdiff-ব্যাকআপ এবং rsnapshot, rsync-এর উপর ভিত্তি করে এবং একটি পুনরুদ্ধার সরঞ্জাম হিসাবে নিয়মিত rsync অফার করে, তাদের প্রায় একই লোড প্রোফাইল এবং ব্যাকআপ পুনরুদ্ধারের সময় থাকবে।

আলকাতরা এটা একটু দ্রুত সম্পন্ন করা হয়েছে

2 মিনিট এবং 43 সেকেন্ড:

বর্ধিত সফ্টির্কের কারণে সিস্টেমের মোট লোড গড়ে 20% বেশি ছিল - নেটওয়ার্ক সাবসিস্টেম পরিচালনার সময় ওভারহেড খরচ বেড়েছে।

সংরক্ষণাগারটি আরও সংকুচিত হলে, পুনরুদ্ধারের সময় 3 মিনিট 19 সেকেন্ডে বৃদ্ধি পায়।
প্রধান সার্ভারে এই ধরনের লোড সহ (প্রধান সার্ভারের পাশে আনপ্যাক করা):

ডিকম্প্রেশন প্রক্রিয়া উভয় প্রসেসর কোর গ্রহণ করে কারণ দুটি প্রক্রিয়া চলছে। সাধারণভাবে, এটি প্রত্যাশিত ফলাফল। এছাড়াও, ব্যাকআপ সহ সার্ভারের পাশে gzip চালানোর সময় একটি তুলনামূলক ফলাফল (3 মিনিট এবং 20 সেকেন্ড) পাওয়া গিয়েছিল; প্রধান সার্ভারে লোড প্রোফাইলটি জিজিপ কম্প্রেসার ছাড়াই টার চালানোর মতো ছিল (আগের গ্রাফ দেখুন)।

В rdiff-ব্যাকআপ আপনি নিয়মিত rsync ব্যবহার করে আপনার করা শেষ ব্যাকআপটি সিঙ্ক্রোনাইজ করতে পারেন (ফলাফল একই রকম হবে), কিন্তু পুরানো ব্যাকআপগুলিকে এখনও rdiff-ব্যাকআপ প্রোগ্রাম ব্যবহার করে পুনরুদ্ধার করতে হবে, যা 17 মিনিট এবং 17 সেকেন্ডের মধ্যে পুনরুদ্ধার সম্পন্ন করেছে, দেখানো হচ্ছে

এই লোড:

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

Rsnapshot পুনরুদ্ধারের জন্য, এটি নিয়মিত rsync ব্যবহার করার পরামর্শ দেয়, তাই এর ফলাফল একই রকম হবে। সাধারণভাবে, এইভাবে এটি পরিণত হয়েছে।

বার্প আমি 7 মিনিট এবং 2 সেকেন্ডে একটি ব্যাকআপ পুনরুদ্ধারের কাজটি সম্পন্ন করেছি
এই লোড সহ:

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

প্রোগ্রামটি প্রায় একই গতি এবং লোড দেখিয়েছে ব্যাকআপপিসি rsync স্থানান্তর মোড সক্রিয় করার সময়, এর জন্য ব্যাকআপ স্থাপন করা

7 মিনিট এবং 42 সেকেন্ড:

কিন্তু ডেটা ট্রান্সফার মোডে, BackupPC আরও ধীরে ধীরে টার মোকাবেলা করেছে: 12 মিনিট এবং 15 সেকেন্ডে, প্রসেসরের লোড সাধারণত কম ছিল

দেড় বার:

ছলনা এনক্রিপশন ছাড়াই 10 মিনিট এবং 58 সেকেন্ডের মধ্যে একটি ব্যাকআপ পুনরুদ্ধার করে কিছুটা ভাল ফলাফল দেখায়। আপনি যদি gpg ব্যবহার করে এনক্রিপশন সক্রিয় করেন, পুনরুদ্ধারের সময় 15 মিনিট এবং 3 সেকেন্ডে বৃদ্ধি পায়। এছাড়াও, অনুলিপি সংরক্ষণের জন্য একটি সংগ্রহস্থল তৈরি করার সময়, আপনি ইনকামিং ডেটা স্ট্রীমকে বিভক্ত করার সময় যে সংরক্ষণাগারের আকার ব্যবহার করা হবে তা নির্দিষ্ট করতে পারেন। সাধারণভাবে, প্রচলিত হার্ড ড্রাইভে, একক-থ্রেডেড অপারেটিং মোডের কারণে, খুব বেশি পার্থক্য নেই। হাইব্রিড স্টোরেজ ব্যবহার করা হলে এটি বিভিন্ন ব্লক আকারে প্রদর্শিত হতে পারে। পুনরুদ্ধারের সময় প্রধান সার্ভারে লোড নিম্নরূপ ছিল:

কোনো এনক্রিপশন নেই

এনক্রিপশন সহ

নকল একটি তুলনামূলক পুনরুদ্ধারের হার দেখিয়েছে, এটি 13 মিনিট এবং 45 সেকেন্ডে সম্পূর্ণ করে। পুনরুদ্ধার করা ডেটার সঠিকতা পরীক্ষা করতে প্রায় 5 মিনিট সময় লেগেছে (মোট প্রায় 19 মিনিট)। ভার ছিল

বেশ উচ্চ:

যখন aes এনক্রিপশন অভ্যন্তরীণভাবে সক্রিয় করা হয়েছিল, তখন পুনরুদ্ধারের সময় ছিল 21 মিনিট 40 সেকেন্ড, পুনরুদ্ধারের সময় CPU ব্যবহার সর্বোচ্চ (উভয় কোর!) ছিল; ডেটা চেক করার সময়, শুধুমাত্র একটি থ্রেড সক্রিয় ছিল, একটি প্রসেসর কোর দখল করে। পুনরুদ্ধারের পরে ডেটা পরীক্ষা করতে একই 5 মিনিট সময় লেগেছিল (মোট প্রায় 27 মিনিট)।

ফল

এনক্রিপশনের জন্য বাহ্যিক gpg প্রোগ্রাম ব্যবহার করার সময় ডুপ্লিকাটি পুনরুদ্ধারের সাথে একটু দ্রুত ছিল, কিন্তু সাধারণভাবে পূর্ববর্তী মোড থেকে পার্থক্য ন্যূনতম। অপারেটিং সময় ছিল 16 মিনিট 30 সেকেন্ড, 6 মিনিটে ডেটা যাচাইকরণের সাথে। ভার ছিল

যেমন:

Amanda, টার ব্যবহার করে, এটি 2 মিনিট 49 সেকেন্ডে সম্পন্ন করেছে, যা নীতিগতভাবে, নিয়মিত টারের খুব কাছাকাছি। নীতিগতভাবে সিস্টেমে লোড করুন

একই:

ব্যবহার করে একটি ব্যাকআপ পুনরুদ্ধার করার সময় zbackup নিম্নলিখিত ফলাফল প্রাপ্ত হয়েছে:

এনক্রিপশন, lzma কম্প্রেশন

চলমান সময় 11 মিনিট 8 সেকেন্ড

AES এনক্রিপশন, lzma কম্প্রেশন

অপারেটিং সময় 14 মিনিট

AES এনক্রিপশন, lzo কম্প্রেশন

চলমান সময় 6 মিনিট, 19 সেকেন্ড

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

BorgBackup এনক্রিপ্টেড মোডে এটি টার থেকে একটু ধীর ছিল, 2 মিনিট 45 সেকেন্ডে, তবে, টার বিপরীতে, এটি সংগ্রহস্থলের অনুলিপি করা সম্ভব হয়েছিল। বোঝাই হয়ে গেল

পরবর্তী:

আপনি ব্লেক-ভিত্তিক এনক্রিপশন সক্ষম করলে, ব্যাকআপ পুনরুদ্ধারের গতি কিছুটা ধীর হয়। এই মোডে পুনরুদ্ধারের সময় 3 মিনিট 19 সেকেন্ড, এবং লোড চলে গেছে

এটার মত:

AES এনক্রিপশন কিছুটা ধীর, পুনরুদ্ধারের সময় 3 মিনিট 23 সেকেন্ড, লোড বিশেষত

পরিবর্তন হয়নি:

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

রেস্টিক পুনরুদ্ধারের সাথে কিছুটা ধীরে ধীরে মোকাবেলা করা হয়েছে, অপারেটিং সময় ছিল 4 মিনিট 28 সেকেন্ড। লোড দেখে মনে হচ্ছিল

নিম্নরূপ:

দৃশ্যত পুনরুদ্ধার প্রক্রিয়াটি বেশ কয়েকটি থ্রেডে কাজ করে, কিন্তু কার্যকারিতা BorgBackup-এর মতো বেশি নয়, তবে নিয়মিত rsync-এর সাথে তুলনা করা যায়।

এর সাহায্যে Bব্যাকআপ 8 মিনিট এবং 19 সেকেন্ডে ডেটা পুনরুদ্ধার করা সম্ভব ছিল, লোড ছিল

যেমন:

লোড এখনও খুব বেশি নয়, এমনকি আলকাতের চেয়ে কম। কিছু জায়গায় বিস্ফোরণ আছে, তবে একটি কোরের লোডের বেশি নয়।

তুলনা করার জন্য মানদণ্ড নির্বাচন এবং ন্যায্যতা

আগের নিবন্ধগুলির একটিতে যেমন বলা হয়েছে, ব্যাকআপ সিস্টেমকে অবশ্যই নিম্নলিখিত মানদণ্ড পূরণ করতে হবে:

• ব্যবহারে সহজ
• বহুমুখতা
• স্থায়িত্ব
• ক্ষিপ্রতা

আরও বিশদে প্রতিটি পয়েন্ট আলাদাভাবে বিবেচনা করা মূল্যবান।

অপারেশন সহজ

একটি বোতাম থাকলে এটি সবচেয়ে ভাল হয় "সবকিছু ভালভাবে করুন" তবে আপনি যদি বাস্তব প্রোগ্রামগুলিতে ফিরে যান, তবে সবচেয়ে সুবিধাজনক জিনিসটি হবে কিছু পরিচিত এবং স্ট্যান্ডার্ড অপারেটিং নীতি।
বেশিরভাগ ব্যবহারকারীরা সম্ভবত ভাল থাকবেন যদি তাদের cli-এর জন্য একগুচ্ছ কী মনে রাখতে না হয়, ওয়েব বা tui-এর মাধ্যমে একগুচ্ছ বিভিন্ন, প্রায়ই অস্পষ্ট বিকল্প কনফিগার করতে হয়, অথবা অসফল অপারেশন সম্পর্কে বিজ্ঞপ্তি সেট আপ করতে না হয়। এর মধ্যে বিদ্যমান পরিকাঠামোতে একটি ব্যাকআপ সলিউশন সহজে "ফিট" করার ক্ষমতা, সেইসাথে ব্যাকআপ প্রক্রিয়ার স্বয়ংক্রিয়তাও অন্তর্ভুক্ত রয়েছে। প্যাকেজ ম্যানেজার ব্যবহার করে বা "ডাউনলোড এবং আনপ্যাক" এর মতো এক বা দুটি কমান্ডে ইনস্টলেশনের সম্ভাবনাও রয়েছে। curl ссылка | sudo bash - একটি জটিল পদ্ধতি, যেহেতু আপনাকে লিঙ্কের মাধ্যমে কী আসে তা পরীক্ষা করতে হবে।

উদাহরণস্বরূপ, বিবেচিত প্রার্থীদের মধ্যে, একটি সহজ সমাধান হল burp, rdiff-ব্যাকআপ এবং রেস্টিক, যার বিভিন্ন অপারেটিং মোডের জন্য স্মৃতি সংক্রান্ত কী রয়েছে। একটু বেশি জটিল হল বোর্গ এবং ডুপ্লিসিটি। সবচেয়ে কঠিন ছিল আমান্ডা। বাকীগুলি ব্যবহারের সহজতার দিক থেকে মাঝখানে কোথাও রয়েছে। যে কোনও ক্ষেত্রে, ব্যবহারকারীর ম্যানুয়ালটি পড়তে আপনার যদি 30 সেকেন্ডের বেশি সময় লাগে, বা আপনাকে Google বা অন্য কোনও সার্চ ইঞ্জিনে যেতে হবে এবং সাহায্যের একটি দীর্ঘ শীট দিয়ে স্ক্রোল করতে হবে, তবে সিদ্ধান্ত নেওয়া কঠিন, এক উপায় বা অন্য।

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

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

বহুমুখতা

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

একটি চিহ্ন হিসাবে - নিয়মিত ssh ব্যবহার করে কাজ করার ক্ষমতা।

কাজের গতি

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

স্থায়িত্ব

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

ব্যাকআপ টুলের তুলনা

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

rsync
4 মি 15 এস
4 মি 28 এস
হাঁ
না
না
না
হাঁ
না
না
হাঁ
না
হাঁ
হাঁ
না
না
না
না
না
হাঁ
6

আলকাতরা
বিশুদ্ধ
3 মি 12 এস
2 মি 43 এস
হাঁ
না
না
না
না
না
হাঁ
হাঁ
না
হাঁ
না
না
না
না
না
না
হাঁ
8,5

gzip,
9 মি 37 এস
3 মি 19 এস
হাঁ

Rdiff-ব্যাকআপ
16 মি 26 এস
17 মি 17 এস
হাঁ
হাঁ
হাঁ
হাঁ
হাঁ
না
হাঁ
না
হাঁ
না
হাঁ
না
হাঁ
হাঁ
হাঁ
না
হাঁ
11

Rsnapshot
4 মি 19 এস
4 মি 28 এস
হাঁ
হাঁ
হাঁ
হাঁ
না
না
হাঁ
না
হাঁ
না
হাঁ
না
না
হাঁ
হাঁ
না
হাঁ
12,5

বার্প
11 মি 9 এস
7 মি 2 এস
হাঁ
না
হাঁ
হাঁ
হাঁ
হাঁ
হাঁ
না
হাঁ
হাঁ
না
না
হাঁ
না
হাঁ
না
হাঁ
10,5

ছলনা
কোন এনক্রিপশন নেই
16 মি 48 এস
10 মি 58 এস
হাঁ
হাঁ
না
হাঁ
না
হাঁ
হাঁ
না
না
হাঁ
না
হাঁ
হাঁ
না
হাঁ
না
হাঁ
11

প্রারম্ভিক স্থান
17 মি 27 এস
15 মি 3 এস

নকল
কোন এনক্রিপশন নেই
20 মি 28 এস
13 মি 45 এস
না
হাঁ
না
না
না
হাঁ
হাঁ
না
না
হাঁ
না
হাঁ
হাঁ
হাঁ
হাঁ
হাঁ
হাঁ
11

AES
29 মি 41 এস
21 মি 40 এস

প্রারম্ভিক স্থান
26 মি 19 এস
16 মি 30 এস

জ্যাকব্যাকআপ
কোন এনক্রিপশন নেই
40 মি 3 এস
11 মি 8 এস
হাঁ
হাঁ
না
না
না
হাঁ
হাঁ
হাঁ
না
হাঁ
না
হাঁ
হাঁ
হাঁ
না
না
না
10

AES
42 মি 0 এস
14 মি 1 এস

aes+lzo
18 মি 9 এস
6 মি 19 এস

BorgBackup
কোন এনক্রিপশন নেই
4 মি 7 এস
2 মি 45 এস
হাঁ
হাঁ
হাঁ
হাঁ
হাঁ
হাঁ
হাঁ
হাঁ
হাঁ
হাঁ
না
হাঁ
হাঁ
হাঁ
হাঁ
না
হাঁ
16

AES
4 মি 58 এস
3 মি 23 এস

ব্লেক ৮৮
4 মি 39 এস
3 মি 19 এস

রেস্টিক
5 মি 38 এস
4 মি 28 এস
হাঁ
হাঁ
হাঁ
হাঁ
না
হাঁ
হাঁ
হাঁ
হাঁ
হাঁ
না
হাঁ
না
হাঁ
না
হাঁ
হাঁ
15,5

Bব্যাকআপ
8 মি 21 এস
8 মি 19 এস
হাঁ
হাঁ
হাঁ
না
হাঁ
না
হাঁ
না
হাঁ
হাঁ
না
হাঁ
হাঁ
হাঁ
হাঁ
না
হাঁ
12

আমান্ডা
9 মি 3 এস
2 মি 49 এস
হাঁ
না
না
হাঁ
হাঁ
হাঁ
হাঁ
না
হাঁ
হাঁ
হাঁ
হাঁ
হাঁ
না
হাঁ
হাঁ
হাঁ
13

ব্যাকআপপিসি
rsync
12 মি 22 এস
7 মি 42 এস
হাঁ
না
হাঁ
হাঁ
হাঁ
হাঁ
হাঁ
না
হাঁ
না
না
হাঁ
হাঁ
না
হাঁ
না
হাঁ
10,5

আলকাতরা
12 মি 34 এস
12 মি 15 এস

টেবিল কিংবদন্তি:

• সবুজ, অপারেটিং সময় পাঁচ মিনিটের কম, অথবা উত্তর দিন "হ্যাঁ" ("একটি ক্লায়েন্ট সার্ভার প্রয়োজন?" কলাম ব্যতীত), 1 পয়েন্ট
• হলুদ, অপারেটিং সময় পাঁচ থেকে দশ মিনিট, 0.5 পয়েন্ট
• লাল, কাজের সময় দশ মিনিটের বেশি, অথবা উত্তর হল "না" (কলাম "আপনার কি একটি ক্লায়েন্ট সার্ভার প্রয়োজন?" ছাড়া), 0 পয়েন্ট

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

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

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

ঘোষণা

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

উত্স: www.habr.com