უკან დაბრუნება
SiTech
სარეზერვო ასლები მარტივი არ არის: რატომ არ კმარა მეორე დისკი
SiTech AI Team2 წთ. საკითხავი

სარეზერვო ასლები მარტივი არ არის: რატომ არ კმარა მეორე დისკი

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

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

მეორე ასლი მხოლოდ დასაწყისია

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

ისინი ორ კითხვას აჩენენ. რამდენად ხშირად კეთდება სნეფშოტი — ეს აღდგენის სამიზნე წერტილია (RPO): ფინანსურ ინსტიტუტებში 30 წამზე ნაკლები, მცირე კომპანიებში 24 საათი ან მეტი. რამდენ ხანს ინახება — სუფთა საცავის პრობლემაა, რომელსაც როტაცია წყვეტს: დღიური სნეფშოტები ინახება 14 დღე, კვირეული — შვიდი კვირა, თვიური — ერთი წელი.

დედუპლიკაცია და რეალური ხარვეზები

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

სახლის ლაბორატორიაში სხვა ხარვეზები ჩნდება: კონტეინერები root-ის საკუთრებაში მყოფ ფაილებს ქმნიან და ჩვეულებრივი cron-იდან გაშვებული ასლი ვარდება, ხოლო ბაზები, რომლებიც მონაცემებს პარტიებად ჩაწერენ, ცალკე დამპის გარეშე დაზიანებულ აღდგენას იძლევიან. რისკი აპარატურაცაა — აქედან მოდის 3-2-1 წესი: სამი ასლი, ორი ტიპის მატარებელი, ერთი ოფისგარეთ. ობიექტურ საცავში, მაგალითად S3-ში, მეტამონაცემები იკარგება და უამრავი წვრილი ფაილის შენახვა ძვირია, ამიტომ არქივები ნაწილებად უნდა შეფუთოთ.

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

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

SSiTech

SiTech — AI-გაძლიერებული ვებ დეველოპმენტი

ვქმნით სწრაფ, თანამედროვე ვებსაიტებს და AI-ს ვაერთიანებთ ქართული ბიზნესებისთვის. გაქვთ პროექტი ან კითხვა? სიამოვნებით დაგეხმარებით.