თამაშის სერვერის backup-ის სტრატეგია თამაშების მიხედვით

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

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

მონაცემების სამი სახეობა ყველა თამაშის სერვერზე#

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

1. მდგომარეობა - სამყარო, მოთამაშეების პროგრესი, ბაზები, ეკონომიკის ბალანსები, უფლებების მონაცემთა ბაზა. ეს იცვლება ყოველ წუთს, სანამ სერვერი მუშაობს, ვერსად ვერ ჩამოტვირთავ თავიდან და ერთადერთია, რისი დაკარგვაც სამუდამოა. ყველა backup უნდა შეიცავდეს მას.
2. კონფიგურაცია - server.properties, serverDZ.cfg, PalWorldSettings.ini, plugin-ების კონფიგები, ადმინების სიები, ბანების სიები. პატარაა, იშვიათად იცვლება და მისი თავიდან შექმნა მტკივნეულია, რადგან ორმოც მნიშვნელობას, რომელიც ოდესღაც მოარგე, არავინ იმახსოვრებს. შეინახე მდგომარეობასთან ერთად - არაფერი ღირს.
3. აღდგენადი ფაილები - თამაშის ბინარები, Steam runtime, Workshop-ის ჩამოტვირთვები, Java runtime. გიგაბაიტებია, და მისი თითოეული ბაიტი შეიძლება თავიდან მოიპოვო SteamCMD-ით ან პანელის reinstall-ით. მათი გამორიცხვა backup-ებს პატარას და სწრაფს ტოვებს.

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

რისი backup გააკეთო, თამაში თამაშზე#

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

ზოგიერთს ახსნა სჭირდება.

Minecraft Paper-სა და Spigot-ზე სამ განზომილებას სამ საქაღალდეში ინახავს. Vanilla Nether-სა და End-ს მთავარ world საქაღალდეში ინახავს, როგორც DIM-1 და DIM1, ამიტომ vanilla-სთვის დაწერილი სკრიპტი Paper-ის სამყაროს ორ მესამედს გამოტოვებს. plugin-ების მონაცემები plugins/<Plugin>/-შია და ნაწილი მათგანი მდგომარეობაა - claim-ები, ეკონომიკის ბალანსები, LuckPerms-ის ჯგუფები, როცა ნაგულისხმევ H2 ფაილში ინახება. Minecraft-ის სამყაროს backup და აღდგენა დეტალურად განიხილავს შენახვის ბრძანებებს და region-ის დონეზე უკან დაბრუნებას.

Project Zomboid ის თამაშია, რომელშიც ყველაზე ხშირად ცდებიან. რუკა Saves/Multiplayer/<servername>-შია, მაგრამ მოთამაშეების ანგარიშები და პაროლები db/<servername>.db-შია. აღადგინე მხოლოდ რუკა და ყველა მოთამაშეს თავიდან რეგისტრაცია მოუწევს; აღადგინე მხოლოდ მონაცემთა ბაზა და ისინი შევლენ სამყაროში, რომელმაც მათ შესახებ არაფერი იცის.

7 Days to Die save-ებს მომხმარებლის მონაცემების საქაღალდეში ინახავს, რომელიც Linux-ზე ნაგულისხმევად არის ~/.local/share/7DaysToDie/Saves/, თუ serverconfig.xml-ში UserDataFolder ან SaveGameFolder სხვაგან არ მიუთითებს. შემთხვევით გენერირებულ სამყაროს ასევე აქვს გენერირებული რუკა GeneratedWorlds/-ში - კონფიგის მასშტაბით პატარაა, მაგრამ მის გენერაციას ათი წუთი ან მეტი დასჭირდა, და save მის გარეშე უსარგებლოა.

DayZ თავის მდგომარეობას მისიის საქაღალდეში წერს. storage_1 ინახავს სამყაროს ობიექტებს, მოთამაშეებს და მანქანებს; რიცხვი არის instance id, რომელიც serverDZ.cfg-შია დაყენებული. მის გვერდით მდებარე ეკონომიკის ფაილები (types.xml, events.xml) კონფიგურაციაა და ზუსტად ისინი არის, რასაც არედაქტირებ, ამიტომ ისინი იმაზე ხშირად იცვლება, ვიდრე ფიქრობ.

Counter-Strike 2-სა და სხვა მატჩებზე დაფუძნებულ შუტერებს კონფიგურაციის გარდა დასაკარგი არაფერი აქვთ. მათი "backup" არის cfg/-ისა და plugin-ების საქაღალდეების ასლი, იდეალურად git-ის რეპოზიტორიაში, უცვლელი საქაღალდის ყოველდღიური snapshot კი უბრალოდ დისკის ხარჯვაა.

თანმიმდევრული ასლის მიღება: ჯერ შენახვა, მერე კოპირება#

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

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

Task 1  command  say Backup in 1 minute - expect a short pauseTask 2  command  save-off              (delay 60 s)Task 3  command  save-all flush        (delay 5 s)Task 4  backup                         (delay 45 s)Task 5  command  save-on               (delay 120 s)

თამაშისთვის, რომელსაც შენახვის ბრძანება არ აქვს, უსაფრთხო ვარიანტებია გაჩერება, backup და გაშვება, ან იმის მიღება, რომ ასლი ბოლო autosave-იდანაა. DayZ მეორე ჯგუფში ხვდება: storage_1-ის ასლი, აღებული დაგეგმილი ჩაწერიდან რამდენიმე წუთში, პრაქტიკაში ნორმალურია. backup-ის წინ სერვერის გაჩერება არასოდესაა შეცდომა - უბრალოდ მოუხერხებელია, რის გამოც ის ჩვეულებრივ ღამის restart-ის ფანჯარაში ხვდება.

რამდენი backup შეინახო და რამდენ ხანს#

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

მუდმივი სამყაროები

გადარჩენისა და sandbox სერვერები - Minecraft SMP, Valheim, Palworld, Project Zomboid, 7 Days to Die wipe-ების გარეშე, Factorio, Satisfactory - ყოველდღე აგროვებენ ღირებულებას და არასოდეს ნულდება. გონივრული როტაციაა:

• ყოველდღიური backup-ები, შენახული შვიდი დღე. ეს ფარავს griefing-ს, რომელიც რამდენიმე დღის დაგვიანებით შენიშნეს, და დაზიანებულ chunk-ს, რომელიც შეუმჩნეველი რჩებოდა, სანამ ვინმე მასში არ შევიდა.
• ყოველკვირეული backup-ები, შენახული ოთხი კვირა. პანელის backup-ის სლოტები იშვიათად წვდება ამდენს, და სწორედ ამისთვისაა ჩამოტვირთვა (შემდეგი სექცია).
• ჩაკეტილი backup-ები ყოველი თამაშის განახლების, ყოველი mod-ის ცვლილების და სამყაროს ყოველი რედაქტირების წინ, შენახული მანამ, სანამ არ დარწმუნდები, რომ ცვლილება წარმატებული იყო - ჩვეულებრივ ერთი კვირა.

wipe-ციკლის სერვერები

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

მატჩის სერვერები

Counter-Strike 2, Team Fortress 2, Insurgency: Sandstorm და მსგავსი. კონფიგურაცია ვერსიების კონტროლში შეინახე და plugin-ების მონაცემთა ბაზების backup გააკეთე (SourceMod-ის sourcemod-local.sq3, თუ ადმინებისთვის ან სტატისტიკისთვის SQLite-ს იყენებ). ყოველდღიური სრული backup დაკარგული სლოტებია.

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

გარე ასლი და რატომ არ კმარა პანელი#

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

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

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

# Weekly pull of a Valheim world over SFTP, run from your own machine$ sftp -P 2022 user.abc123@panel.example:/worlds_local/Midgard.* \    ~/backups/valheim/$(date +%F)/

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

ზომა, სიხშირე და რა ღირს#

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

აქედან ორი რამ გამომდინარეობს. პატარა სამყაროების (Valheim, Terraria, Factorio) backup შეიძლება ყოველ საათში გაკეთდეს ისე, რომ ვერავინ შეამჩნიოს. დიდების (Minecraft-ის სამყარო წინასწარ გენერირებული 10,000-ბლოკიანი საზღვრით, დატვირთული Zomboid-ის რუკა) დაარქივებას იმდენი დრო სჭირდება, რომ ყოველსაათიანი backup დისკისთვისაც და თამაშისთვისაც უხეშია, და სწორი რიტმი ყოველდღიურია, მშვიდ საათში. საჭიროს გარდა ყველაფრის გამორიცხვას აქ ყველაზე დიდი მნიშვნელობა აქვს: Minecraft-ის backup, რომელიც Dynmap-ის ან BlueMap-ის tile cache-ს შეიცავს, შეიძლება ხუთჯერ დიდი იყოს იმ სამყაროზე, რომლის რუკასაც ხატავს. რამდენი საცავი სჭირდება თამაშის სერვერს ამის დისკის ზომის მხარეს განიხილავს, მათ შორის იმ მარაგს, რომელიც backup-ებს მათი შექმნისას სჭირდებათ.

Pterodactyl-ზე დაფუძნებულ პანელზე საქაღალდეების გამორიცხვა ხდება ignore ფაილით, სახელად .pteroignore, სერვერის root-ში, რომელიც .gitignore-ის მსგავსად იწერება (ეს upstream Pterodactyl-ის ფუნქციაა, ამიტომ ჰკითხე შენს ჰოსტს, თუ არ ხარ დარწმუნებული, რომ მას ითვალისწინებენ):

# rebuilt on demand, no need to back them upplugins/dynmap/web/tiles/bluemap/web/maps/logs/crash-reports/cache/*.log.gz

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

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

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

1. გააჩერე სერვერი. გაშვებულ სამყაროზე აღდგენა შემდეგი autosave-ისას გადაიწერება.
2. გააკეთე გაფუჭებული მდგომარეობის backup და ჩაკეტე. შეიძლება მოგვიანებით რამე დაგჭირდეს მისგან - ბოლო კარგი backup-ის შემდეგ აშენებული ნაგებობა ან იმის მტკიცებულება, ვინ მიაყენა ზიანი.
3. აღადგინე მთელი backup ან ამოიღე მხოლოდ სამყაროს საქაღალდე, თუ მას შემდეგ კონფიგურაცია შეცვალე და მისი შენარჩუნება გინდა. RE:NODE-ზე პანელი backup-ს ერთი ღილაკით აღადგენს; ნაწილობრივი აღდგენისთვის ჩამოტვირთე არქივი და საჭირო საქაღალდე ატვირთე ფაილების მენეჯერით, რომელიც არქივებს ადგილზევე ხსნის.
4. შეამოწმე, რომ ვერსიები ემთხვევა. თამაშის განახლებამდელი სამყარო ახალ ვერსიაში თითქმის ყოველთვის იტვირთება; განახლების შემდგომი სამყარო ძველში იშვიათად. თუ თავად თამაშს აბრუნებ უკან, ნახე ვერსიის ფიქსაცია და უკან დაბრუნება.
5. გაუშვი და წაიკითხე ლოგი, მოძებნე ხაზი, რომელიც ამბობს, რომელი სამყარო ჩაიტვირთა. სერვერი, რომელიც სამყაროს ვერ პოულობს, ჩვეულებრივ იმავე სახელით ახალს აგენერირებს და სრულიად ჯანმრთელად გამოიყურება.
6. უთხარი მოთამაშეებს, რომელ დრომდე აღდგა სამყარო, რომ იცოდნენ, რა დაკარგეს.

შემდეგ, რომელიმე მშვიდ მომენტში, გაიმეორე ეს საცდელად. აღდგენის ტესტირება მანამ, სანამ დაგჭირდება ოცდაათწუთიანი ვარჯიშია, და სწორედ ასე აღმოაჩენ, რომ backup-ში db საქაღალდე არასოდეს ყოფილა.

გავრცელებული ხარვეზები, თამაში თამაშზე#

backup-ები, რომლებიც საჭირო დღეს მარცხდება, ჩვეულებრივ ერთ-ერთი ამ მიზეზით მარცხდება:

• სამყარო სხვაგან იყო. გაშვებისას save-ის საქაღალდის ფლაგმა (-savedir Valheim-ზე, UserDataFolder 7 Days to Die-ზე, -cachedir Project Zomboid-ზე) სამყარო იმ საქაღალდიდან გაიტანა, რომლის backup-იც კეთდებოდა.
• მონაცემთა ბაზა ფაილი არ იყო. plugin-ებსა და framework-ებს, რომლებიც მდგომარეობას მონაცემთა ბაზაში ინახავს - FiveM-ის framework-ები oxmysql-ით, გარე ბაზაზე მორგებული Minecraft-ის plugin-ები - ამ ბაზის dump-იც სჭირდება. პანელზე მონაცემთა ბაზის სლოტი ფაილების backup-ისგან ცალკეა; მონაცემთა ბაზის backup-ები და აღდგენა აღწერს, როგორ აიღო dump.
• სერვერის სახელი შეიცვალა. Zomboid და Don't Starve Together თავიანთ საქაღალდეებს სახელზე აბამენ. გადაარქვი სერვერს სახელი და ის ახალ, ცარიელ საქაღალდეში დაიწყებს წერას, backup-ის განრიგი კი ძველის დაარქივებას გააგრძელებს.
• backup შენახვის დროს გაეშვა. განრიგში შენახვის ბრძანება არ იყო, ან დაყოვნება დიდი სამყაროსთვის ზედმეტად მოკლე იყო.
• Workshop-ის კონტენტი განახლდა. სამყარო მიუთითებს mod-ის ვერსიაზე, რომელიც Workshop-ზე აღარ არსებობს. ყველაფრისთვის, რისი დაკარგვაც არ შეგიძლია, mod-ის ფაილების ასლი save-თან ერთად შეინახე.
• ჩაშენებული backup-ები ნამდვილად ჩათვალეს. Valheim-ის -backups, Minecraft-ის backup plugin-ები და 7 Days to Die-ის საკუთარი backup საქაღალდე იმავე დისკზეა, სადაც სამყარო. ისინი დაზიანებული save-ისგან იცავს და არა წაშლილი სერვერისგან.

FAQ#

რამდენად ხშირად უნდა გავაკეთო თამაშის სერვერის backup?

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

უნდა გავაჩერო სერვერი backup-ისთვის?

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

ღირს თავად თამაშის ფაილების backup?

ჩვეულებრივ არა. ისინი reinstall-ით ან SteamCMD-ის განახლებით ბრუნდება. გამონაკლისია, როცა ზუსტ ვერსიაზე ხარ დამოკიდებული - mod-ებიანი სერვერი, რომელიც ძველ build-ზეა მიბმული - ამ შემთხვევაში შეინახე სამუშაო ინსტალაციის ერთი ასლი, ყოველდღიური სამყაროს backup-ებისგან ცალკე.

რა განსხვავებაა პანელის backup-სა და ჩამოტვირთვას შორის?

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

რატომ გამოიყურება ჩემი აღდგენილი სამყარო სრულიად ახალივით?

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