სერვერის backup-ები შენს PC-ზე: Windows backup აგენტი

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

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

რატომ არის მნიშვნელოვანი ასლი შენს მანქანაზე#

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

რასაც პროვაიდერის მხარეს backup ვერ ფარავს, თვითონ პროვაიდერის მხარეა. მარტივი შემთხვევები:

• სერვერი წაიშალა. RE:NODE-ზე სერვერის წაშლა მის backup-ებსაც შლის, ჩაკეტილებსაც. კონფიდენციალობისთვის სწორი ქცევაა და ნიშნავს, რომ შემთხვევით წაშლა, ან ზედმეტი წვდომის მქონე subuser, ყველა ასლს ერთბაშად იღებს.
• სერვისი ვადას გადის. ბარათს ვადა გაუვიდა, განახლების წერილი spam-ში მოხვდა და სერვერი, რომელსაც აღარ აკვირდებოდი, საშეღავათო პერიოდს გასცდა. ფაილებს რაც არ უნდა დაემართოს, შენ მათ აღარ გადმოწერ.
• ანგარიში გატეხილია. ვისაც შენი panel-ის პაროლი აქვს და 2FA არ გაქვს ჩართული, backup-ებს ყველაფერზე ადრე შეუძლია წაშალოს. შენს PC-ზე არსებულ ასლამდე მას ვერ მიაღწევს.
• წასვლა გინდა. სხვა ჰოსტზე ან სახლის მანქანაზე გადასვლა იმით იწყება, რომ მონაცემები გაქვს. შენს დისკზე არქივების საქაღალდე ყველაზე მარტივი მიგრაციაა, რაც კი გიკეთებია.

ეს ძველი 3-2-1 წესია, რიცხვებით შევსებული: სამი ასლი (ცოცხალი სერვერი, panel-ის backup, შენი PC), შენახვის ორ სახეობაზე, რომელთაგან ერთი დანარჩენი ორისგან მოშორებითაა. შენი PC არის ის "მოშორებული" ასლი. იდეალური არაა - სახლის დისკები ფუჭდება, ლეპტოპები იპარება - მაგრამ ის სრულიად სხვა მიზეზებით ფუჭდება, ვიდრე ჰოსტინგის მხარე, და ზუსტად ეს არის აზრი. უფრო ფართო სტრატეგიისთვის game server backup strategy მოიცავს slot-ებს, სიხშირეს და იმას, რა უნდა ჩაიკეტოს.

რას აკეთებს RE:NODE უკვე და რას გიტოვებს შენ#

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

• შენი backup-ები. ყველა გეგმას აქვს backup slot-ები - უმეტეს თამაშის გეგმაზე ორი, app, web და database გეგმებზე კი დიაპაზონი. მათ ქმნი მოთხოვნით ან გრაფიკით, აღადგენ ღილაკით, ჩამოტვირთავ და ჩაკეტავ იმათ, რომლებიც გინდა შეინახო. ისინი იმ მანქანის გარეთ ინახება, რომელსაც იცავენ. სწორედ ამათ გადმოწერს ეს პოსტი.
• ღამის სისტემური backup-ები. ყველა სერვერს ყოველ ღამე ასევე უკეთდება backup, გეგმის slot-ების რაოდენობის მიუხედავად, შენი კვოტის გარეთ. ისინი ჩვენია: შენს Backups ჩანართზე არ ჩანს და ვერ ჩამოტვირთავ. თუ რომელიმეს აღდგენა გჭირდება, ეს support-ის გავლით ხდება. Nightly backups outside your quota განმარტავს, როგორ მუშაობს.
• პლატფორმის backup-ები. ცალკე, თვითონ პლატფორმას ყოველ ღამე ვუკეთებთ backup-ს ცალკე hardware-ზე, ვამოწმებთ და ვასუფთავებთ, და node-დან ასლებს ყოველდღე ვიღებთ.

ამ სამიდან არც ერთი არ არის ასლი, რომელიც შენ გიჭირავს. ღამის სისტემური backup არის უსაფრთხოების ბადე, რომელსაც ინციდენტებისთვის ვინახავთ; ის შენი საკუთარის შემცვლელი არ არის და ღამის სამ საათზე, როცა გჭირდება, მასთან ვერ მიხვალ. შენს PC-ზე არსებული ასლი ერთადერთია, რომელიც შენ გარდა არავის ჰყავს დამოკიდებული.

რას შეიცავს backup არქივი#

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

სერვერის backup არის სერვერის ფაილების .tar.gz. database, რომელიც panel-ის Databases ჩანართში შექმენი, ცხოვრობს database სერვერზე და არა სერვერის ფაილურ სისტემაში, ამიტომ არქივში არ არის. თუ შენი Minecraft plugin-ები, FiveM resource-ები ან Discord bot მონაცემებს ამ database-ში ინახავს, მხოლოდ ფაილების backup-ი აღადგენს სერვერს, რომელიც თავის მონაცემებს ვერ პოულობს. გააკეთე database-ის dump ცალკე - mysqldump backup and restore შეიცავს ბრძანებებს - და dump-ი backup-ის გაშვებამდე ჩააგდე სერვერის ფაილებში, რომ არქივს გაჰყვეს.

მეორე ხარვეზი .pteroignore-ია. ეს სერვერის root-ში მდებარე ფაილია და .gitignore-ს ჰგავს: რასაც ჩამოთვლის, backup-ის შექმნისას გამოტოვება. სასარგებლოა log-ებისა და cache-ის გამოსატოვებლად და სახიფათოა, როცა ვიღაცამ თვეების წინ ადგილის დასაზოგად მასში world/ ჩაამატა. ნებისმიერ არქივს სანამ ენდობი, ეს ფაილი გახსენი.

Startup ცვლადები - ვერსია, jar-ი, Startup ჩანართზე არსებული გარემოს მნიშვნელობები - ასევე ფაილები არ არის. ჩაიწერე ერთხელ. გათიშვის დროს მათი ხსოვნიდან აღდგენა ნელია.

ხელით: ჩამოტვირთვა Backups ჩანართიდან#

თუ ასლი მხოლოდ დროდადრო გჭირდება, არაფრის დაყენება არ გესაჭიროება.

1. გახსენი სერვერი panel-ში და გადადი Backups ჩანართზე.
2. თუ უახლესი backup ძველია, დააჭირე ღილაკს ახლის შესაქმნელად და დაელოდე, სანამ დასრულებულად გამოჩნდება.
3. გახსენი ამ backup-ის მენიუ და აირჩიე Download. ბრაუზერი .tar.gz-ს მოკლევადიანი ხელმოწერილი ბმულით გადმოწერს.
4. გადაიტანე ფაილი ისეთ ადგილას, რომელიც შენი Downloads საქაღალდე არ არის, და გადაარქვი სახელი თარიღითა და სერვერის სახელით.

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

ავტომატიზაცია PowerShell-ით და client API-ით#

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

გჭირდება სამი რამ:

• API გასაღები. შექმენი panel-ში შენი ანგარიშის API credentials განყოფილებაში. ის იწყება ptlc_-ით. გასაღების კონკრეტულ მისამართებზე შეზღუდვა შეგიძლია; თუ სახლის კავშირს სტატიკური IP აქვს, გააკეთე ეს. თუ IP იცვლება, შეზღუდული გასაღები შეწყვეტს მუშაობას, რაც ღია გასაღებზე უსაფრთხოა, მაგრამ უნდა იცოდე.
• სერვერის მოკლე ID. ეს არის panel-ში სერვერის URL-ის რვასიმბოლოიანი ნაწილი, მაგალითად a1b2c3d4 ბმულში /server/a1b2c3d4.
• საქაღალდე საკმარისი ადგილით. არქივის ზომა გაამრავლე შესანახი ასლების რაოდენობაზე და დაამატე მარაგი.

გასაღები შეინახე როგორც მომხმარებლის გარემოს ცვლადი და არა სკრიპტში, რომ სკრიპტის გაზიარება ან commit-ი გასაღებს არ გაჟონავს:

setx RENODE_API_KEY "ptlc_your_key_here"

setx ცვლადს მომავალი სესიებისთვის წერს, ამიტომ ამის შემდეგ გახსენი ახალი PowerShell ფანჯარა. დაგეგმილი დავალება, რომელსაც მოგვიანებით შევქმნით, შენი მომხმარებლით გაეშვება და ცვლადს დაინახავს.

ახლა სკრიპტი. შეინახე როგორც C:\ServerBackups\pull.ps1:

$Panel  = 'https://panel.renode.space'$Server = 'a1b2c3d4'$Dest   = "C:\ServerBackups\$Server"$Keep   = 14$Key    = $env:RENODE_API_KEY[Net.ServicePointManager]::SecurityProtocol = 'Tls12'$ProgressPreference = 'SilentlyContinue'$Headers = @{ Authorization = "Bearer $Key"; Accept = 'application/json' }$Base = "$Panel/api/client/servers/$Server/backups"New-Item -ItemType Directory -Force -Path $Dest | Out-Null$Log = Join-Path $Dest 'pull.log'$list = Invoke-RestMethod -Headers $Headers -Uri $Baseforeach ($b in $list.data) {  $a = $b.attributes  if (-not $a.is_successful -or -not $a.completed_at) { continue }  $stamp = ([datetime]$a.completed_at).ToString('yyyy-MM-dd_HHmm')  $file  = Join-Path $Dest ("$stamp-" + $a.uuid.Substring(0,8) + '.tar.gz')  if (Test-Path $file) { continue }  $link = Invoke-RestMethod -Headers $Headers -Uri "$Base/$($a.uuid)/download"  Invoke-WebRequest -Uri $link.attributes.url -OutFile "$file.part" -UseBasicParsing  tar -tzf "$file.part" > $null 2>&1  if ($LASTEXITCODE -ne 0) {    Add-Content $Log "$(Get-Date -f s) BAD archive $stamp, kept as .part"    continue  }  Move-Item "$file.part" $file  Add-Content $Log "$(Get-Date -f s) pulled $stamp $($a.name)"}Get-ChildItem $Dest -Filter *.tar.gz |  Sort-Object LastWriteTime -Descending |  Select-Object -Skip $Keep |  Remove-Item

ის დაწერილია Windows PowerShell 5.1-ისთვის, ვერსიისთვის, რომელიც ყველა Windows 10 და 11 მანქანაზე უკვე არის, ამიტომ არაფრის დაყენება არ გჭირდება. ბლოკი მხოლოდ ჩვეულებრივ ტექსტად არის მონიშნული იმის გამო, როგორ ღებავს ბლოგი კოდს; თვითონ ფაილი ჩვეულებრივი .ps1-ია.

რას აკეთებს თითოეული ნაწილი

პირველი ბლოკი კონფიგურაციაა. $Keep არის, რამდენ არქივს ინახავ PC-ზე; თოთხმეტი ყოველდღიური panel backup-ის შემთხვევაში ორი კვირაა. SecurityProtocol-ის ხაზი აიძულებს TLS 1.2-ს, რომელსაც 5.1-ის ძველი ინსტალაციები ყოველთვის თავისით არ ირჩევს. $ProgressPreference უფრო მნიშვნელოვანია, ვიდრე ჩანს: Windows PowerShell 5.1-ში Invoke-WebRequest ყოველი ნაწილისთვის თავიდან ხატავს progress bar-ს, და რამდენიმე გიგაბაიტიან არქივზე მხოლოდ ეს ჩამოტვირთვას რამდენჯერმე ანელებს.

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

ახალი backup-ისთვის ის ჩამოტვირთვის ბმულს ითხოვს, რომელიც მოდის როგორც ხელმოწერილი URL და მალე იწურება, და ჩამოტვირთავს .part ფაილში. მხოლოდ მას შემდეგ, რაც tar -tzf მთელ არქივს შეცდომის გარეშე წაიკითხავს, ის .tar.gz-ად გადაერქმევა. სწორედ ეს ერთი ნაბიჯია განსხვავება backup-ების საქაღალდესა და ფაილების საქაღალდეს შორის, რომლებიც backup-ებს ჰგავს. tar Windows 10-თან და 11-თან ერთად მოდის, ამიტომ ესეც არაფერს ითხოვს დამატებით.

ბოლო pipeline არის retention: დაალაგე არქივები უახლესიდან, გამოტოვე ის რაოდენობა, რაც გინდა შეინახო, დანარჩენი წაშალე. ის მხოლოდ ამ სერვერის საქაღალდის .tar.gz ფაილებს ეხება, ამიტომ დაზიანებული .part ადგილზე რჩება სანახავად და შენს დისკზე სხვა არაფერი ხვდება მის სფეროში.

ერთზე მეტი სერვერი

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

ჩამოტვირთვის დაგეგმვა Task Scheduler-ით#

სკრიპტი, რომლის გაშვებაც უნდა გახსოვდეს, ხელით გზაა დამატებითი ნაბიჯებით. Windows Task Scheduler მას შენ მაგივრად გაუშვებს. გახსენი PowerShell შენი ჩვეულებრივი მომხმარებლით და დაარეგისტრირე დავალება:

$action = New-ScheduledTaskAction -Execute 'powershell.exe' `  -Argument '-NoProfile -ExecutionPolicy Bypass -File C:\ServerBackups\pull.ps1'$daily  = New-ScheduledTaskTrigger -Daily -At 9am$logon  = New-ScheduledTaskTrigger -AtLogOn -User $env:USERNAME$opts   = New-ScheduledTaskSettingsSet -StartWhenAvailable `  -ExecutionTimeLimit (New-TimeSpan -Hours 3)Register-ScheduledTask -TaskName 'Server backup pull' `  -Action $action -Trigger $daily,$logon -Settings $opts

ორი trigger განზრახ არის. სახლის PC ხშირად გამორთულია იმ დროს, რომელსაც აირჩევ, ამიტომ მარტო ყოველდღიური trigger დღეებს აცდენს. logon trigger მას ყოველ შესვლაზე უშვებს, და -StartWhenAvailable Windows-ს ეუბნება, გამოტოვებული ყოველდღიური გაშვება მანქანის დაბრუნებისთანავე შეასრულოს. რადგან სკრიპტი მხოლოდ იმას ჩამოტვირთავს, რაც აკლია, ერთ დილას ორჯერ გაშვება ერთ API გამოძახებად ჯდება.

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

დააკავშირე panel-ის backup გრაფიკთან

ჩამოტვირთვას მხოლოდ იმის გადმოწერა შეუძლია, რაც არსებობს. panel-ის მხარეს გახსენი სერვერის Schedules ჩანართი და დაამატე გრაფიკი backup დავალებით, სასურველი დროისთვის cron გამოსახულებით. თუ panel-ის backup 05:00-ზე მუშაობს, შენი PC კი 09:00-ზე და logon-ზე იღებს, ყოველი დილის ასლი იმავე დღეს აღწევს შენს დისკს. Cron expressions explained ხუთ ველს განმარტავს, თუ ადრე არ გიწერია, და scheduled tasks worth having გვთავაზობს, კიდევ რა ეკუთვნის ამ ჩანართს.

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

ვამოწმებთ, რომ ასლები გამოსადეგია#

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

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

tar -tzf C:\ServerBackups\a1b2c3d4\2026-10-16_0500-3f9a1c2e.tar.gz | more

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

მესამე ფენა რეალური აღდგენაა და ის ერთადერთია, რაც რამეს ამტკიცებს. გახსენი არქივი ცარიელ საქაღალდეში და სერვერი მისგან გაუშვი - შენს PC-ზე, თუ თამაში იქ მუშაობს, ან სათადარიგო სერვერზე. Testing a restore before you need it გიჩვენებს, როგორ გააკეთო ეს production-ის შეხების გარეშე, და backups that actually restore მოიცავს ჩავარდნის სახეებს, რომლებიც მხოლოდ ამ ნაბიჯზე ჩანს.

ლოკალური ასლის დაცვა#

შენს PC-ზე არსებული ასლი მხოლოდ მაშინ არის "მოშორებული", თუ ის იმისგან განცალკევებულია, რამაც სერვერს შეიძლება ავნოს.

• პირდაპირ ღრუბელში უკან ნუ დაასინქრონებ. backup საქაღალდე OneDrive-ში ან Dropbox-ში მესამე ასლად კარგია, მაგრამ sync კლიენტები წაშლებს ირეკლავენ. თუ ransomware ან ცუდი სკრიპტი საქაღალდეს დაცარიელებს, ცარიელი საქაღალდე დასინქრონდება. გამოიყენე ვერსიების ისტორია, ან sync ასლი ჩამოტვირთვის საქაღალდისგან განცალკევებით შეინახე.
• შეინახე ყოველკვირეული ოფლაინ ასლი. გარე დისკი, რომელსაც რთავ, აკოპირებ და გამოართავ, ერთადერთი ასლია, რომელსაც შენს PC-ზე არსებული ransomware ვერ წვდება. robocopy C:\ServerBackups E:\ServerBackups /E ამას ერთ ხაზში აკეთებს.
• დაიცავი გასაღები. API გასაღებს შეუძლია ყველაფერი, რაც შენს ანგარიშს შეუძლია იმ სერვერებზე, რომლებზეც წვდომა აქვს. შეზღუდე მისამართით, თუ შეგიძლია, ინახე გარემოს ცვლადში და არა სკრიპტში, და თუ PC დაიკარგა, panel-ში გააუქმე.
• უთვალთვალე დისკს. თამაშის არქივები სამყაროსთან ერთად იზრდება. პირველი ორი კვირის შემდეგ ნახე საქაღალდის ზომა და $Keep დისკის გავსებამდე შეასწორე და არა შემდეგ.

თუ ასლი გირჩევნია PC-ის გარდა სხვაგან ინახებოდეს, იგივე სქემა object storage-ზეც მუშაობს: game server backups to S3 და rclone with S3 storage ამ გზას მოიცავს.

ჩამოტვირთვის პრობლემების გადაჭრა#

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

• 401 ან 403 API-დან. გასაღები არასწორია, გაუქმებულია ან შეზღუდულია მისამართზე, რომელზეც არ ხარ. შეამოწმე გასაღები ახალ ფანჯარაში echo $env:RENODE_API_KEY-ით; თუ ცარიელია, setx გაეშვა, მაგრამ ეს სესია მასზე ადრე დაიწყო. თუ გასაღები IP-ით შეზღუდე და შენი კავშირის მისამართი შეიცვალა, დაამატე ახალი.
• 404 სერვერზე. მოკლე ID არასწორია, ან გასაღები ისეთ ანგარიშს ეკუთვნის, რომელიც ამ სერვერის მფლობელი ან subuser არ არის.
• დავალება წარმატებას აჩვენებს, მაგრამ არაფერი იტვირთება. შეიძლება ახალი არაფერი იყოს. შეამოწმე Backups ჩანართი: თუ ბოლო backup ჩავარდა ან ჯერ კიდევ მიმდინარეობს, სკრიპტი მას დიზაინით გამოტოვებს.
• ჩამოტვირთვა გაუსაძლისად ნელია. დარწმუნდი, რომ $ProgressPreference-ის ხაზი არის. მის გარეშე Windows PowerShell 5.1 დროის დიდ ნაწილს progress bar-ის ხატვაში ხარჯავს.
• `.part` ფაილი რჩება და log-ში არის BAD ხაზი. ჩამოტვირთვა შეწყდა ან არქივი დაზიანებულია. წაშალე .part ფაილი; შემდეგი გაშვება მას თავიდან გადმოწერს. თუ ერთი და იგივე backup ყოველ ჯერზე ვარდება, panel-ში ახალი შექმენი და ნახე, ის თუ გაივლის.
• "Running scripts is disabled on this system". ეს execution policy-ა. დავალება ამ ერთი სკრიპტისთვის -ExecutionPolicy Bypass-ს აწვდის; ხელით გაშვებისას გამოიყენე იგივე flag და ნუ შეარბილებ პოლიტიკას მთელ მანქანაზე.
• დავალება არ ეშვება, როცა გასული ხარ. ასე დარეგისტრირებული დავალებები მხოლოდ შესვლის დროს მუშაობს, რაც საშუალებას აძლევს მათ შენი მომხმარებლის გარემოს ცვლადი წაიკითხონ. თუ გჭირდება, რომ ისინი მაშინაც გაეშვას, როცა არავინ არის შესული, დაარეგისტრირე შენახული პაროლით და გასაღები გადაიტანე ფაილში, რომლის წაკითხვაც მხოლოდ ამ ანგარიშს შეუძლია.

FAQ#

შემიძლია RE:NODE-ის ღამის backup-ების ჩამოტვირთვა?

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

არსებობს RE:NODE-ის ოფიციალური backup აპლიკაცია დასაყენებლად?

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

შეიცავს ჩამოტვირთული არქივი ჩემს database-ს?

არა. სერვერის backup არქივი სერვერის ფაილებია. database slot ცალკე რამეა და საკუთარ dump-ს საჭიროებს. ჩაწერე dump სერვერის ფაილებში backup-ის გაშვებამდე და ის გადმოწერილ არქივში იქნება.

რამდენი ასლი შევინახო ჩემს PC-ზე?

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

შეანელებს ბეკაპების გადმოწერა ჩემს სერვერს?

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

შემიძლია ამის გამოყენება Mac-ზე ან Linux მანქანაზე?

იდეა პირდაპირ გადადის - ორი API გამოძახება, ჩამოტვირთვა, tar -tzf, retention ნაბიჯი - მაგრამ სკრიპტი PowerShell-ია და scheduler Windows-ისაა. Linux-ზე ან macOS-ზე ეკვივალენტია მოკლე shell სკრიპტი curl-ით და cron ჩანაწერი.