লগ কোথা থেকে আসে? ভিম লগ ডাইভিং

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

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

তাই লগ

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

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

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

এই ধরনের API এর কিছু উদাহরণ

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

চলো আমরা শুরু করি অথবা VMware. 

তালিকায় সবার আগে থাকবেন vSphere API. প্রমাণীকরণ, শ্রেণিবিন্যাস পড়া, স্ন্যাপশট তৈরি এবং মুছে ফেলা, মেশিন সম্পর্কে তথ্যের অনুরোধ করা এবং আরও অনেক কিছু (খুব বেশি) জন্য ব্যবহৃত হয়। সমাধানটির কার্যকারিতা খুব বিস্তৃত, তাই আমি সংস্করণটির জন্য VMware vSphere API রেফারেন্স সুপারিশ করতে পারি 5.5 и 6.0. আরো বর্তমান সংস্করণের জন্য, সবকিছু শুধু গুগল করা হয়.

VIX API. হাইপারভাইজার কালো জাদু, যার জন্য একটি পৃথক আছে ত্রুটি তালিকা. নেটওয়ার্কে তাদের সাথে সংযোগ না করে হোস্টে ফাইলগুলির সাথে কাজ করার জন্য VMware API। একটি শেষ অবলম্বন বিকল্প যখন আপনাকে একটি মেশিনে একটি ফাইল রাখতে হবে যেখানে এর চেয়ে ভাল যোগাযোগের চ্যানেল নেই। ফাইলটি বড় হলে এবং হোস্ট লোড হলে এটি ব্যথা এবং যন্ত্রণাদায়ক। কিন্তু এখানে নিয়মটি কাজ করে যে এমনকি 56,6 Kb/s 0 Kb/s থেকেও ভালো। হাইপার-ভিতে, এই জিনিসটিকে পাওয়ারশেল ডাইরেক্ট বলা হয়। কিন্তু এটা শুধু আগে ছিল

vSpehere ওয়েব পরিষেবা API vSphere 6.0 থেকে শুরু করে (প্রায়, যেহেতু এই APIটি প্রথম সংস্করণ 5.5 এ চালু করা হয়েছিল) এটি গেস্ট মেশিনের সাথে কাজ করতে ব্যবহৃত হয় এবং প্রায় সর্বত্র VIX প্রতিস্থাপিত হয়েছে। আসলে, এটি vSphere পরিচালনার জন্য আরেকটি API। যারা আগ্রহী তাদের জন্য আমি অধ্যয়ন করার পরামর্শ দিই মহান ম্যানুয়াল 

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

VDDK error: 21036749815809.Unknown error

তারপর আমরা সাহসের সাথে এটিকে হেক্সে রূপান্তর করি এবং 132200000001 পাই। আমরা কেবল 132200-এর অজানা শুরুটি বাতিল করে দিই, এবং অবশিষ্টটি আমাদের ত্রুটি কোড (VDDK 1: অজানা ত্রুটি) হবে। সবচেয়ে ঘন ঘন ভিডিডিকে ত্রুটি সম্পর্কে, সম্প্রতি একটি পৃথক ছিল একটি নিবন্ধ.

এখন দেখা যাক উইন্ডোজ.

এখানে, আমাদের জন্য সবচেয়ে প্রয়োজনীয় এবং গুরুত্বপূর্ণ সবকিছু স্ট্যান্ডার্ডে পাওয়া যাবে পর্ব পরিদর্শক. তবে একটি ধরা আছে: একটি দীর্ঘ ঐতিহ্য অনুসারে, উইন্ডোজ ত্রুটির সম্পূর্ণ পাঠ্য লগ করে না, তবে শুধুমাত্র তার সংখ্যা। উদাহরণস্বরূপ, ত্রুটি 5 হল "অ্যাক্সেস অস্বীকার করা হয়েছে", এবং 1722 হল "আরপিসি সার্ভার অনুপলব্ধ", এবং 10060 হল "সংযোগের সময় শেষ"৷ অবশ্যই, আপনি যদি সবচেয়ে বিখ্যাতগুলি মনে রাখেন তবে এটি দুর্দান্ত, তবে এখন পর্যন্ত অদেখাগুলি সম্পর্কে কী? 

এবং যাতে জীবনকে মধুর মতো মনে হয় না, ত্রুটিগুলিও হেক্সাডেসিমেল আকারে 0x8007 উপসর্গ সহ সংরক্ষণ করা হয়। উদাহরণস্বরূপ, 0x8007000e আসলে 14, মেমরির বাইরে। কেন এবং কার জন্য এটি করা হয়েছিল তা একটি রহস্য অন্ধকারে আবৃত। যাইহোক, ত্রুটিগুলির একটি সম্পূর্ণ তালিকা বিনামূল্যে এবং এসএমএস ছাড়াই ডাউনলোড করা যেতে পারে devcenter.

যাইহোক, কখনও কখনও অন্যান্য উপসর্গ আছে, শুধুমাত্র 0x8007 নয়। এইরকম একটি দুঃখজনক পরিস্থিতিতে, HRESULT ("রেজাল্ট হ্যান্ডেল") বোঝার জন্য, আপনাকে আরও গভীরে যেতে হবে ডকুমেন্টেশন বিকাশকারীদের জন্য। সাধারণ জীবনে, আমি আপনাকে এটি করার পরামর্শ দিই না, তবে আপনি যদি হঠাৎ দেয়ালে চাপ দেন বা কেবল কৌতূহলী হন তবে এখন আপনি কী করবেন তা জানেন।

কিন্তু মাইক্রোসফটের কমরেডরা আমাদের প্রতি একটু করুণা করেছিল এবং বিশ্বকে একটি উপযোগিতা দেখিয়েছিল ছিল ERR. এটি কনসোল সুখের একটি ছোট অংশ যা Google ব্যবহার না করেই মানুষের মধ্যে ত্রুটি কোডগুলি অনুবাদ করতে পারে৷ এটা এই মত কাজ করে.

C:UsersrootDesktop>err.exe 0x54f
# for hex 0x54f / decimal 1359
  ERROR_INTERNAL_ERROR                                           winerror.h
# An internal error occurred.
# as an HRESULT: Severity: SUCCESS (0), FACILITY_NULL (0x0), Code 0x54f
# for hex 0x54f / decimal 1359
  ERROR_INTERNAL_ERROR                                           winerror.h
# An internal error occurred.
# 2 matches found for "0x54f"

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

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

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

আরপিসি (রিমোট প্রসিডিউর কল) আমার মনে হয় না এমন একজন ব্যক্তি আছেন যিনি উইন্ডোজের সাথে কাজ করেছেন যিনি আরপিসি-সম্পর্কিত ত্রুটি দেখেননি। জনপ্রিয় ভ্রান্ত ধারণা সত্ত্বেও, এটি একটি একক প্রোটোকল নয়, কিন্তু কোনো ক্লায়েন্ট-সার্ভার প্রোটোকল যা অনেকগুলি পরামিতি সন্তুষ্ট করে। যাইহোক, যদি আমাদের লগগুলিতে একটি RPC ত্রুটি থাকে, তবে 90% সময় এটি Microsoft RPC থেকে একটি ত্রুটি হবে, যা DCOM (ডিস্ট্রিবিউটেড কম্পোনেন্ট অবজেক্ট মডেল) এর অংশ। আপনি নেটে এই বিষয়ে প্রচুর পরিমাণে ডকুমেন্টেশন খুঁজে পেতে পারেন, তবে এর সিংহভাগটি বেশ পুরানো। তবে যদি বিষয়টি অধ্যয়নের তীব্র ইচ্ছা থাকে তবে আমি নিবন্ধগুলি সুপারিশ করতে পারি RPC কি?, কিভাবে আরপিসি কাজ করে এবং দীর্ঘ তালিকা RPC ত্রুটি.

আমাদের লগগুলিতে RPC ত্রুটির প্রধান কারণ হল VBR উপাদানগুলির মধ্যে যোগাযোগের ব্যর্থ প্রচেষ্টা (উদাহরণস্বরূপ সার্ভার > প্রক্সি) এবং প্রায়শই যোগাযোগের সমস্যার কারণে।

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

দ্বিতীয় সর্বাধিক জনপ্রিয় ত্রুটি: এন্ডপয়েন্ট ম্যাপার (1753) থেকে আর কোন এন্ডপয়েন্ট উপলব্ধ নেই। RPC ক্লায়েন্ট বা সার্ভার নিজেকে একটি পোর্ট বরাদ্দ করতে ব্যর্থ হয়েছে৷ সাধারণত ঘটে যখন সার্ভার (আমাদের ক্ষেত্রে, গেস্ট মেশিন) একটি সংকীর্ণ পরিসর থেকে গতিশীলভাবে পোর্ট বরাদ্দ করার জন্য কনফিগার করা হয়েছে যা শেষ হয়েছে৷ এবং যদি আপনি ক্লায়েন্টের দিক থেকে লগ ইন করেন (আমাদের ক্ষেত্রে, VBR সার্ভার), এর মানে হল আমাদের VeeamVssAgent হয় শুরু হয়নি বা RPC ইন্টারফেস হিসাবে নিবন্ধিত হয়নি। এই বিষয়ে এছাড়াও আছে পৃথক এইচএফ.

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

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

সাহায্যে SMB / CIFS অভ্যাসের বাইরে, সবাই সেগুলি পাশাপাশি লেখে, যদিও সবাই মনে রাখে না যে CIFS (সাধারণ ইন্টারনেট ফাইল সিস্টেম) SMB (সার্ভার মেসেজ ব্লক) এর একটি ব্যক্তিগত সংস্করণ মাত্র। সুতরাং এই ধারণাগুলিকে সাধারণীকরণে কোনও ভুল নেই। সাম্বা ইতিমধ্যেই একটি LinuxUnix বাস্তবায়ন, এবং এর নিজস্ব বিশেষত্ব রয়েছে, কিন্তু আমি বিচ্ছিন্ন হয়ে পড়ি। এখানে কী গুরুত্বপূর্ণ: যখন Veeam UNC পাথে (সার্ভার ডিরেক্টরি) কিছু লিখতে বলে, তখন সার্ভারটি ফাইল সিস্টেম ড্রাইভারের শ্রেণিবিন্যাস ব্যবহার করে, যার মধ্যে mup এবং mrxsmb, বল লেখার জন্য। তদনুসারে, এই ড্রাইভারগুলিও ত্রুটি তৈরি করবে।

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

উপরোল্লিখিত WMI (উইন্ডোজ ম্যানেজমেন্ট ইন্সট্রুমেন্টেশন) হল এক ধরনের সর্বশক্তিমান API যা উইন্ডোজ জগতের সবকিছু এবং প্রত্যেককে পরিচালনা করার জন্য। উদাহরণস্বরূপ, হাইপার-ভির সাথে কাজ করার সময়, হোস্টের কাছে প্রায় সমস্ত অনুরোধ এটির মধ্য দিয়ে যায়। এক কথায়, জিনিসটি একেবারে অপরিবর্তনীয় এবং এর ক্ষমতার দিক থেকে খুব শক্তিশালী। কোথায় এবং কি ভাঙা হয়েছে তা খুঁজে বের করার প্রয়াসে, অন্তর্নির্মিত WBEMtest.exe টুলটি অনেক সাহায্য করে।

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

এই, সম্ভবত, আমরা থামাতে পারেন. আমি সবচেয়ে মৌলিক বিষয়গুলি সম্পূর্ণ করা ব্যাখ্যা করার কাজটি বিবেচনা করি, তাই পরবর্তী অধ্যায়ে আমরা ইতিমধ্যে লগগুলি দেখব। কিন্তু যদি আপনার কোন প্রশ্ন থাকে, মন্তব্যে তাদের জিজ্ঞাসা করতে নির্দ্বিধায়.

উত্স: www.habr.com