backup-ებს ყველა ყიდის. გაცილებით ცოტა ამბობს, სად ინახება ისინი, და ეს ერთადერთი ნაწილია, რომელიც წყვეტს, დაგეხმარება თუ არა ის, როცა რაღაც არასწორად წავა. backup არქივი არ არის - ეს არის ასლი, რომლის აღდგენაც შეგიძლია, მუშა აპარატურაზე, შენთვის მისაღებ დროში, და რომელიც შეიცავს ყველაფერს, რაც სერვერს სჭირდება, რომ ისევ თავად იყოს. რასაც ადამიანები backup-ს უწოდებენ, უმეტესობა ამ ოთხი გამოცდიდან ერთს ვერ გადის და ჩვეულებრივ ბოლოს: ბაზა ცალკე სერვისი იყო, გაშვების ცვლადები ფაილები არასოდეს ყოფილა, ან plugin-ის მონაცემების ნახევარი საქაღალდეში იყო, რომლის ჩართვაც არავის მოსვლია აზრად.
ეს პოსტი ერთი-ორი სერვერის backup პოლიტიკის ფორმაზეა - რა შედის, სად ინახება ასლები, რამდენ ხანს ცოცხლობს და რა თანმიმდევრობით აბრუნებ ყველაფერს. რეპეტიცია, რომელიც ამტკიცებს, რომ ეს ყველაფერი მუშაობს, ცალკე საქმეა და ფარავს პოსტი აღდგენის გამოცდა, სანამ დაგჭირდება, ხოლო ბაზებს საკუთარი წესები აქვს პოსტში ბაზის backup-ები და აღდგენა.
რა უნდა იყოს backup-ში#
დაიწყე კითხვით "თუ ეს სერვერი ახლავე წაიშალა, რა დამჭირდება მის ზუსტად ხელახლა ასაგებად?" და პასუხი არასოდეს არის უბრალოდ save ფაილი.
| დატვირთვა | არქივში უნდა იყოს | სხვაგან ცხოვრობს |
|---|---|---|
| Minecraft (Paper) | world/, world_nether/, world_the_end/, plugins/, server.properties, ops.json, whitelist.json, banned-players.json | Paper-ის build ნომერი, Java-ს ვერსია, ნებისმიერი plugin, რომელიც მონაცემებს ბაზაში ინახავს |
| Valheim | worlds_local/ (.db და .fwl), adminlist.txt, bannedlist.txt, permittedlist.txt | გაშვების არგუმენტები, BepInEx plugin-ების ვერსიები |
| Source თამაშები | cfg/, maps/, addons/, სერვერის კონფიგურაციის ფაილი | Workshop კონტენტი, რომელიც თავიდან იტვირთება, თამაშის სერვერის token |
| Node ან Python აპლიკაცია | წყარო ან deploy commit, .env, ნებისმიერი uploads/ დირექტორია | node_modules, ბაზა, თავად რეპოზიტორია |
| WordPress | wp-content/, wp-config.php, .htaccess | ბაზა, რომელიც საიტის უმეტესი ნაწილია |
| Postgres ან Mongo | dump ფაილი | Role-ები და grant-ები, თუ ცალკე არ დაიდამპა |
სამი კატეგორია განმეორებით იკარგება.
- ბაზა. ის სხვა სერვისია სხვა backup მექანიზმით და მომუშავე ბაზის ფაილური დონის არქივი მისი backup არ არის. თუ შენი Minecraft-ის უფლებების plugin-ი, შენი FiveM რესურსები ან შენი ვებ აპლიკაცია მდგომარეობას ბაზაში ინახავს, არქივი ამ ბაზის გარეშე აღადგენს სერვერს, რომელიც ირთვება და არაფერი ახსოვს.
- ყველაფერი სერვერის დირექტორიის გარეთ. პანელის backup-ები არქივებს სერვერის საკუთარ ფაილებს. cron job VDS-ზე, რომელიც
/opt/tools-ში წერს, მეორე mount ან ლოგების დირექტორია, რომელიც ადგილის გამო გადაიტანე, იქ არ არის, თუ თავად არ ჩადე. - პარამეტრები, რომლებიც ფაილები არ არის. გაშვების ცვლადები, პორტების გამოყოფა, განრიგები, subuser-ების უფლებები და გეგმა, რომელზეც სერვერი მუშაობს, ყველა პანელის ბაზაში ცხოვრობს და არა დისკზე. აღდგენილი არქივი ბრუნდება სწორი სამყაროთი და არასწორი გაშვების ბრძანებით. შეინახე backup-ების გვერდით უბრალო ტექსტური ჩანაწერი გაშვების ხაზით, გამოყოფილი პორტებით და ყველაფრით, რაც ნაგულისხმევიდან შეცვალე. ორ წუთს ართმევს და ის არის განსხვავება ოცწუთიან აღდგენასა და ორსაათიანს შორის.
ვერსიის ინფორმაციაც ამ ჩანაწერს ეკუთვნის. Minecraft 1.21.4-ის world/ საქაღალდე, დაწყებული 1.20-ზე, არ ჩაიტვირთება, ხოლო modpack, აღდგენილი მოდების ზუსტი ვერსიების გარეშე, იმავე ავარიას გამოიწვევს, რომლის გაუქმებაც backup-ს უნდა ეკეთებინა - იხილე რა უნდა გააკეთო, როცა მოდის განახლება ყველაფერს ამსხვრევს.
სად ცხოვრობს ასლები#
წესი, რომელმაც შეინარჩუნა თავი საცავის ტექნოლოგიის ყოველი ცვლილების მიუხედავად, არის 3-2-1: მონაცემების სამი ასლი, ორი განსხვავებული ტიპის საცავზე ან სისტემაში, ერთი იმ ადგილას, სადაც პირველი ორი ერთად ვერ განადგურდება. ეს გამყიდველის სლოგანი არ არის; ეს აღიარებაა, რომ ჩავარდნები ჯგუფებად მოდის.
ერთ ჰოსტინგზე მყოფ სერვერზე გამოყენებული ეს კონკრეტულია:
- ცოცხალი მონაცემები, node-ზე, რომელშიც ახლა იწერება. ეს ასლია და არა backup.
- backup, აღებული მანქანის გარეთ, რომელსაც იცავს. არქივი იმავე საცავის pool-ზე, რომელზეც ის, რასაც იცავს, ფარავს ზუსტად ერთ ჩავარდნას: შენ საკუთარი სამყაროს წაშლას. ის არაფერს ფარავს დისკის, pool-ის, მანქანის ან ანგარიშის მხრივ.
- ასლი, რომელიც შენ გაქვს. ჩამოტვირთული შენს დისკზე, ან გაგზავნილი საცავში, რომელსაც შენს ჰოსტთან კავშირი არ აქვს. ეს ის ასლია, რომელიც გადარჩება შემთხვევას, როცა შენი ანგარიში გაქრება, და ის, რომელიც თითქმის არავის აქვს.
ბევრის გეგმის წყვეტილი ნაწილია ისარი არქივიდან სატესტო სერვერისკენ. არქივი, რომელსაც ამ ისრის გავლა არასოდეს უცდია, არის ფაილი სასარგებლო სახელით.
შენახვის ვადა: რამდენი, რამდენი ხნის და რომელი დაბლოკო#
შენახვის ვადა კითხვაა იმაზე, რომელ შეცდომას ელოდები. ბოლო დღის backup-ები იჭერს ავარიას ან ცუდ განახლებას. სამი კვირის წინანდელი backup-ები იჭერს იმას, რასაც არავინ შეამჩნია: plugin, რომელიც ჩუმად აფუჭებდა მოთამაშეების ინვენტარს, griefer op ჩანაწერით, ცხრილი, რომელმაც სამშაბათს ჩანაწერები დაკარგა.
კლასიკური სქემაა grandfather-father-son: შეინახე შვიდი ყოველდღიური backup, ოთხი ყოველკვირეული და რამდენიმე ყოველთვიური. ორი slot-იან თამაშის გეგმაზე ამის გაშვება არ შეგიძლია, ამიტომ გაუშვი პატიოსანი პატარა ვერსია:
- Slot 1 ტრიალებს. ღამის backup, რომელიც გუშინდელს გადაწერს. ეს შენი ავარიისგან დაცვაა.
- Slot 2 დაბლოკილია და შეიცავს ბოლო ცნობილ კარგ მდგომარეობას: backup-ს, რომელიც აიღე ბოლო განახლებამდე, ბოლო მოდის ცვლილებამდე ან ბოლო წარმატებული აღდგენის ტესტის შემდეგ. განაახლე ის განზრახ და არასოდეს განრიგით.
- შენი საკუთარი ასლი არის სიღრმე. ჩამოტვირთე მბრუნავი backup კვირაში ერთხელ და შეინახე ოთხი. შენს საკუთარ მანქანაზე საცავი slot-ზე გაცილებით იაფია და ოთხი კვირის ისტორია კვირაში ერთ drag-and-drop-ს გიჯდება.
RE:NODE-ზე თამაშის გეგმებს ორი backup slot აქვს, აპლიკაციების, ვებისა და ბაზის ხაზებს - ორიდან ექვსამდე დონის მიხედვით, ხოლო VDS ხაზს - ერთი. ყველა გეგმას აქვს slot-ები - აქ არაფერი ფასზეა დამოკიდებული. backup-ები იღება მოთხოვნით ან განრიგით, აღდგება ღილაკით და არა ბილეთით, ჩამოიტვირთება და შეიძლება დაიბლოკოს rotation-ისგან. სადაც მანქანის გარეთ ასლები ცხოვრობს, ჩვენ არ ვაქვეყნებთ, ზუსტად ამიტომ არის ზემოთ მე-3 პუნქტი შენი საქმე და არა ჩვენი.
თანმიმდევრულობა: განსხვავება ასლსა და snapshot-ს შორის#
თამაშის სერვერების უმეტესობა სამყაროს მეხსიერებაში ინახავს და პერიოდულად წერს. იმ ფაილების არქივირება ჩაწერის შუაში ორი მდგომარეობის ნარევს გაძლევს, და ჩავარდნის ფორმა უსიამოვნოა, რადგან არქივი კარგად გამოიყურება: სწორი ზომა, სწორი ფაილების სახელები და სამყარო, რომელიც არ იტვირთება ან ხვრელით იტვირთება.
სამი გამოსავალი, უპირატესობის მიხედვით:
- გააჩერე სერვერი, აიღე backup, ჩართე. სრულყოფილი თანმიმდევრულობა, რამდენიმე წუთის ოფლაინის ფასად. პატარა ჯგუფისთვის ეს სწორი პასუხია და 05:00-ზე ამას არავინ ამჩნევს.
- ჯერ flush გააკეთე. Minecraft-ს შეიძლება უთხრა, რომ ჩაწერა შეწყვიტოს და შემდეგ ყველაფერი დისკზე ჩაწეროს:
save-off, შემდეგsave-all flush, აიღე backup, შემდეგsave-on. Palworld-სა და Project Zomboid-ს აქვთSaveდაsaveკონსოლის ბრძანება, შესაბამისად. 7 Days to Die-ს აქვსsaveworld. - მიიღე რისკი ნამდვილად დამატებადი მონაცემებისთვის. ლოგები, ატვირთული მედია, სტატიკური ფაილები. არაფერი, რასაც პროცესი ღიად ინახავს და თავიდან წერს.
Valheim ცალკე ხაზს იმსახურებს, რადგან ის გავრცელებული მსხვერპლია: სუფთა გაჩერება სამყაროს ინახავს, kill - არა, და ნაგულისხმევი -saveinterval 1800 წამია. მომუშავე Valheim სერვერის backup-მა შეიძლება სამყარო დააარქივოს თამაშისგან ნახევარი საათით უკან. Valheim dedicated სერვერის გზამკვლევი ფარავს ამ ინტერვალის შემცირებას.
ამ ნაბიჯების თანმიმდევრობა ტაიმერზე არის თემა პოსტისა გეგმიური ამოცანები, რომლებიც ღირს - მოკლედ, flush ბრძანება backup ამოცანამდე რამდენიმე წუთით ადრე მიდის და არა იმავე წუთში, ხოლო ღამის გადატვირთვა არქივის შემდეგ და არა მის გვერდით, იმ მიზეზებით, რომლებიც აღწერილია პოსტში გადატვირთვის განრიგები, რომლებიც ეხმარება.
ხელით აღება#
ამას რაღაც მომენტში გააკეთებ: რისკიანი ცვლილების წინ, მიგრაციამდე, ან იმიტომ, რომ გინდა ასლი, რომელიც შენი ჰოსტის ხელში არ არის. SFTP-ით ან ფაილების მენეჯერით საქაღალდეების პირდაპირ ჩამოტვირთვა შეგიძლია, მაგრამ არქივის ჯერ სერვერზე შექმნა უფრო სწრაფია და გაძლევს რაღაცას, რასაც checksum-ს გამოუთვლი.
$ cd /home/container$ tar -czf /home/container/backup-$(date +%F).tar.gz \ world world_nether world_the_end plugins server.properties ops.json$ sha256sum backup-$(date +%F).tar.gz > backup-$(date +%F).sha256შემდეგ გადაამოწმე, სანამ ენდობი, და ისევ ჩამოტვირთვის შემდეგ:
$ gzip -t backup-2026-09-21.tar.gz && echo "archive intact"$ tar -tzf backup-2026-09-21.tar.gz | wc -l$ sha256sum -c backup-2026-09-21.sha256სამი რიცხვი ღირს ყოველ ჯერზე ჩაწერად: ფაილების რაოდენობა, ზომა ბაიტებში და რამდენ ხანს მოუნდა არქივის აგებას. backup, რომელიც უცებ გასულ კვირისაზე 90%-ით პატარაა, ყველაზე საიმედო ადრეული გაფრთხილებაა, რასაც მიიღებ, და ის ჩანს მხოლოდ თუ გასული კვირისას ოდესმე შეხედე. gzip -t იჭერს შეკვეცილ ჩამოტვირთვას, ეს მეორე გავრცელებული სიურპრიზია - 4 GB არქივი, რომელიც 3.1 GB-ზე გაჩერდა, რადგან ბრაუზერის ჩანართი დაიხურა.
გახსოვდეს, რომ არქივი შეიცავს შენს საიდუმლოებს. wp-config.php, .env, RCON პაროლები და ბაზის credential-ები ყველა მასთან ერთად მოგზაურობს. ჩამოტვირთულ backup-ს ისე მოეპყარი, როგორც თავად სერვერს, და წაიკითხე გარემოს ცვლადები და საიდუმლოებები, თუ რომელიმე მათგანი ახლა ფაილშია, რომელიც ვინმეს ელფოსტით გაუგზავნე.
აღდგენა, რომ უარესი არ გახდეს#
ინციდენტისას ინსტინქტია, მაშინვე ზემოდან აღადგინო. უარი თქვი სამოც წამზე, რადგან გატეხილი მდგომარეობა მტკიცებულებაა და ახლა განადგურდება.
- გააჩერე სერვერი. არა გადატვირთე - გააჩერე. მომუშავე პროცესი გადაწერს იმას, რასაც ადგილზე დებ.
- აიღე გატეხილი მდგომარეობის backup, ან სულ მცირე ჩამოტვირთე დაზიანებული საქაღალდე. თუ აღდგენა გაფიქრებულზე უფრო ძველი აღმოჩნდება, ეს ერთადერთი გზაა დღევანდელი შრომის მქონე ვერსიასთან დასაბრუნებლად.
- აღადგინე ადგილას, რომელიც production არ არის, თუ ეჭვი გეპარება, რომელი backup არის სწორი. მეორე სერვერზე აღდგენა პატარა გეგმის ერთ საათს ჯდება და გამორიცხავს გამოცნობას.
- აღადგინე ფაილები, შემდეგ ბაზა, ამ თანმიმდევრობით, და შეამოწმე, რომ აპლიკაციის მოსალოდნელი სქემის ვერსია აღდგენილ კოდს ემთხვევა. ფაილებზე უფრო ახალი ბაზა ყველაზე უსიამოვნო შემთხვევაა: იხილე migration-ები შეფერხების გარეშე.
- ხელახლა გამოიყენე პანელის მხარის პარამეტრები შენი ჩანაწერიდან - გაშვების ცვლადები, პორტები, განრიგები.
- გაუშვი და შეამოწმე რაიმე კონკრეტული. არა "ირთვება". შედი სისტემაში, გახსენი ის, რაც გაფუჭდა, შეამოწმე ბოლო ცვლილება, რომელიც გახსოვს backup-მდე.
ხუთი გზა, რომლითაც backup აღმოჩნდება, რომ backup არ ყოფილა#
- ის იმავე დისკზეა. თამაშის საკუთარი მბრუნავი save-ები, სამყაროს გვერდით
backups/საქაღალდე, ასლი/home/container/old-ში. ისინი ყველა გადარჩება ზუსტად იმ შეცდომებს, რომლებსაც ფაილების მენეჯერით აკეთებ, და არცერთს, რასაც აპარატურა. - მას ბაზა აკლია. ზემოთ აღვწერე და ის აპლიკაციებისა და ვებ დატვირთვებზე წარუმატებელ აღდგენებს ყველა სხვა მიზეზზე მეტს ჰყოფს.
- ის გაეშვა, მაგრამ არაფერზე. განრიგი, რომელიც სერვერს backup-ს უკეთებს, რომელსაც სახელი გადაარქვეს, ან dump ბრძანება, რომლის ბაზის სახელიც შეიცვალა, ყოველ ღამე პატარა არქივს გამოიმუშავებს. უყურე ზომას.
- ის არ იკითხება. შეკვეცილი ჩამოტვირთვები, არქივი, რომელიც სავსე დისკზე აიგო, დაზიანებული gzip ნაკადი. checksum შექმნისას და checksum გადატანის შემდეგ არაფერი ჯდება.
- პროცედურა არავინ იცის. არქივი სრულყოფილია და ადამიანი, ვინც ის დააყენა, ძინავს. ჩაწერე აღდგენის ნაბიჯები იმავე ჩანაწერში, სადაც გაშვების ცვლადები.
backup, რომელიც არავის აღუდგენია, ჰიპოთეზაა. დროდადრო აღადგინე ერთი სატესტო სერვერზე; ნახევარ საათს ართმევს და ერთადერთი გზაა, გაიგო.
განრიგის მორგება იმაზე, რისი დაკარგვაც შეგიძლია#
ორი რიცხვი აღწერს ნებისმიერ backup პოლიტიკას და მათი დასახელება კამათების უმეტესობას წყვეტს. recovery point objective არის, რამდენი სამუშაოს დაკარგვას ეთანხმები - ხარვეზი backup-ებს შორის. recovery time objective არის, რამდენ ხანს ეთანხმები გათიშულობას, სანამ ყველაფერს უკან აბრუნებ.
| დატვირთვა | გონივრული RPO | გონივრული RTO | რატომ |
|---|---|---|---|
| პატარა გადარჩენის სერვერი, მეგობრები | 24 საათი | 1 საათი | ერთი დღის მშენებლობა ნერვიულობაა და არა ფატალური |
| დატვირთული საზოგადოების გეიმ სერვერი | 6 საათი | 30 წუთი | მოთამაშეების პროგრესი და shop-ის შენაძენები |
| ვებ აპლიკაცია ან shop | 1 საათი ან ნაკლები | 30 წუთი | backup-ებს შორის ჩაწერილი შეკვეთები იკარგება |
| ბაზა აპლიკაციის უკან | წუთები, თუ გჭირდება | ზომის მიხედვით იცვლება | სჭირდება dump-ები პლუს write-ahead ლოგები და არა მხოლოდ dump-ები |
| განვითარების ან სატესტო სერვერი | ყოველკვირეული | როდესაც | იაფია რეპოზიტორიიდან თავიდან აგება |
რიგი, რომელიც ხალხს იჭერს, ბოლო რეალურია. თუ ბაზის ჩაწერების ერთი საათის დაკარგვა მიუღებელია, ღამის dump-ები ამას ვერ გააკეთებენ, შენახვის ვადის მიუხედავად, და გჭირდება უწყვეტი დაარქივება ინფრასტრუქტურაზე, რომელსაც აკონტროლებ - რაც ჩვეულებრივ ნიშნავს VDS-ს და არა slot-ს. ყველაფრისთვის დანარჩენისთვის ღამის backup პლუს დაბლოკილი ცნობილი კარგი ასლი პლუს ყოველკვირეული ჩამოტვირთვა სრული პოლიტიკაა და ის გაყიდულ ყველაზე პატარა გეგმაზეც შესაძლებელია.
FAQ#
რამდენად ხშირად უნდა ავიღო გეიმ სერვერის backup?
ღამით, ყველაზე მშვიდ საათზე, პლუს ერთი ხელით ნებისმიერი განახლების, მოდის ცვლილების ან კონფიგურაციის ექსპერიმენტის წინ. ხელით აღებულები განრიგზე მეტად მნიშვნელოვანია: აღდგენების უმეტესობა ხდება იმიტომ, რომ ვიღაცამ რაღაც შეცვალა და არა იმიტომ, რომ რამე ჩავარდა.
შეიცავს backup ჩემს ბაზას?
არა, თუ ბაზის dump-ს სერვერის საქაღალდეში backup-მდე არ ჩადებ. პანელის backup-ები სერვერის ფაილებს არქივირებს. ბაზა - პანელის ბაზის slot ან ცალკე PostgreSQL ან MongoDB სერვერი - სხვა სერვისია და საკუთარი dump სჭირდება, ამიტომ მოცემულ პოსტში განრიგის თანმიმდევრობა dump-ს პირველად სვამს.
დაბლოკილი backup სამუდამოდ უსაფრთხოა?
ის უსაფრთხოა rotation-ისგან და არა წაშლისგან. დაბლოკვა ხელს უშლის დაგეგმილ backup-ს, შენი ცნობილი კარგი ასლი slot-ებიდან გამოაძევოს. ის არ გადარჩება სერვერის წაშლას და არ ცვლის შენს საკუთარ ჩამოტვირთულ ასლს.
რამდენ ხანს გრძელდება აღდგენა?
იმდენ ხანს, რომ გაზომვა გმართებს და არა დაშვება. 500 MB გეიმ სერვერის აღდგენა პანელის backup-იდან რამდენიმე წუთია; 40 GB მოდიანი სერვერი ბაზით ერთი საღამოა. ერთადერთი პატიოსანი პასუხია რიცხვი, რომელიც ბოლო ცდაზე მიიღე, სწორედ ამიტომ უნდა სცადო.
შემიძლია backup სხვა სერვერზე აღვადგინო?
დიახ, და ეს მისი შემოწმების ყველაზე უსაფრთხო გზაა. ჩამოტვირთე არქივი, ატვირთე მეორე სერვერზე იმავე ან უფრო დიდ გეგმაზე და იქ გაუშვი. ასევე ასე გადადიხარ გეგმებს ან ჰოსტებს შორის - სერვერის გადატანა მოთამაშეების დაკარგვის გარეშე ფარავს DNS-სა და მოთამაშეებისკენ მიმართულ მხარეს.
რაც შეეხება მთელი პლატფორმის backup-ს და არა მხოლოდ ჩემი სერვერისას?
ეს ჰოსტის საქმეა და შენსგან განსხვავებულია. ჩვენებია ღამის, ცალკე აპარატურაზე გადაწერილი, გადამოწმებული და განრიგით გასუფთავებული. ის პლატფორმას იცავს და არა შენს გადაწყვეტილებებს - სამყარო, რომელიც გუშინ წაშალე, მისგან არ აღდგება, რისთვისაც შენი საკუთარი backup slot-ებია.




კომენტარები
სრულიად ანონიმურად: ანგარიშის, ელფოსტის და cookie-ის გარეშე. ინახება მხოლოდ სახელი, ტექსტი და დრო - სხვა არაფერი. ბმულების რაოდენობა ლიმიტირებულია.