ტევადობის დონე (ან როგორც ჩვენ მას ვუწოდებთ Vim - captir) ჯერ კიდევ გამოჩნდა Veeam სარეზერვო და რეპლიკაციის 9.5 განახლების 4-ის დღეებში, სახელწოდებით Archive Tier. ამის მიღმა იდეა მდგომარეობს იმაში, რომ შესაძლებელი გახდეს ეგრეთ წოდებული ოპერატიული აღდგენის ფანჯრიდან ამოვარდნილი სარეზერვო ასლების გადატანა ობიექტების შესანახად. ეს დაეხმარა დისკზე სივრცის გასუფთავებას იმ მომხმარებლებისთვის, რომლებსაც ეს ცოტა ჰქონდათ. და ამ ვარიანტს ერქვა Move Mode.

ამ მარტივი (როგორც ჩანს) მოქმედების შესასრულებლად საკმარისი იყო ორი პირობის დაკმაყოფილება: გადატანილი სარეზერვო ასლიდან ყველა წერტილი უნდა იყოს ზემოაღნიშნული ოპერაციული აღდგენის ფანჯრის საზღვრებს გარეთ, რომელიც პირდაპირ არის დაყენებული UI-ში. და მეორე: ჯაჭვი უნდა იყოს ეგრეთ წოდებული „დალუქული ფორმით“ (დალუქული სარეზერვო ჯაჭვი ან არააქტიური სარეზერვო ჯაჭვი). ანუ ამ ჯაჭვში დროთა განმავლობაში ცვლილებები არ ხდება.

მაგრამ VBR v10-ში კონცეფციას დაემატა ახალი ფუნქციები - Copy Mode, Sealed Mode და გამოჩნდა ნივთი რთულად გამოთქმადი სახელით Immutability.

ეს არის მომხიბლავი რამ, რაზეც დღეს ვისაუბრებთ. ჯერ იმაზე, თუ როგორ მუშაობდა VBR9.5u4-ში, შემდეგ კი მეათე ვერსიაში ცვლილებების შესახებ.

და შეიძლება მაპატიონ წმინდა ენის დამცველებმა, მაგრამ ძალიან ბევრი ტერმინია, რომელთა თარგმნა შეუძლებელია.
ასე რომ, აქ იქნება ტონა ანგლიციზმი.
და ბევრი გიფი.
და სურათებიც.

• ოდნავი სინანულის გარეშე. სტატიის ავტორი.

Როგორც იყო

მოდით, დავიწყოთ ოპერაციული აღდგენის ფანჯრის და დალუქული სარეზერვო ასლის ანალიზით (ან როგორც მათ უწოდებენ არააქტიური სარეზერვო ჯაჭვის დოკუმენტაციაში). მათი გაგების გარეშე, შემდგომი ახსნა შეუძლებელი იქნება.

როგორც სურათზე ვხედავთ, გვაქვს ერთგვარი სარეზერვო ჯაჭვი მონაცემთა ბლოკებით, რომელიც განლაგებულია საცავის Performance tier SOBR-ზე, რომელსაც უკავშირდება Capacity Tier. ჩვენი ოპერატიული სარეზერვო ფანჯარა სამი დღეა.

შესაბამისად, ორშაბათს შექმნილი .vbk ლუქავს წინა ჯაჭვს, რომლის ფანჯარა დაყენებულია სამ დღეს. და ეს ნიშნავს, რომ თქვენ შეგიძლიათ უსაფრთხოდ დაიწყოთ ამ სამი დღეზე ძველის გადასაღებ მოედანზე გადატანა.

მაგრამ კონკრეტულად რას გულისხმობდა დალუქული ჯაჭვი და რა შეიძლება გაიგზავნოს ტევადობის სროლის მოედანზე განახლება 4-ში?

Forward Incremental, ჯაჭვის დალუქვის ნიშანი არის ახალი სრული სარეზერვო ასლის შექმნა. და არ აქვს მნიშვნელობა როგორ მიიღება ეს სრული სარეზერვო საშუალება: განიხილება როგორც სინთეზური, ასევე აქტიური სრული სარეზერვო ასლები.

Reverse-ის შემთხვევაში, ეს არის ყველა ფაილი, რომელიც არ მოხვდება ოპერაციულ ფანჯარაში.

გადაბრუნებით წინ გაზრდის შემთხვევაში, ეს არის ყველა უკან დაბრუნება და .vbk, თუ არის სხვა .vbk შესრულების ზომებზე.

ახლა განვიხილოთ სარეზერვო ასლის ჯაჭვებთან მუშაობის ვარიანტი. აქ მხოლოდ GFS-ის შეკავების ქვეშ მყოფი ნივთების ტრანსპორტირება მოხდა. იმის გამო, რომ ყველაფერი, რაც ინახება უახლეს სარეზერვო ასლების ჯაჭვებში, შეიძლება შეიცვალოს ამა თუ იმ გზით.

ახლა მოდით შევხედოთ კაპოტის ქვეშ. იქ ხდება პროცესი, რომელსაც ეწოდება დეჰიდრატაცია - ცარიელი სარეზერვო ფაილების მოცულობის დატოვება და ამ ფაილებიდან ბლოკების გადაადგილება ტევადობის სროლის დიაპაზონში. ამ პროცესის ოპტიმიზაციისთვის გამოიყენება ეგრეთ წოდებული დეჰიდრატაციის ინდექსი, რომელიც საშუალებას გაძლევთ თავიდან აიცილოთ ბლოკების კოპირება, რომლებიც უკვე დაკოპირებულია ტევადობის სროლის დიაპაზონში.

ვნახოთ, როგორ გამოიყურება ეს მაგალითით: ვთქვათ, გვაქვს .vbk, რომელიც გამოვიდა ტრანზაქციის ფანჯრიდან და ეკუთვნის დალუქულ ჯაჭვს. ეს ნიშნავს, რომ ჩვენ გვაქვს სრული უფლება გადავიტანოთ ის ტევადობის სასროლეთზე. გადატანის დროს იქმნება მეტამონაცემების ფაილი გადაცემული ფაილის ტევადობის ტირეში და ბლოკებში. ბმულის დონის მეტამონაცემების ფაილი აღწერს რა ბლოკებისგან შედგება ჩვენი ფაილი. სურათზე მოცემულ შემთხვევაში, ჩვენი პირველი ფაილი შედგება a, b, c ბლოკებისგან და მეტამონაცემები შეიცავს ამ ბლოკების ბმულებს. როდესაც გვაქვს მეორე .vbk ფაილი, მზად არის გადასატანად და შედგება a, b და d ბლოკებისგან, ჩვენ, დეჰიდრატაციის ინდექსის გაანალიზებით, გვესმის, რომ მხოლოდ d ბლოკი უნდა გადავიდეს. და მისი მეტამონაცემების ფაილი შეიცავს ბმულებს ორ წინა ბლოკთან და ერთ ახალ ბლოკთან.

შესაბამისად, ამ ცარიელი ადგილების მონაცემებით შევსების პროცესს რეჰიდრატაცია ეწოდება. ის უკვე იყენებს რეჰიდრატაციის საკუთარ ინდექსს, რომელიც დაფუძნებულია უძველეს .vbk ფაილზე ადგილობრივი შესრულების მასშტაბით. ანუ, თუ მომხმარებელს სურს ფაილის დაბრუნება ტევადობის სროლის დიაპაზონიდან, ჩვენ ჯერ ვქმნით უძველესი სრული სარეზერვო ბლოკების ინდექსს და გადავიტანთ მხოლოდ დაკარგული ბლოკებს ტევადობის სროლის გალერეიდან. სურათზე წარმოდგენილ შემთხვევაში FullBackup1.vbk-ის რეჰიდრატაციისთვის რეჰიდრატაციის ინდექსის მიხედვით გვჭირდება მხოლოდ ბლოკი C, რომელსაც ვიღებთ ტევადობის სროლის დიაპაზონიდან. თუ შესანახი ღრუბლოვანი ობიექტი ემსახურება ტევადობის სროლის დიაპაზონს, ეს საშუალებას გაძლევთ დაზოგოთ უზარმაზარი თანხა.

აქ შეიძლება ჩანდეს, რომ ეს ტექნოლოგია იდენტურია WAN ამაჩქარებლებში გამოყენებულის, მაგრამ ეს მხოლოდ ასე ჩანს. ამაჩქარებლებში დედუპლიკაცია გლობალურია; აქ ლოკალური დედუპლიკაცია გამოიყენება თითოეულ ფაილში კონკრეტული ოფსეტურით. ეს ხდება ამოხსნილ ამოცანებს შორის განსხვავების გამო: აქ ჩვენ უნდა დავაკოპიროთ დიდი სრული სარეზერვო ფაილები და ჩვენი კვლევის მიხედვით, მაშინაც კი, თუ მათ შორის დიდი დრო გადის, ეს დედუპლიკაციის ალგორითმი იძლევა საუკეთესო შედეგს.

მაგრამ უფრო მეტი ინდექსები ინდექსების ღმერთისთვის! ასევე არის მონაცემთა აღდგენის ინდექსი! როდესაც ვიწყებთ მოწყობილობის აღდგენას, რომელიც მდებარეობს სიმძლავრის ტირეში, ჩვენ წავიკითხავთ მხოლოდ მონაცემთა უნიკალურ ბლოკებს, რომლებიც არ არიან შესრულების ტირეში.

Როგორ მოხდა?

ეს ყველაფერი შესავალი ნაწილისთვის. საკმაოდ დეტალურია, მაგრამ როგორც ზემოთ აღინიშნა, ამ დეტალების გარეშე შეუძლებელი იქნება იმის ახსნა, თუ როგორ მუშაობს ახალი ფუნქციები. ამიტომ, ყოველგვარი შეფერხების გარეშე, გადავიდეთ პირველზე.

კოპირების რეჟიმი

იგი ძირითადად დაფუძნებულია არსებულ ტექნოლოგიებზე, მაგრამ ახორციელებს გამოყენების სრულიად განსხვავებულ ლოგიკას. 

ამ რეჟიმის მიზანია უზრუნველყოს, რომ ყველა მონაცემს, რომელიც მდებარეობს ლოკალურ დონეზე, აქვს ასლი სიმძლავრის ტირეში.

თუ შეადარებთ Move-სა და Copy-ის რეჟიმებს, ის ასე გამოიყურება:

• მხოლოდ დალუქული ჯაჭვის გადაადგილებაა შესაძლებელი. ასლის რეჟიმის შემთხვევაში, აბსოლუტურად ყველაფერი გადადის, მიუხედავად იმისა, თუ რა ხდება სარეზერვო სამუშაოში.
• გადაადგილება ხდება მაშინ, როდესაც ფაილები სცილდება ოპერაციული სარეზერვო ფანჯრის საზღვრებს და კოპირება იწყება როგორც კი სარეზერვო ფაილი გამოჩნდება.
• კოპირებისთვის ახალი მონაცემების მონიტორინგი მუდმივად ხდება და მისი გადატანისთვის 4 საათში ერთხელ მოქმედებდა.

ახალი რეჟიმის განხილვისას, მე ვთავაზობ მარტივი მაგალითებიდან რთულზე გადასვლას.

ყველაზე გავრცელებულ შემთხვევაში, ჩვენ უბრალოდ გვაქვს ახალი ფაილები მატებით და უბრალოდ ვაკოპირებთ მათ ტევადობის სროლის დიაპაზონში. მიუხედავად იმისა, თუ რა რეჟიმი გამოიყენება სარეზერვო სამუშაოში, განურჩევლად იმისა, ეკუთვნის თუ არა ის ჯაჭვის დალუქულ ნაწილს, მიუხედავად იმისა, ამოიწურა თუ არა ჩვენს ოპერაციულ ფანჯარას ვადა. უბრალოდ აიღეს და დააკოპირეს.

ამის უკან პროცესი ჯერ კიდევ დეჰიდრატაციაა, როგორც ზემოთ აღწერილი. კოპირების რეჟიმში, ის ასევე დარწმუნდება, რომ ჩვენ არ ვაკოპირებთ ბლოკებს, რომლებიც უკვე ჩვენს მეხსიერებაშია. ერთადერთი განსხვავება ისაა, რომ თუ ფილმის რეჟიმში ჩვენ შევცვალეთ რეალური ფაილები მოჩვენებითი ფაილებით, აქ მათ არანაირად არ ვეხებით და ყველაფერს ისე დავტოვებთ, როგორც არის. წინააღმდეგ შემთხვევაში, ეს არის ზუსტად იგივე დეჰიდრატაციის ინდექსი, რომელიც გულდასმით ცდილობს დაზოგოს თქვენი ფული და დრო.

ჩნდება კითხვა - თუ UI-ს დააკვირდებით, არის შესაძლებლობა ერთდროულად აირჩიოთ ორივე ვარიანტი. როგორ იმუშავებს ასეთი კომბინირებული რეჟიმი?

გავიგოთ.

დასაწყისი სტანდარტულია: სარეზერვო ფაილი იქმნება და დაუყოვნებლივ კოპირდება. მასზე იქმნება ნამატი და ასევე კოპირებულია. ეს ხდება მანამ, სანამ არ მივხვდებით, რომ ფაილებმა დატოვეს ჩვენი ოპერაციული ფანჯარა და გაჩნდა დალუქული ჯაჭვი. ამ ეტაპზე ჩვენ ვასრულებთ დეჰიდრატაციის ოპერაციას და ვცვლით ამ ფაილებს მოჩვენებითი ფაილებით. რა თქმა უნდა, ჩვენ აღარაფერს ვაკოპირებთ ტევადობის სროლის დიაპაზონში.

მთელი ეს მომხიბლავი ლოგიკა პასუხისმგებელია ინტერფეისის მხოლოდ ერთ ყუთზე: დააკოპირეთ სარეზერვო ასლები ობიექტების შესანახად, როგორც კი ისინი იქმნება.

რატომ გვჭირდება ეს კოპირების რეჟიმი?

კიდევ ჯობია კითხვა ასე ჩამოვაყალიბოთ: რა რისკებისგან ვართ დაცული მისი დახმარებით? რა პრობლემის მოგვარებაში გვეხმარება?

პასუხი აშკარაა: რა თქმა უნდა, ეს არის მონაცემთა აღდგენა. თუ ჩვენ გვაქვს ლოკალური მონაცემების სრული ასლი ობიექტის შენახვაზე, მაშინ რაც არ უნდა მოხდეს ჩვენს პროდუქტს, ჩვენ ყოველთვის შეგვიძლია აღვადგინოთ მონაცემები პირობითი Amazon-ში მდებარე ფაილებიდან.

მოდით გავიაროთ შესაძლო სცენარები, მარტივიდან უფრო რთულამდე.

უმარტივესი უბედურება, რომელიც შეიძლება დაგვხვდეს, არის სარეზერვო ჯაჭვის ერთ-ერთი ფაილის მიუწვდომლობა.

უფრო სამწუხარო ამბავი ის არის, რომ ჩვენი SOBR საცავი გატეხილია.

ეს კიდევ უფრო უარესდება, როდესაც მთელი SOBR საცავი მიუწვდომელია, მაგრამ ტევადობის სროლის დიაპაზონი მუშაობს.
და ყველაფერი მართლაც ცუდია - ეს არის მაშინ, როდესაც სარეზერვო სერვერი კვდება და თქვენი პირველი სურვილია სცადოთ კანადის საზღვარზე გაშვება ათ წუთში.

ახლა მოდით შევხედოთ თითოეულ სიტუაციას ცალკე.

როდესაც ჩვენ დავკარგეთ ერთი (და კიდევ რამდენიმე) სარეზერვო ფაილი, მაშინ ყველაფერი რაც უნდა გავაკეთოთ არის საცავის ხელახალი სკანირების პროცესის დაწყება და დაკარგული ფაილი შეიცვლება მოჩვენებითი ფაილით. და რეჰიდრატაციის პროცესის გამოყენებით (რომელიც სტატიის დასაწყისში იყო განხილული), მომხმარებელს შეეძლება მონაცემების ჩამოტვირთვა ტევადობის სროლის დიაპაზონიდან ადგილობრივ საცავში.

ახლა სიტუაცია უფრო გართულდა. დავუშვათ, რომ ჩვენი SOBR შედგება ორი განზომილებისგან, რომელიც მუშაობს Performance რეჟიმში, რაც ნიშნავს, რომ ჩვენი .vbk და .vib გავრცელებულია მათზე საკმაოდ არათანაბარი ფენით. და დროის გარკვეულ მომენტში, ერთ-ერთი ზონა მიუწვდომელია და მომხმარებელს სასწრაფოდ სჭირდება აპარატის აღდგენა, რომლის მონაცემების ნაწილი სწორედ ამ ზომაზეა.

მომხმარებელი ამუშავებს აღდგენის ოსტატს, ირჩევს წერტილს, რომლის აღდგენაც სურს და ოსტატი მუშაობის დროს ხვდება, რომ მას არ აქვს ადგილობრივი აღდგენისთვის საჭირო ყველა მონაცემი და, შესაბამისად, უნდა გადმოიწეროს სროლის შესაძლებლობიდან. გალერეა. ამავდროულად, ბლოკები, რომლებიც რჩება ადგილობრივ მეხსიერებაში, არ ჩამოიტვირთება ღრუბელიდან. დიდება აღდგენის ინდექსს (დიახ, ეს ასევე ნახსენები იყო სტატიის დასაწყისში).

ამ შემთხვევის ქვეტიპი არის ის, რომ მთელი SOBR საცავი მიუწვდომელი გახდა. ამ შემთხვევაში, ჩვენ არაფერი გვაქვს დასაკოპირებელი ლოკალური მეხსიერებიდან და ყველა ბლოკი ჩამოტვირთულია ღრუბელიდან.

და ყველაზე საინტერესო სიტუაცია არის ის, რომ სარეზერვო სერვერი გარდაიცვალა. აქ ორი ვარიანტია: ადმინისტრატორი მშვენიერია და კონფიგურაციის სარეზერვო ასლებს აკეთებს, ხოლო ადმინი თავად ბოროტი პინოქიოა და კონფიგურაციის სარეზერვო ასლებს არ აკეთებს.

პირველ შემთხვევაში, მისთვის საკმარისი იქნება უბრალოდ სადმე განათავსოს VBR-ის სუფთა ინსტალაცია და აღადგინოს მისი მონაცემთა ბაზა სარეზერვოდან სტანდარტული საშუალებების გამოყენებით. ამ პროცესის ბოლოს ყველაფერი ნორმალურად დაბრუნდება. ან აღდგება ზემოთ მოყვანილი ერთ-ერთი სცენარის მიხედვით.

მაგრამ თუ ადმინი ან მისი საკუთარი მტერია, ან კონფიგურაციის სარეზერვო ასლს ასევე განიცადა ეპიკური მარცხი, მაშინ აქაც არ დავტოვებთ მას ბედის წყალობას. ამ შემთხვევისთვის ჩვენ შემოვიღეთ ახალი პროცედურა, სახელწოდებით Import Object Storage. ის საშუალებას გაძლევთ გამოტოვოთ SOBR საცავი ხელით ხელახლა შექმნისა და მასზე ტევადობის სროლის დიაპაზონის მიმაგრების პროცესი შემდგომი ხელახალი სკანირებით და უბრალოდ დაამატოთ შენახვის ობიექტი Vim ინტერფეისში და გაუშვათ Import Storage Repository პროცედურა. ერთადერთი, რაც ხელს უშლის თქვენსა და თქვენს სარეზერვო ასლებს შორის, არის პაროლის შეყვანის მოთხოვნა, თუ თქვენი სარეზერვო ასლები დაშიფრულია.

ეს, ალბათ, ეხება კოპირების რეჟიმს და ჩვენ გადავდივართ

დალუქული რეჟიმი

მთავარი იდეა ისაა, რომ ახალი სარეზერვო ასლები ვერ გამოჩნდება საცავის არჩეულ SOBR ზონაში. V10-მდე ჩვენ გვქონდა მხოლოდ Maintenance Mode, როდესაც საცავთან ნებისმიერი მუშაობა სრულიად აკრძალული იყო. ერთგვარი მყარი რეჟიმი მეხსიერების გამორთვისთვის, სადაც ხელმისაწვდომია მხოლოდ Evacuate ღილაკი, რომელიც ერთჯერად გადააქვს სარეზერვო ასლებს სხვა მასშტაბით.

და დალუქული რეჟიმი ერთგვარი "რბილი" ვარიანტია: ჩვენ კრძალავთ ახალი სარეზერვო ასლების შექმნას და თანდათან ვშლით ძველებს შერჩეული შენახვის მიხედვით, მაგრამ ამ პროცესში ჩვენ არ ვკარგავთ შენახული წერტილებიდან აღდგენის უნარს. ძალიან სასარგებლო რამ, როდესაც ჩვენ გვაქვს ტექნიკის ნაწილი მისი სიცოცხლის დასასრულს და გვჭირდება მისი გამოცვლა, ან უბრალოდ უნდა გავათავისუფლოთ ის რაღაც უფრო მნიშვნელოვანისთვის, მაგრამ არსად გვაქვს მისი აღება და ყველაფრის ერთდროულად გადატანა. ან მისი წაშლა არ შეიძლება.

შესაბამისად, მოქმედების პრინციპი საკმაოდ მარტივია: აუცილებელია აკრძალოს ყველა ჩაწერის ოპერაცია (ახალი მონაცემების გამოჩენა), წაკითხვის (აღდგენის) და წაშლის (შეკავება) დატოვება.

ორივე რეჟიმი შეიძლება გამოყენებულ იქნას ერთდროულად, მაგრამ გახსოვდეთ, რომ ტექნიკური მომსახურება უფრო მაღალი პრიორიტეტია.

მაგალითად, განვიხილოთ SOBR, რომელიც შედგება ორი მასშტაბისგან. დავუშვათ, რომ პირველი ოთხი დღის განმავლობაში ჩვენ ვქმნიდით სარეზერვო ასლებს Forward Forever Incremental რეჟიმში და შემდეგ ვლუქავთ მასშტაბს, რაც იწვევს იმ ფაქტს, რომ ჩვენ ვიწყებთ ახალი აქტიური სრულის შექმნას მეორე ხელმისაწვდომ მასშტაბზე. თუ ჩვენი შეკავება ოთხია, მაშინ როდესაც დალუქულ ზონაზე მდებარე მთელი ჯაჭვი სცილდება მის საზღვრებს, ის იშლება სუფთა სინდისით.

არის სიტუაციები, როდესაც წაშლა ხდება ადრე. მაგალითად, ეს არის Forward incremental პერიოდული სრულებით. თუ ჩვენ შევქმენით სრული სარეზერვო ასლები პირველი ორი დღის განმავლობაში და ხუთშაბათს გადავწყვიტეთ დალუქვა საცავი, მაშინ პარასკევს, როდესაც ახალი სარეზერვო ასლი შეიქმნება, ორშაბათის ფაილი წაიშლება, რადგან ამ მხრივ არანაირი დამოკიდებულება არ არსებობს. და თავად წერტილი არავისზეა დამოკიდებული. შემდეგ ველოდებით, სანამ ოთხი წერტილი შეიქმნება ხელმისაწვდომ ზომაზე და ვშლით დარჩენილ სამს, რომელთა წაშლა შეუძლებელია ერთმანეთისგან დამოუკიდებლად.

Reverse Incremental-ით ყველაფერი უფრო მარტივია. მასში უძველესი პუნქტები არაფერზეა დამოკიდებული და მათი უსაფრთხოდ წაშლაა შესაძლებელი. ამიტომ, როგორც კი ახალი .vbk შეიქმნება ახალ მასშტაბზე, ძველი .vrbs სათითაოდ წაიშლება.

სხვათა შორის, რატომ ვქმნით ახალ .vbk-ს ყოველ ჯერზე: თუ ჩვენ არ შევქმნით მას, არამედ გავაგრძელებდით ნამატების ძველ ჯაჭვს, მაშინ ძველი .vbk უსასრულოდ დიდხანს გაიყინება ნებისმიერ რეჟიმში, რაც ხელს უშლის მის წაშლას. ამიტომ, გადაწყდა, რომ როგორც კი მოცულობის დალუქვა, ჩვენ შევქმნით სრულ სარეზერვო ასლს თავისუფალ ზონაზე.

საქმე უფრო რთულია ტევადობის სროლის დიაპაზონში.

პირველი, მოდით შევხედოთ კოპირების რეჟიმს. დავუშვათ, რომ ოთხი დღის განმავლობაში აქტიურად ვქმნიდით სარეზერვო ასლებს, შემდეგ კი ტევადობის სროლის პოლიგონი დაილუქა. ჩვენ არ ვშლით არაფერს, მაგრამ თავმდაბლად ვიტანთ შეკავებას, რის შემდეგაც ვშლით მონაცემებს ტევადობის სროლის დიაპაზონიდან.

დაახლოებით იგივე ხდება გადაადგილების რეჟიმში - ველოდებით რეტუშს, ვშლით ძველს ლოკალურ საცავში და ვშლით ობიექტის საცავში შენახულს.

საინტერესო მაგალითი Forever forward incremental-ით. ჩვენ ვაყენებთ შეკავებას სამ წერტილში და ვიწყებთ სარეზერვო ასლების შექმნას ორშაბათიდან, რომლებიც რეგულარულად კოპირდება ღრუბელში. საცავის დალუქვის შემდეგ, სარეზერვო ასლების შექმნა გრძელდება სამი წერტილის შენარჩუნებით, მაგრამ ტევადობის ტირეში შენახული მონაცემები რჩება დამოკიდებული და არ შეიძლება წაიშალოს. ამიტომ, ველოდებით ხუთშაბათს, როდესაც ჩვენი .vbk სცილდება შეკავებას და მხოლოდ ამის შემდეგ მშვიდად ვშლით მთელ შენახულ ჯაჭვს.

და მცირე უარი პასუხისმგებლობაზე: აქ ყველა მაგალითი ნაჩვენებია ერთი მანქანით. თუ თქვენ გაქვთ რამდენიმე მათგანი თქვენს სარეზერვო ასლში, მაშინ მათი რეტუში განსხვავდება იმისდა მიხედვით, გაკეთდა თუ არა Active Full.

ძირითადად ეს ყველაფერია. მოდით გადავიდეთ ყველაზე მძიმე მახასიათებლებზე -

უცვლელობა

როგორც წინა პუნქტებში, პირველ რიგში, რა პრობლემას წყვეტს ეს ფუნქცია. როგორც კი ჩვენ ავტვირთავთ ჩვენს სარეზერვო ასლებს სადმე შესანახად, ჩნდება დიდი სურვილი, გარანტირებული იყოს მათი უსაფრთხოება, ანუ ფიზიკურად აკრძალოს მათი წაშლა და ნებისმიერი ცვლილება მოცემული შენახვის დროს. ადმინისტრატორების ჩათვლით, მათ შორის მათი root ანგარიშების ქვეშ. ეს საშუალებას გაძლევთ დაიცვათ ისინი შემთხვევითი ან განზრახ დაზიანებისგან. ნებისმიერს, ვინც მუშაობს AWS-ით, შეიძლება წააწყდეს მსგავს ფუნქციას, სახელწოდებით Object Lock.

ახლა მოდით შევხედოთ რეჟიმს ზოგადი თვალსაზრისით და შემდეგ ჩავუღრმავდეთ დეტალებს. ჩვენს მაგალითში, Immutability ჩართული იქნება ჩვენი ტევადობის სროლის დიაპაზონში ოთხი დღის შენარჩუნებით. ხოლო სარეზერვო რეჟიმში ჩართულია კოპირების რეჟიმი.

უცვლელობა არანაირად არ ურთიერთქმედებს ზოგად შეკავებასთან. მაგალითად, არ ამატებს დამატებით ქულებს ან რაიმე მსგავსს. უბრალოდ, ადამიანს არ შეუძლია წაშალოს სარეზერვო ფაილები ოთხი დღის განმავლობაში. თუ სარეზერვო ასლს გააკეთებთ ორშაბათს, მისი ფაილის წაშლას მხოლოდ პარასკევს შეძლებთ.

დეჰიდრატაციის ყველა ადრე ახსნილი კონცეფცია, ინდექსები და მეტამონაცემები აგრძელებს მუშაობას ზუსტად იგივე. მაგრამ ერთი პირობით - ბლოკი დაყენებულია არა მხოლოდ მონაცემებისთვის, არამედ მეტამონაცემებისთვისაც. ეს კეთდება იმ შემთხვევაში, თუ მზაკვარი თავდამსხმელი გადაწყვეტს წაშალოს ჩვენი მეტამონაცემების მონაცემთა ბაზა და თავიდან აიცილოს მონაცემთა ბლოკები უსარგებლო ბინარულ მუშად გადაქცევაში.

ახლა შესანიშნავი დროა ავხსნათ ჩვენი ბლოკის წარმოების ტექნოლოგია. ან დაბლოკოს გენერაცია. ამისათვის განიხილეთ სიტუაცია, რამაც გამოიწვია მისი გამოჩენა.

ავიღოთ ექვსდღიანი დროის შკალა და ქვემოთ აღვნიშნავთ უცვლელობის მოსალოდნელი ამოწურვის დროს. პირველ დღეს ვიღებთ და ვქმნით ფაილს, რომელიც შედგება მონაცემთა ბლოკისგან a და მისი მეტამონაცემებისგან. თუ უცვლელობა დაყენებულია სამ დღეს, ლოგიკურია ვივარაუდოთ, რომ მეოთხე დღეს მონაცემები განბლოკილია და წაიშლება. მეორე დღეს ჩვენ დავამატებთ ახალ ფაილს2, რომელიც შედგება b ბლოკისგან იგივე პარამეტრებით. ბლოკი a მაინც უნდა მოიხსნას მეოთხე დღეს. მაგრამ მესამე დღეს რაღაც საშინელება ხდება - იქმნება File3 ფაილი, რომელიც შედგება ახალი d ბლოკისგან და ძველი ბლოკის a ბმულისგან. ეს ნიშნავს, რომ ბლოკისა და მისი უცვლელობისთვის დროშა უნდა გადატვირთოს ახალ თარიღზე, რომელიც გადატანილია მეექვსე დღეს. და აქ ჩნდება პრობლემა - რეალურ სარეზერვო ასლებში არის ასეთი ბლოკების დიდი რაოდენობა. და მათი უცვლელობის პერიოდის გასახანგრძლივებლად, თქვენ უნდა გააკეთოთ უამრავი მოთხოვნა ყოველ ჯერზე. სინამდვილეში, ეს იქნება თითქმის გაუთავებელი ყოველდღიური პროცესი, რადგან დიდი ალბათობით ჩვენ ვიპოვით დუბლიკატირებული ბლოკების დიდ დასტას თითოეულ ასლთან ერთად. რას ნიშნავს მოთხოვნის დიდი რაოდენობა ობიექტების შენახვის პროვაიდერებისგან? უფლება! უზარმაზარი გადასახადი თვის ბოლოს.

და იმისათვის, რომ არ გამოავლინოთ თქვენი საყვარელი კლიენტები მნიშვნელოვან ფულზე, გამოიგონეს ბლოკის გენერირების მექანიზმი. ეს არის დამატებითი პერიოდი, რომელსაც ჩვენ ვუმატებთ დადგენილ უცვლელობის პერიოდს. ქვემოთ მოცემულ მაგალითში ეს პერიოდი ორი დღეა. მაგრამ ეს მხოლოდ მაგალითია. სინამდვილეში, ისინი იყენებენ საკუთარ ფორმულას, რომელიც იძლევა დაახლოებით ათ დამატებით დღეს ყოველთვიური ჩაკეტვის დროს.

მოდით გავაგრძელოთ იგივე სიტუაციის განხილვა, მაგრამ ბლოკის გენერირებით. პირველ დღეს ჩვენ ვქმნით file1 ბლოკიდან a და მეტამონაცემებიდან. ჩვენ ვამატებთ გენერირების პერიოდს და უცვლელობას - ეს ნიშნავს, რომ ფაილის წაშლის შესაძლებლობა მეექვსე დღეს იქნება. თუ მეორე დღეს შევქმნით File2-ს, რომელიც შედგება b ბლოკისგან და a ბლოკის ბმულისგან, მაშინ არაფერი მოხდება წაშლის მოსალოდნელ თარიღთან. ის ისე იდგა, როგორც მეექვსე დღეს. და ამით ჩვენ ვცდილობთ დავზოგოთ ფული მოთხოვნის რაოდენობაზე. ერთადერთი სიტუაცია, როდესაც ვადა შეიძლება გადაიტანოს, არის თუ თაობის ვადა ამოიწურა. ანუ, თუ მესამე დღეს ახალი File3 შეიცავს a-ს დაბლოკვის ბმულს, მაშინ მე-2 თაობა დაემატება, რადგან Gen1 უკვე ამოიწურა. ხოლო a ბლოკის წაშლის სავარაუდო თარიღი გადაინაცვლებს მერვე დღეს. ეს საშუალებას გვაძლევს მკვეთრად შევამციროთ მოთხოვნის რაოდენობა დედუპლიკირებული ბლოკების სიცოცხლის გაგრძელების მიზნით, რაც კლიენტებს ზოგავს ტონა ფულს.

თავად ტექნოლოგია ხელმისაწვდომია S3 და S3-თან თავსებადი ტექნიკის მომხმარებლებისთვის, რომელთა მწარმოებლები გარანტიას იძლევიან, რომ მათი დანერგვა არ განსხვავდება Amazon-ისგან. აქედან მომდინარეობს პასუხი ლეგიტიმურ კითხვაზე, რატომ არ არის მხარდაჭერილი Azure - მათ აქვთ მსგავსი ფუნქცია, მაგრამ ის მუშაობს კონტეინერების დონეზე და არა ცალკეული ობიექტების დონეზე. სხვათა შორის, თავად ამაზონს აქვს ობიექტის დაბლოკვა ორ რეჟიმში: შესაბამისობა და მმართველობა. მეორე შემთხვევაში, რჩება შესაძლებლობა, რომ ყველაზე დიდი ადმინი ადმინისტრატორებზე და root ზემოთ, მიუხედავად ობიექტის დაბლოკვისა, მაინც წაშლის მონაცემებს. შესაბამისობის შემთხვევაში, ყველაფერი მჭიდროდ არის მიმაგრებული და სარეზერვო ასლებს ვერავინ წაშლის. ამაზონის ადმინებიც კი (მათი ოფიციალური განცხადებების მიხედვით). ეს არის რეჟიმი, რომელსაც ჩვენ ვუჭერთ მხარს.

და, როგორც ყოველთვის, რამდენიმე სასარგებლო ბმული:

• on ბლოკის თაობა ყველა დეტალში.
• ყველა ინფორმაცია Veeam Backup & Replication 10 საუკეთესოდ
• О სიმძლავრის დონე დეტალურად

წყარო: www.habr.com