লিনাক্সে 10 মিলিয়ন ফাইল সংরক্ষণ এবং ব্যাক আপ করে


25

আমি একটি ওয়েবসাইট পরিচালনা করি যেখানে প্রায় ১০ মিলিয়ন ফাইল (বইয়ের কভার) 3 স্তরের সাব-ডিরেক্টরিতে সংরক্ষণ করা হয়, [0-f] সহ:

0/0/0/
0/0/1/
...
f/f/f/

এটি প্রতি ডিরেক্টরি প্রায় 2400 ফাইলের দিকে নিয়ে যায় যা আমাদের যখন একটি ফাইল পুনরুদ্ধার করতে হয় তখন খুব দ্রুত হয়। এটি আরও অনেক প্রশ্ন দ্বারা প্রস্তাবিত একটি অনুশীলন ।

যাইহোক, যখন আমার এই ফাইলগুলি ব্যাকআপ করা দরকার তখন 10 এম ফাইলযুক্ত 4k ডিরেক্টরিগুলি ব্রাউজ করতে কেবল অনেক দিন সময় লাগে।

সুতরাং আমি ভাবছি যে আমি এই ফাইলগুলি একটি ধারক (বা 4 কে পাত্রে) সংরক্ষণ করতে পারতাম, যা প্রত্যেকে একটি ফাইল সিস্টেমের মতো কাজ করবে (কিছু প্রকারের মাউন্ট এক্সট 3/4 ধারক?) আমি অনুমান করি যে এটি ফাইল সিস্টেমের সরাসরি কোনও ফাইল অ্যাক্সেস করার মতো প্রায় দক্ষ হবে এবং এটি খুব দক্ষতার সাথে অন্য সার্ভারে অনুলিপি করার দুর্দান্ত সুবিধা হবে।

এটি কীভাবে সেরা করবেন তার কোনও পরামর্শ? বা কোনও কার্যকর বিকল্প (নোএসকিউএল, ...)?


আপনি এখন কোন ফাইল সিস্টেম ব্যবহার করছেন?
সেমিগ্রিন্টি

নেট অ্যাপ্লিকেশন একটি বিকল্প হতে পারে যদি আপনি দামগুলি বঞ্চিত করতে পারেন
আয়ান

আমি CentOS 5.6 এর অধীনে ext4 ব্যবহার করছি
বেনজামিন

1
উত্সাহিত কেন এটি "10m ফাইল ধারণকারী 4k ডিরেক্টরিগুলি ব্রাউজ করতে কেবল অনেক দিন" লাগবে, এটি বেশ ধীর বলে মনে হচ্ছে। পথের প্রতি 150 বাইট অনুমান করে, 10 মি ফাইলের নামগুলি 1.5 গিগাবাইট ডেটা তৈরি করে, তাই এটি উপলব্ধ মেমরি / সিপিইউ (ফলাফল বাছাই সহ) হতে পারে। এছাড়াও, যদি সক্রিয় পরীক্ষা / dir_index নিষ্ক্রিয় সাহায্য করে: lonesysadmin.net/2007/08/17/... প্লাস এ বিভিন্ন টিপস serverfault.com/questions/183821/...
RichVel

নোট 5 বছর পরে: আমি অ্যামাজন এস 3 তে সমস্ত স্থানান্তরিত করেছি, যা এত বড় পরিমাণে ফাইল সঞ্চয় করার জন্য উপযুক্ত। এছাড়াও আমাকে ফাইলগুলিকে আর 3 টি সাব-ডিরেক্টরিগুলির স্তরে বিভক্ত করতে হবে না, এস 3 হিসাবে এটি কোনও তফাত্ করে না (একটি পাথ একটি পাথ, এতে স্ল্যাশ রয়েছে বা না কোনও পার্থক্য নেই)। আমার ডেটা নিরাপদে বেশ কয়েকটি স্থানে প্রতিলিপি করা হয়েছে তা জেনে আমি আরও ভাল ঘুমাতে পারি।
বেনিয়ামিন

উত্তর:


11

লক্ষ লক্ষ ফাইলগুলিতে দ্রুত অ্যাক্সেস এবং ব্যাক আপ করার জন্য বিকল্পসমূহ

একই সমস্যাযুক্ত লোকদের কাছ থেকে ধার করুন

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

http://devel.squid-cache.org/coss/coss-notes.txt

http://citeseer.ist.psu.edu/viewdoc/download;jsessionid=4074B50D266E72C69D6D35FEDCBBA83D?doi=10.1.1.31.4000&rep=rep1&type=pdf

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

উত্সর্গীকৃত ফাইল সিস্টেমগুলি

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

LVM- র

পার্টিশনের গতিশীল আকারের অনুমতি দেওয়ার জন্য আমি উপরে LVM কে দরকারী হিসাবে উল্লেখ করেছি যাতে আপনাকে প্রচুর খালি জায়গার ব্যাকআপ নিতে হবে না। তবে অবশ্যই, এলভিএমের অন্যান্য বৈশিষ্ট্য রয়েছে যা সম্ভবত খুব বেশি প্রযোজ্য। বিশেষত "স্ন্যাপশট" কার্যকারিতা যা আপনাকে একটি মুহুর্তে একটি ফাইল সিস্টেম হিম করতে দেয়। যে কোনও দুর্ঘটনাযুক্ত rm -rfবা যাই হোক না কেন স্ন্যাপশটকে বিরক্ত করবে। আপনি যা করতে চেষ্টা করছেন ঠিক তার উপর নির্ভরশীল, এটি আপনার ব্যাকআপগুলির প্রয়োজনের জন্য যথেষ্ট।

RAID- র -1

আমি নিশ্চিত যে আপনি ইতিমধ্যে র‌্যাডের সাথে পরিচিত এবং সম্ভবত এটি ইতিমধ্যে নির্ভরযোগ্যতার জন্য ব্যবহার করেছেন, তবে কমপক্ষে আপনি যদি সফ্টওয়্যার র‌্যাড ব্যবহার করছেন তবে কমপক্ষে র‌্যাড -১ ব্যবহার করা যেতে পারে (আপনি এটি হার্ডওয়ার রেডের সাথে ব্যবহার করতে পারেন, তবে এটি আসলে আপনাকে নিম্ন নির্ভরযোগ্যতা দেয় কারণ এটি পড়তে একই মডেল / রিভিশন নিয়ামক প্রয়োজন হতে পারে)। ধারণাটি হ'ল আপনি নিজের স্বাভাবিক নির্ভরযোগ্যতার প্রয়োজনের জন্য আপনার প্রয়োজনের তুলনায় আরও একটি ডিস্কের সাথে একটি RAID-1 গ্রুপ তৈরি করেন (উদাহরণস্বরূপ আপনি যদি দুটি ডিস্কের সাথে সফ্টওয়্যার RAID-1 ব্যবহার করেন তবে সম্ভবত একটি বৃহত ডিস্ক এবং একটি হার্ডওয়্যার- হার্ডওয়্যার RAID-5 এর উপরে একটি সফ্টওয়্যার RAID-1 সহ ছোট ডিস্ক সহ RAID5 যখন ব্যাকআপ নেওয়ার সময় আসে, একটি ডিস্ক ইনস্টল করুন, mddm কে সেই ডিস্কটিকে রেড গ্রুপে যুক্ত করতে বলুন, এটি সম্পূর্ণতা নির্দেশ না হওয়া পর্যন্ত অপেক্ষা করুন, allyচ্ছিকভাবে একটি যাচাইয়ের স্ক্রাবের জন্য জিজ্ঞাসা করুন এবং তারপরে ডিস্কটি সরিয়ে ফেলুন। অবশ্যই,


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

9

আপনি লুপব্যাক ম্যানেজার ব্যবহার করে ভার্চুয়াল ফাইল সিস্টেমটি মাউন্ট করতে পারেন তবে এটি আপনার ব্যাকআপ প্রক্রিয়াটিকে ত্বরান্বিত করতে পারে, এটি সাধারণ ক্রিয়াকলাপগুলিকে প্রভাবিত করতে পারে।

আর একটি বিকল্প হ'ল ডিডি ব্যবহার করে পুরো ডিভাইসটি ব্যাকআপ করা। উদাহরণস্বরূপ dd if=/dev/my_device of=/path/to/backup.dd,।


+1 ডিভাইসটি নিজেই ব্যাক আপ করা ভাল ধারণা।
asm

3
আপনার যদি এই পদ্ধতিটি ব্যবহার করা হয় তবে পুনরুদ্ধারটি পরীক্ষা করুন (ভাল, আপনার সর্বদা এটি করা উচিত) কারণ আপনার ইনপুটটি যদি / dev / sdd এর মতো ডিস্ক হয় তবে ডিডি পার্টিশন শেম এবং মাপগুলি সংরক্ষণ করবে store আপনি যদি এটি একটি ছোট ডিস্কে পুনরুদ্ধার করেন তবে আপনি ত্রুটিগুলি পেয়ে যাবেন এবং আপনি যদি এটি কোনও বড় ডিস্কে পুনরুদ্ধার করেন তবে এটি কেটে ফেলা হবে। আপনি যদি একই ডিস্ক প্রকারের অন্য এক উদাহরণে ডেটা পুনরুদ্ধার করেন তবে এটি সবচেয়ে ভাল কাজ করবে। কেবলমাত্র পার্টিশন পুনরুদ্ধার (/ dev / sdd1) কম ঝামেলা পাবে।
ব্যবহারকারী অজানা

1
মনে রাখবেন যে ডিভাইসটি যদি LVM তে থাকে তবে LVM স্ন্যাপশট ব্যবহার করে ডিস্কটিকে আনমাউন্ট না করে একটি ব্যাকআপও করা যায়।
বিডনলান

আমি LVM স্ন্যাপশট ব্যাকআপ পদ্ধতির দ্বিতীয় লাইভ ডিআর প্রতিরূপের জন্য আমি অতীতে lvm ব্যবহার করেছি। স্ন্যাপশটের সাথে ডিডি ব্যবহার করে দ্রুত ব্লক-স্তরের ব্যাকআপ করা সহজ করে তোলে makes
স্ল্যাশডট

আমি চেষ্টা ddউপর ncএবং এই একটি ভাল কাজ আছে! তবে লাইভ পার্টিশনের পরিবর্তে LVM স্ন্যাপশট ব্যবহারের বিপরীতে আমার কাছে অসঙ্গতিপূর্ণ / দূষিত ডেটা থাকতে পারে।
বেনিয়ামিন

8

আপনি সম্ভবত জানেন, আপনার সমস্যা লোকালয়। একটি সাধারণ ডিস্কের সন্ধান 10 মিনিট বা তার বেশি সময় নেয়। সুতরাং এলোমেলোভাবে স্থাপন করা ফাইলগুলিতে কেবল "স্ট্যাট" (বা ওপেন ()) কল করতে 10 মিলিয়ন সিক, বা প্রায় 100000 সেকেন্ড, বা 30 ঘন্টা প্রয়োজন হয় requires

সুতরাং আপনাকে অবশ্যই আপনার ফাইলগুলি বৃহত্তর পাত্রে রাখতে হবে যেমন প্রাসঙ্গিক নম্বরটি আপনার ড্রাইভ ব্যান্ডউইদথ (একক ডিস্কের জন্য সাধারণত 50-100 মেগাবাইট / সেকেন্ড) সাধারণত আপনার সময় চাওয়ার চেয়ে। এছাড়াও আপনি এটিতে একটি RAID নিক্ষেপ করতে পারেন, যা আপনাকে ব্যান্ডউইথকে ক্র্যাঙ্ক করতে দেয় (তবে সময় সন্ধানকে হ্রাস করে না)।

আমি সম্ভবত আপনাকে এমন কিছু বলছি না যা আপনি ইতিমধ্যে জানেন না, তবে আমার বক্তব্যটি হ'ল আপনার "ধারক" ধারণাটি অবশ্যই সমস্যাটি সমাধান করবে, এবং কেবল কোনও ধারকই এটি করবে। লুপব্যাক মাউন্টগুলি সম্ভবত কিছু হিসাবে কাজ করবে।


হ্যাঁ, লোকেশন অত্যন্ত গুরুত্বপূর্ণ। আপনার ব্যবহারের ধরণগুলি দেখুন। বেশিরভাগ সমস্যাগুলি পেরেটো নীতি অনুসরণ করে (20% ডেটা হিট করার প্রক্রিয়াগুলির 80%), তাই যদি আপনি বুঝতে পারেন যে কোন ফাইলগুলিকে র‌্যামে ক্যাশে করা দরকার, বা ডিরেক্টরিগুলির একটি পৃথক বিন্যাস সহ কেবল একটি পৃথক পার্টিশন রেখে দেওয়া যায়, তাই এটি ডিরেক্টরি ডিরেক্টরি অনুসন্ধান বা সন্ধান কম লাগে, এটি সম্ভবত অনেক সাহায্য করবে। ডিস্কের বিভিন্ন স্পিন্ডলে ঘন ঘন অ্যাক্সেস করা ফাইলগুলি ছড়িয়ে দেওয়া যাতে চেষ্টাগুলি সমান্তরালভাবে করা যায় তবে সহায়তা করতে পারে। রেফারেন্সের লোকালটি আনার জন্য @ নেমোর জন্য +1।
মার্সিন

5

বিকল্প দুটি আছে। সবচেয়ে সহজ এবং সমস্ত লিনাক্স ফাইল সিস্টেমের সাথে কাজ করা হ'ল ddসম্পূর্ণ পার্টিশনটি ( /dev/sdb3বা /dev/mapper/Data-ImageVol) একটি একক ছবিতে অনুলিপি করা এবং সেই চিত্রটি সংরক্ষণাগারভুক্ত করা। একক ফাইল পুনরুদ্ধারের ক্ষেত্রে, লুপব্যাকটি মাউন্ট করুন ( mount -o loop /usr/path/to/file /mountpoint) এবং আপনার প্রয়োজনীয় ফাইলগুলি অনুলিপি করুন। সম্পূর্ণ পার্টিশন পুনরুদ্ধারের জন্য, আপনি প্রাথমিক ddকমান্ডের দিকটি বিপরীত করতে পারেন , তবে আপনার সত্যিকারের অভিন্ন আকারের একটি পার্টিশন প্রয়োজন।

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

পর্যায়ক্রমে, গুগল ভিডিও @ কেসি প্রায় অর্ধেক পথের উল্লেখ করে বলেছে, এক্সএফএস একটি দুর্দান্ত ফাইল সিস্টেম (জটিল হলে)। এক্সএফএসের সাথে একটি দুর্দান্ত xfsdumpইউটিলিটি হ'ল ইউটিলিটি, যা একটি সম্পূর্ণ ফাইল সিস্টেমকে একটি ফাইলে ডাম্প করে দেবে এবং সাধারণত এটির চেয়ে দ্রুত কাজ করে tar। এটি একটি ফাইল-সিস্টেম-নির্দিষ্ট ইউটিলিটি, সুতরাং যেভাবে টার পারে না সেভাবে Fs ইন্টার্নালগুলির সুবিধা নিতে পারে।


সেখানে প্রচুর ভাল উত্তর! এক্সএফএস আকর্ষণীয় বলে মনে হচ্ছে তবে আমি ভয় করি যে এটি আমার নাগালের থেকে কিছুটা দূরে।
বেনিয়ামিন

3

আমি আপনাকে পরামর্শ দিচ্ছি আপনি প্রথমে এটি এক্সটি 4 এ আপগ্রেড করার চেষ্টা করুন, যদি আপনি এটি ইতিমধ্যে চালাচ্ছেন না।

গুগল কেন এক্সটি 4 ভাল ধারণা তা নিয়ে অনেক গবেষণা করেছে ।

এর পরে আপনার বিতরণ করা ফাইল সিস্টেম আর্কিটেকচার স্থাপনের বিষয়টি দেখতে হবে। উদাহরণ স্বরূপ:


আমি ইতিমধ্যে EXT4 চালাচ্ছি, যা দুর্দান্ত দেখাচ্ছে!
বেনিয়ামিন

2

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

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

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


গ্রিডএফএস-এ অবশ্যই একটি নজর থাকবে যা আমি জানতাম না, তবে আমি মনে করি যে সমস্ত কিছু ইতিমধ্যে কাজ করে যাচ্ছি তাই কাজের পরিমাণ হ্রাস করার জন্য ফাইল সিস্টেম-ভিত্তিক সবকিছুই রেখে দেব!
বেঞ্জামিন

1

আপনি যদি আপনার ডেটা সঞ্চয় করার জন্য কোনও অ্যাপ্লায়েন্স মডেল নিয়ে খুশি হন তবে আপনি NexentaStor বিবেচনা করতে পারেন । এটি ওপেন সোলারিসে হুডের অধীনে জেডএফএস চালায় তবে সমস্ত প্রশাসন একটি ওয়েব জিইউআইয়ের মাধ্যমে।

এমন কয়েকটি বৈশিষ্ট্য রয়েছে যা আপনার সমস্যাটিতে সহায়তা করবে।

  • এন্টারপ্রাইজ সংস্করণ স্ন্যাপশটের ভিত্তিতে দূরবর্তী প্রতিরূপের একটি ফর্ম সমর্থন করে যা পুরো ফাইল সিস্টেমের মাধ্যমে স্ক্যানের প্রয়োজন হয় না।

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


ধন্যবাদ, এটি একবার দেখুন। তবে এটি আমার প্রকল্পে কিছুটা জটিলতা যোগ করবে!
বেনিয়ামিন

1

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

এর restoreদ্বারা তৈরি ব্যাকআপগুলি পুনরুদ্ধার করার জন্য একটি উপযুক্ত ইউটিলিটি রয়েছে dump

এটি স্তরগুলি ব্যবহার করে ইনক্রিমেন্টাল ব্যাকআপগুলি সমর্থন করে - শেষ স্তর 0 (পূর্ণ) ব্যাকআপ থেকে স্তর 1 স্তরের ব্যাকআপ ফাইলগুলি, স্তর 2 - স্তর 1 ব্যাকআপ থেকে সংশোধিত ইত্যাদি on


0

ইনক্রিমেন্টাল ব্যাকআপগুলির জন্য, একটি বিকল্পে নতুন কভারগুলির জন্য একটি দ্বিতীয়, ছায়া গাছ থাকা উচিত। এটি হ'ল আপনার প্রধান গাছটি যা সমস্ত পঠিত ক্রিয়াকলাপের জন্য ব্যবহৃত হয়। আপনার একটি newfiles/012345.....jpgডিরেক্টরিও রয়েছে; নতুন যুক্ত হওয়া কভারগুলি এখানে মূল গাছের পাশাপাশি একটি হার্ডলিঙ্ক তৈরি করে। ব্যাকআপগুলি সম্পাদন করার সময় আপনি মাঝেমধ্যে মূল গাছটিকে ব্যাকআপ করতে পারেন তবে newfilesনিয়মিতভাবে (অনেক ছোট) গাছটিকে ব্যাকআপ করুন ।

নোট করুন যে newfilesগাছটি ছোট রাখার জন্য, প্রধান গাছের নতুন ব্যাকআপ সম্পাদনের আগে, আপনি নতুন ফাইলগুলি ট্রি খালি করতে পারেন:

mv newfiles newfiles_
mkdir newfiles
rm -rf newfiles_

একবার আপনি এটি করেন, অবশ্যই, আপনি মূল গাছ একটি নতুন ব্যাকআপ উত্পাদন প্রতিশ্রুতিবদ্ধ।


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

0

সামান্য সামঞ্জস্য যোগ করা সাধারণত সহায়তা করে।

তোমার চেয়ে আমারও একই সমস্যা; আমার ক্ষেত্রে আমার প্রায় 30 মিলিয়ন ফাইলের ব্যাকআপ নিতে হবে, তাদের বেশিরভাগ এইচটিএমএল, পিএইচপি বা জেপিইজি ফাইল। আমার জন্য ব্যাকআপপিসি + আরএসসিএন ওভার এসএসএস কাজের ধরণের ওকে; পুরো ব্যাকআপটি প্রায় এক দিন সময় নেয়, তবে ইনক্রিমেন্টগুলি সাধারণত কয়েক ঘন্টার মধ্যে শেষ হবে।

কৌশলটি হ'ল ব্যাকআপপিসিতে অনুলিপি করার জন্য প্রতিটি প্রধান স্তরের ডিরেক্টরি (0, 1, 2 ... ক, খ, সি ...) যুক্ত করা এবং এটি সমান্তরালভাবে ব্যাকআপটি সম্পাদন করতে দেওয়া, সুতরাং এটি একই সাথে ডিরেক্টরিগুলি ব্যাক আপ করে এ / , বি / , সি / * এবং আরও অনেক কিছু। আপনার ডিস্কের সাবসিস্টেমের উপর নির্ভর করে কয়েকটি প্রক্রিয়া প্রায় 10 টি প্রসেসের মধ্যে থাকা ব্যাক আপ করার সম্ভবত দ্রুততম উপায়।

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


আমি অবাক হই যে রুট ডিরেক্টরিগুলি ব্যাক আপ একই সাথে আপনার জন্য সমস্যার সমাধান করে, আমি আশা করি এটি আসলে ধীর হবে। সমস্ত ডিরেক্টরি একই ডিস্কে আছে? আপনি কি এসএসডি ব্যবহার করছেন?
বেনিয়ামিন

ডেটা ফাইলগুলি সান এ সংরক্ষণ করা হয়।
জান্নে পিক্কারাইনেন

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

0

বেঞ্জামিন,

আমি মনে করি আপনার ডিরেক্টরিটি প্রতিটি ডিরেক্টরি স্তরের ফাইলের সংখ্যায় সমাধান করা যেতে পারে!

আপনি যদি কোনও ডিরেক্টরিতে 20 000 ফাইল সঞ্চয় করেন তবে অ্যাক্সেসের সময়টি কি কোনও গুরুত্বপূর্ণ ফ্যাক্টর দ্বারা পরিবর্তিত হয়?

এছাড়াও আপনি কি পৃথক দ্রুত অ্যাক্সেস ড্রাইভে ফাইল সিস্টেমের মেটাটাটা সংরক্ষণ করার জন্য? (এসএসডি এর মতো)?


0

পরিবর্তে আমি একটি ভাল পুরানো রিলেশনাল ডাটাবেস সুপারিশ করব।

আমি বলি যে, 256 পার্টিশনযুক্ত টেবিল (কভার_00, কভার 001, ..., কভার_এফ) সহ প্রাথমিক তথ্য হিসাবে byteaফাইল সনাক্তকারী সহ বাহ্যিক স্টোরেজ সহ (বাইনারি) কলাম হিসাবে চিত্র ডেটা রয়েছে । কোনও চিত্র পুনরুদ্ধার দ্রুত হবে (প্রাথমিক কীতে কোনও সূচককে ধন্যবাদ), ডেটা অখণ্ডতার গ্যারান্টি দেওয়া হবে (এসিআইডি কমপ্লায়েন্ট ডাটাবেস), ব্যাকআপ ডিস্ক ক্রমে থাকবে, তাই খুব বেশি সন্ধান করা নয়।

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.