S3 საცავის ზომის გამოთვლა და backup-ის 3-2-1 წესი

S3 საცავის ზომა სამი რიცხვით გამოითვალე: რამდენ მონაცემს იცავ, რამდენ წარსულ ვერსიას ინახავ და რამდენად კარგად არიდებს შენი backup-ის ხელსაწყო ერთი და იმავე ბაიტების ორჯერ შენახვას. 5 GB-იანი ვებსაიტი, შენახული თოთხმეტი ყოველდღიური სრული ასლის სახით, 70 GB-ს საჭიროებს; იგივე ისტორია დედუპლიკაციის მქონე ხელსაწყოში, მაგალითად restic-ში, ხშირად 10-დან 15 GB-მდე ეტევა. შემდეგ გადაწყვიტე, სად დგას bucket 3-2-1 წესში - მონაცემების სამი ასლი, ორ სხვადასხვა ტიპის საცავზე, ერთი მათგანი სხვა ადგილას. ერთასლიანი bucket ერთ ლოკაციაში კარგი მეორე ან მესამე ასლია და ცუდი ერთადერთი ასლი, და რეპლიცირებული საცავიც არ არის იგივე, რაც backup: რეპლიკაცია შენს შეცდომებსაც ერთგულად აკოპირებს. ეს პოსტი ორივე კითხვას რეალური რიცხვებით განიხილავს, რომ სწორი დონე იყიდო და ზუსტად იცოდე, რისგან იცავს ის და რისგან არა.

3-2-1 წესი და რისთვისაა თითოეული რიცხვი#

წესი cloud საცავზე ძველია და იმიტომ გადარჩა, რომ თითოეული რიცხვი სხვადასხვა მარცხს პასუხობს.

გავრცელებული თანამედროვე გაფართოებაა 3-2-1-1-0: ერთი ასლი offline ან უცვლელი, რომ მას ვერ წაშლის ის, ვისაც შენი ავტორიზაციის მონაცემები აქვს, და ნული შეცდომა, როცა აღდგენას ამოწმებ. ბოლო ციფრი არის ის, რასაც ხალხი გამოტოვებს, და ის, რასაც ყველაზე დიდი მნიშვნელობა აქვს. backup-ები, რომლებიც მართლა აღდგება ამას ვრცლად ასაბუთებს.

რა ითვლება "საცავის სხვა ტიპად", დღეს უფრო თავისუფალია, ვიდრე მაშინ, როცა წესი ლენტს და დისკს ნიშნავდა. მთავარი დამოუკიდებლობაა: პანელის backup და S3 bucket სხვა სერვისზე სხვადასხვა სისტემაა, სხვადასხვა ავტორიზაციის მონაცემებით და მარცხის სხვადასხვა გზებით, და სწორედ ამას ესწრაფვის "2". ორი საქაღალდე ერთ სერვერზე საცავის ორი ტიპი არ არის. ორი bucket ერთი და იმავე access key-ს ქვეშ ძლივს ითვლება ორ ასლად.

ერთი ასლი, რეპლიცირებული, და რისგან იცავს თითოეული#

საცავის პროვაიდერები საიმედოობას სხვადასხვანაირად აღწერენ, და ღირს ზუსტად გაიგო, რას გპირდებიან.

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

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

ახლა შეხედე, რა ანადგურებს backup-ებს პრაქტიკაში:

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

RE:NODE-ის S3 საცავი ერთასლიანი ტიპისაა, და ამას პირდაპირ ამბობს: შენი მონაცემების ერთი ასლი, NVMe-ზე, ერთ ლოკაციაში გერმანიაში, რეპლიკაციის გარეშე. საცავის გეგმებს პანელის backup-ის სლოტებიც არ აქვთ - bucket თავადაა backup და არა რამე, რისი backup-იც კეთდება. ეს მას კარგ ადგილად აქცევს შენი backup-ების მეორე ასლისთვის და აპლიკაციის ატვირთვებისთვის, რომლებიც სხვაგანაც არსებობს. ის არ უნდა იყოს ერთადერთი ადგილი, სადაც რამე ინახება.

რა ეკუთვნის ობიექტების საცავს#

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

კარგად ერგება:

• backup-ის ასლები - restic-ის რეპოზიტორიები, მონაცემთა ბაზის dump-ები, დაარქივებული თამაშის სამყაროები, ფაილებად ექსპორტირებული სერვერის snapshot-ები.
• მომხმარებლების ატვირთვები და მედია - ავატარები, მიმაგრებული ფაილები, პროდუქტის სურათები, გენერირებული PDF-ები, თუ აპლიკაცია ან backup-ის დავალება მათ სხვაგანაც ინახავს.
• build-ისა და რელიზის არტეფაქტები - ვერსიებიანი ფაილები, რომელთა მოტანაც რამდენიმე სერვერიდან გინდა.
• ლოგების არქივები - შეკუმშული დღიური ლოგები, გატანილი იმ სერვერიდან, რომელმაც ისინი დაწერა.
• მონაცემების ექსპორტი და გადაცემა - ფაილები, რომლებსაც presigned ბმულით აზიარებ ელფოსტის მიმაგრების ნაცვლად.

ცუდად ერგება:

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

რამდენი ადგილი: არითმეტიკა#

ზომას სამი მონაცემი წყვეტს:

1. წყაროს ზომა - რასაც იცავ, შეკუმშვის შემდეგ. მონაცემთა ბაზები კარგად იკუმშება (ტექსტით მდიდარი dump-ებისთვის ხშირად 5-10x); სურათები, ვიდეო და თამაშის სამყაროები თითქმის არა.
2. შენახვის ვადა - აღდგენის რამდენ წერტილს ინახავ.
3. ცვლილების ტემპი და დედუპლიკაცია - აღდგენის თითოეული წერტილის რა ნაწილია ახალი მონაცემები, და ინახავს თუ არა ხელსაწყო უცვლელ მონაცემებს თავიდან.

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

შედეგს მარაგი დაამატე. ორი რამ ადგილს მოულოდნელად ჭამს: მიტოვებული multipart ატვირთვები (შუა გზაზე მოკლული დიდი ატვირთვა თავის ნაწილებს ტოვებს, სანამ ვინმე მათ არ გააუქმებს) და თავად წყაროს ზრდა. გონივრული წესია, იყიდო დაახლოებით 1.5-ჯერ მეტი, ვიდრე არითმეტიკა ამბობს, და ყოველთვიურად შეხედო რეალურ გამოყენებას.

შენახვის ვადა: რამდენად შორს უნდა შეგეძლოს უკან დაბრუნება#

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

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

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

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

გამოთვლილი მაგალითები#

Minecraft სერვერი 3 GB-იანი სამყაროთი. სამყაროები თითქმის არ იკუმშება. თოთხმეტ თარიღიან სრულ ასლს 42 GB დასჭირდებოდა; restic, სადაც region ფაილების უმეტესობა ღამიდან ღამემდე არ იცვლება, ჩვეულებრივ ინახავს პირველ ასლს პლუს რამდენიმე ასეულ მეგაბაიტს დღეში - ვთქვათ, 6-9 GB ორი კვირის ყოველდღიურებისა და რამდენიმე ყოველთვიურისთვის. restic-ით 10 GB-იანი დონე საკმარისია; თარიღიანი სრული ასლებისთვის - 50 GB-იანი. თამაშის სერვერის backup-ები S3-ში დავალებას აწყობს.

ვებ-აპლიკაცია 2 GB-იანი PostgreSQL ბაზით და 20 GB ატვირთვებით. custom ფორმატის dump დაახლოებით 400 MB-მდე იკუმშება. 7 ყოველდღიური, 5 ყოველკვირეული და 12 ყოველთვიური dump-ის შენახვა 24 ფაილია, დაახლოებით 10 GB. ატვირთვები, restic-ით ისტორიით სინქრონიზებული, 20 GB-ია პლუს მათი ზრდა. ჯამში დღეს დაახლოებით 35 GB, ასე რომ 50 GB-იანი დონე ზრდის მარაგით. მონაცემთა ბაზის dump-ები S3-ში განრიგით შენახვის ვადის სკრიპტს შეიცავს.

პატარა ოფისი 60 GB საერთო დოკუმენტებით. ოფისის ფაილები ზომიერად იკუმშება და ნელა იცვლება. restic-ს 30 ყოველდღიურით და 12 ყოველთვიურით შეიძლება 75-90 GB დასჭირდეს. ეს 100 GB-იანი დონეა - და ბიზნესისთვის მესამე ასლი სახლში ან მეორე პროვაიდერთან არჩევითი არ არის.

RE:NODE-ის საცავის დონეები 10 GB-დან 100 GB-მდეა, თვეში $1.5-დან. დონის აწევა არსებულ სერვერზე ლიმიტს ცვლის და მას თავიდან არ აწყობს, ამიტომ პატარიდან დაწყება და ზრდა გონივრული სტრატეგიაა, თუ გამოყენებას ზღვარამდე მიღწევამდე ადევნებ თვალს და არა მის შემდეგ.

რეალური გამოყენების შემოწმება#

გაზომე bucket და არა შენი შეფასება. ორი ბრძანება ჯამს გაჩვენებს:

$ aws s3 ls s3://backups --recursive --summarize --human-readable --profile store | tail -n 2$ rclone size store:backups

ორივე ყველა ობიექტს ჩამოთვლის, ამიტომ bucket-ზე მილიონობით გასაღებით დრო სჭირდებათ; ჩვეულებრივი backup-ის bucket-ებისთვის წამებში სრულდება. ასევე მოძებნე დავიწყებული multipart ატვირთვები, რომლებიც ჩვეულებრივ ჩამონათვალში არ ჩანს, მაგრამ ადგილს იკავებს:

$ aws s3api list-multipart-uploads --bucket backups --profile store$ aws s3api abort-multipart-upload --bucket backups --key big.tar --upload-id <id> --profile store

restic-ის რეპოზიტორიებისთვის restic stats --mode raw-data გაჩვენებს, რამდენ ადგილს იყენებს რეპოზიტორია სინამდვილეში დედუპლიკაციის შემდეგ, და სწორედ ეს რიცხვი უნდა შეადარო შენს დონეს. და თუ გამოყენება შენს მონაცემებზე სწრაფად იზრდება, ჩვეულებრივი მიზეზი შენახვის ვადის დავალებაა, რომელმაც გაშვება შეწყვიტა - შეამოწმე, რომ forget --prune ან შენი წაშლის სკრიპტი ისევ სრულდება.

3-2-1 სისტემის აწყობა ერთასლიანი bucket-ით#

ერთასლიანი S3 bucket ბუნებრივად ერგება სამიდან ერთ-ერთად. რამდენიმე განლაგება, რომელიც წესს აკმაყოფილებს:

თითოეული ისარი ცალკე დავალებაა საკუთარი განრიგით, და თითოეული ბლოკი შეიძლება დაიკარგოს ისე, რომ დანარჩენები თან არ გაიყოლოს. განლაგების წაკითხვა ბლოკ-ბლოკ:

• ასლი 1 ცოცხალი მონაცემებია სერვერზე.
• ასლი 2 პანელის backup-ებია, შენახული იმ მანქანის გარეთ, რომელსაც იცავს, და ერთი ღილაკით აღდგენადი - ყველაზე სწრაფი აღდგენა ყოველდღიური შეცდომებისთვის.
• ასლი 3 S3 bucket-ია, რომელსაც ავსებს დავალება საკუთარი ავტორიზაციის მონაცემებით და საკუთარი შენახვის ვადით. ის გადაურჩება სერვერის წაშლას, რომელიც პანელის backup-ებს თან მიაქვს.
• გარე ასლი არის ის, რასაც მხოლოდ bucket ვერ მოგცემს, როცა ის სერვერთან ერთ ლოკაციაშია. თვიური ჩამოტვირთვა სახლის დისკზე, ან მეორე bucket სხვა პროვაიდერთან, რომელსაც პირველიდან rclone sync ავსებს, ამ ხარვეზს ხურავს. ჰობი-პროექტისთვის თვიური ჩამოტვირთვა სავსებით საკმარისია; ბიზნესისთვის ავტომატიზაცია გააკეთე.

ავტორიზაციის მონაცემები ცალ-ცალკე შეინახე. აპლიკაციას არ უნდა ჰქონდეს გასაღებები, რომლებსაც საკუთარი backup-ების წაშლა შეუძლია. თუ სერვერი, რომელზეც backup-ის დავალება ეშვება, გატეხილია, თავდამსხმელი იღებს ყველა გასაღებს, რაც მასზეა, ამიტომ ასლი, რომლის წაშლაც დავალებას არ შეუძლია - ჩამოტვირთვა სახლში - არის შენი offline "1" 3-2-1-1-0-ში.

შემოწმება, რომ აღდგება#

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

1. bucket-იდან: ჩამოტვირთე dump ან restic restore latest --target /tmp/restore-test და ჩატვირთე სატესტო ბაზაში ან სატესტო სერვერზე.
2. გარე ასლიდან: გახსენი ფაილი სახლის დისკიდან და შეამოწმე, რომ ის მოსალოდნელი თარიღისაა.
3. ჩაიწერე, რამდენი ხანი დასჭირდა თითოეულს. 50 GB-ის ჩამოტვირთვას სწრაფ ხაზზეც კი რეალური დრო სჭირდება, და ეს დრო შენი გათიშვის ნაწილია.

აღდგენის ტესტირება მანამ, სანამ დაგჭირდება ამას ჩამონათვალად აქცევს.

FAQ#

უსაფრთხოა ერთასლიანი bucket backup-ებისთვის?

როგორც ერთი ასლი რამდენიმეს შორის - კი. მისი რისკი თავმოყრილია ერთ სისტემაში ერთ ადგილას, და სწორედ ამისთვისაა 3-2-1-ის დანარჩენი ასლები. როგორც ერთადერთი backup - არა, მაგრამ ეს ნებისმიერ ცალკეულ საცავის სისტემას ეხება, რეპლიცირებულს თუ არა.

ანაცვლებს რეპლიკაცია backup-ებს?

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

რამდენი დღის backup-ები უნდა შევინახო?

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

ითვლება backup-ები ჩემს საცავში, თუ მათ წავშლი?

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

უნდა დავშიფრო backup-ები S3-ში?

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