თამაშის სერვერის backup-ები S3-ში: სამყაროს გარე ასლები განრიგით

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

რატომ მეორე ასლი და რისგან იცავს ის#

პანელის backup-ები და S3-ის ასლი სხვადასხვანაირად მარცხდება, და სწორედ ამიტომ ღირს ორივეს ქონა.

RE:NODE-ზე თამაშის გეგმები მოიცავს backup-ის სლოტებს, რომლებიც ინახება იმ მანქანის გარეთ, რომელსაც იცავს, შეიძლება ჩაიკეტოს როტაციისგან და ღილაკით აღდგეს - მაგრამ სერვერის წაშლა მის backup-ებსაც შლის, ჩაკეტილების ჩათვლით. bucket-ში არსებული ასლი ამას გადაურჩება. თუმცა მეორე სტრიქონთან დაკავშირებით გულახდილი იყავი: RE:NODE-ის S3 საცავი შენი მონაცემების ერთ ასლს ინახავს NVMe-ზე ერთ ლოკაციაში, გერმანიაში, იმავე ადგილას, სადაც თამაშის სერვერებია. ის იცავს წაშლისა და შეცდომებისგან, და არა მთელი ლოკაციის დაკარგვისგან. სამყაროსთვის, რომლის დაკარგვაც გულს გაგიტეხდა, მესამე სვეტსაც აქვს მნიშვნელობა, და იმავე rclone-ის დავალებას შეუძლია ასლი შენს საკუთარ დისკზეც ჩააგდოს. backup-ები, რომლებიც მართლა აღდგება 3-2-1-ის ლოგიკას სრულად განიხილავს, ხოლო S3 საცავის ზომა და 3-2-1 წესი მას bucket-ებზე იყენებს.

სისტემის აგებულება#

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

ამომღები შეიძლება იყოს ნებისმიერი რამ, რაც ტაიმერით მუშაობს: Linux VDS, სახლის სერვერი ან Raspberry Pi, ან Windows PC, რომელიც ღამით ჩართულია. მას სჭირდება rclone, თამაშის სერვერის SFTP-ის მონაცემები და bucket-ის გასაღებები. თამაშის გაშვება ან ფაილების შენახვა გაშვებებს შორის არასოდეს სჭირდება, თუ restic-ს არ აირჩევ, რომელიც პატარა cache-ს ინახავს.

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

რა დააკოპირო#

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

ეს გზები იცვლება, თუ სერვერი save-ის მორგებული საქაღალდით ეშვება, ამიტომ შენი გზები გაშვების ხაზს შეადარე. თამაშის სერვერის backup-ის სტრატეგიაში უფრო გრძელი სიაა, მათ შორის თამაშები, სადაც აშკარა საქაღალდე მთელი ამბავი არ არის - კლასიკური მაგალითია Project Zomboid-ის მოთამაშეების მონაცემთა ბაზა.

არჩევანი rclone-ის ფილტრის ფაილად ჩაწერე. ის ამავდროულად დოკუმენტაციაცაა იმისა, რას შეიცავს შენი backup სინამდვილეში:

+ /world/**+ /world_nether/**+ /world_the_end/**+ /plugins/**+ /server.properties+ /*.json- /plugins/*.jar.old- /plugins/**/logs/**- *

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

rclone-ის remote-ების დაყენება#

დააყენე rclone ამომღებზე (sudo apt install rclone ხშირად ძველ ვერსიას აყენებს; ინსტალაციის სკრიპტი ან rclone.org-ის release ბინარი მიმდინარე ვერსიას მოგცემს), შემდეგ განსაზღვრე ორი remote - ერთი თამაშის სერვერის SFTP-ისთვის, მეორე საცავისთვის.

[mc]type = sftphost = sftp.example-node.netport = 2022user = yourname.a1b2c3d4pass = <output of: rclone obscure 'your-sftp-password'>[store]type = s3provider = Otheraccess_key_id = AKIA...secret_access_key = ...endpoint = https://s3.example.comregion = us-east-1force_path_style = true

SFTP-ის ჰოსტი, პორტი და მომხმარებლის სახელი აიღე ზუსტად ისე, როგორც პანელი აჩვენებს ამ სერვერისთვის - Pterodactyl-ზე დაფუძნებულ პანელებზე მომხმარებლის სახელს სერვერის სუფიქსი აქვს, პორტი კი ჩვეულებრივ 22 არ არის. pass ველში უნდა იყოს rclone obscure-ის გამონატანი და არა უბრალო პაროლი. rclone obscure შექცევადი კოდირებაა და არა დაშიფვრა, ამიტომ თავად ფაილი დაიცავი chmod 600-ით. SFTP და ფაილების მენეჯერი ხსნის, საიდან მოდის ეს მონაცემები.

საცავის remote-ისთვის provider = Other არის ზოგადი S3-თავსებადი პარამეტრი, force_path_style = true კი rclone-ში უკვე ნაგულისხმევია. endpoint არის HTTPS ჰოსტის სახელი, რომელიც საცავის გეგმის proxy სლოტზე მიმართე; პირდაპირი plain-HTTP პორტიც მუშაობს, მაგრამ მაშინ შენი სამყარო დაუშიფრავად მოგზაურობს. სანამ რამეს გააკეთებ, ორივე remote შეამოწმე:

$ rclone lsd mc:/$ rclone ls mc:/ --filter-from minecraft.filter | head$ rclone lsd store:$ rclone mkdir store:game-backups

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

სუფთა ასლის მიღება: ჯერ შენახვა#

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

RE:NODE-ზე Schedules ჩანართი cron-ის გამოსახულებით უშვებს დალაგებულ დავალებებს დაყოვნებებით. Minecraft-ისთვის ღამის განრიგი 03:55-ზე ასეთი იქნება:

Task 1  command  save-offTask 2  command  save-all flush       (delay 5 s)Task 3  command  save-on              (delay 600 s)

save-off აჩერებს autosave-ს, რომ თამაშმა კოპირების შუაში region ფაილების გადაწერა არ დაიწყოს, save-all flush ყველაფერს დისკზე წერს და ელოდება დასრულებას, save-on კი autosave-ს ათი წუთის შემდეგ აბრუნებს, მას შემდეგ, რაც ამომღებმა 04:00-ზე საქმე დაასრულა. სამყაროსთვის, რომელიც ერთ წუთში კოპირდება, ათი წუთი უხვია; მრავალგიგაბაიტიანი სამყაროსთვის გაზომე ერთი გაშვება და შუალედი გაზარდე. სხვა თამაშებს თავიანთი შენახვის ბრძანება აქვთ - save Project Zomboid-სა და Terraria-ში, saveworld 7 Days to Die-ში, /server-save Factorio-ში - ზოგს კი, მაგალითად Valheim-სა და DayZ-ს, სერვერის კონსოლის ბრძანება არ აქვს, და მათი კოპირება ყველაზე უსაფრთხოა დაგეგმილი პანელის backup-იდან ან სუფთა restart-ის შემდეგ. დაგეგმილი დავალებები, რომლებიც ღირს და cron-ის გამოსახულებების ახსნა scheduler-ს განიხილავს.

ამომღების საათი და პანელის განრიგი დროის სარტყელზე უნდა თანხმდებოდეს. ორივე UTC-ში ჩაწერე, ან შეამოწმე, თითოეული რას ვარაუდობს, სანამ ხუთწუთიან შუალედს ენდობი.

ისტორიის შენახვა versioning-ის გარეშე#

ერთი rclone sync bucket-ს სერვერის იდენტურად ინახავს - ეს კი ნიშნავს, რომ როცა სამყაროს 21:00-ზე დაანგრევენ, 04:00-ის sync ერთგულად გადააწერს დანგრეულ სამყაროს კარგს. backup-ს ისტორია სჭირდება. bucket-ის versioning-ის გარეშე მისი მიღების სამი გზა არსებობს.

თარიღიანი სრული ასლები. ყოველი ღამე საკუთარ prefix-ში მიდის. მარტივია, აღდგენა აშკარაა და დღეში მთელი სამყაროს ზომა ჯდება.

$ rclone copy mc:/ store:game-backups/mc/daily/$(date -u +%F) \    --filter-from minecraft.filter --transfers 4 --log-file /var/log/mc-backup.log

Sync backup-ის საქაღალდით. bucket ერთ მიმდინარე ასლს ინახავს, და ყოველი ფაილი, რომელსაც sync გადააწერდა ან წაშლიდა, ჯერ თარიღიან საქაღალდეში გადადის. ისტორია მხოლოდ შეცვლილი ფაილების ფასი ჯდება, რაც Minecraft-ის სამყაროსთვის ის region ფაილებია, რომლებსაც მოთამაშეები მართლა ეწვივნენ.

$ rclone sync mc:/ store:game-backups/mc/current \    --backup-dir store:game-backups/mc/changed/$(date -u +%F) \    --filter-from minecraft.filter

ამ გზით წარსული დღის აღდგენა ნიშნავს, რომ აიღო current და თარიღიანი საქაღალდეები ზემოდან დაადო, უახლესიდან დაწყებული სასურველ დღემდე - შესაძლებელია, მაგრამ სტრესის ქვეშ წვალებაა.

restic. rclone-ით ფაილები ლოკალურ შუალედურ საქაღალდეში გადმოიტანე, შემდეგ restic-ს bucket-ში snapshot-ის გადაღება მიანდე. restic დედუპლიკაციას chunk-ის დონეზე აკეთებს და ყველაფერს შიფრავს, ამიტომ სამყაროს ოცდაათი ყოველდღიური snapshot, რომელიც ყოველდღე ცოტათი იცვლება, ერთზე ოდნავ მეტი ჯდება. ნებისმიერი snapshot-ის აღდგენა ერთი ბრძანებაა. ეს საუკეთესო ვარიანტია, თუ ამომღებს ცოტა ლოკალურ დისკს დაუთმობ.

$ rclone sync mc:/ /srv/stage/mc --filter-from minecraft.filter$ restic -r s3:https://s3.example.com/game-backups/restic backup /srv/stage/mc --tag mc

restic გარემოდან კითხულობს AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY და RESTIC_PASSWORD (ან RESTIC_PASSWORD_FILE) ცვლადებს. დაკარგე restic-ის პაროლი და რეპოზიტორია წაუკითხავი ხდება - ეს ასეა ჩაფიქრებული. restic-ის backup-ები S3-ში რეპოზიტორიის ინიციალიზაციას და დანარჩენს განიხილავს.

შენახვის ვადა და გასუფთავება#

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

აშკარა ბრძანება არასწორია. rclone delete --min-age 14d ფილტრავს თითოეული ობიექტის ცვლილების დროით, rclone კი ატვირთვისას წყაროს ფაილის ცვლილების დროს ინარჩუნებს (ობიექტის მეტამონაცემებში ინახავს). კონფიგის ფაილი, რომელსაც თვის განმავლობაში არავინ შეხებია, ამაღამინდელ თარიღიან საქაღალდეში უკვე "ერთი თვის" ჩადის, და --min-age 14d მას დავალების დასრულებისთანავე შლის. შენი უახლესი backup ჩუმად კარგავს ყველა ფაილს, რომელიც ბოლო დროს არ შეცვლილა - ზუსტად იმ ფაილებს, რომელთა შემოწმებაც თავში არ მოგივა.

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

CUTOFF=$(date -u -d '14 days ago' +%F)rclone lsf --dirs-only store:game-backups/mc/daily | while read -r d; do  d=${d%/}  if [[ "$d" < "$CUTOFF" ]]; then    rclone purge "store:game-backups/mc/daily/$d"  fidone

ISO თარიღები (2026-10-08) ერთნაირად ლაგდება როგორც ტექსტად, ისე დროდ, რის გამოც უბრალო სტრიქონების შედარება მუშაობს. date -d GNU date-ია, Linux-ზე სტანდარტული; macOS-ზე გამოიყენე date -u -v-14d +%F. იგივე ეხება --backup-dir-ის განლაგებას: თარიღიანი changed/ საქაღალდეები სახელით გაასუფთავე, არასოდეს --min-age-ით. restic-ში შენახვის ვადა პოლიტიკაა:

$ restic -r s3:https://s3.example.com/game-backups/restic forget \    --tag mc --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

თამაშის სერვერების უმეტესობისთვის გონივრული პოლიტიკაა ერთი კვირის ყოველდღიურები, ერთი თვის ყოველკვირეულები და ასლი ყოველი დიდი განახლების წინ, შენახული უვადოდ. bucket-ის ზომა აქედან გამოთვალე: 2 GB-იან Minecraft-ის სამყაროს თარიღიანი სრული ასლებით თოთხმეტი დღის განმავლობაში დაახლოებით 28 GB სჭირდება; იგივე ისტორია restic-ში ჩვეულებრივ ერთი სამყაროს მცირე ჯერადია. რამდენი საცავი სჭირდება თამაშის სერვერს ამ ჯამის სამყაროს მხარეში დაგეხმარება.

დავალების დაგეგმვა#

ყველაფერი ერთ სკრიპტში ჩადე, რომ განრიგი ერთი ხაზი იყოს:

#!/usr/bin/env bashset -euo pipefailDAY=$(date -u +%F)CUTOFF=$(date -u -d '14 days ago' +%F)rclone copy mc:/ "store:game-backups/mc/daily/$DAY" \  --filter-from /etc/rclone/minecraft.filter --log-file /var/log/mc-backup.logrclone lsf --dirs-only store:game-backups/mc/daily | while read -r d; do  d=${d%/}  if [[ "$d" < "$CUTOFF" ]]; then rclone purge "store:game-backups/mc/daily/$d"; fidonecurl -fsS -m 10 https://hc.example.com/ping/mc-backup > /dev/null || true

შემდეგ crontab -e და 0 4 * * * /usr/local/bin/mc-backup.sh. set -euo pipefail სკრიპტს პირველივე შეცდომაზე აჩერებს, ამიტომ წარუმატებელი კოპირება ძველი backup-ების წაშლამდე არასოდეს მიდის. ბოლო ხაზი dead-man's-switch მონიტორს აპინგებს (Healthchecks.io და მსგავსი სერვისები), რომელიც გაფრთხილებს, როცა პინგი არ მოდის - ეს ერთადერთი საიმედო გზაა, შეამჩნიო backup-ის დავალება, რომელიც ჩუმად გაჩერდა. Windows-ის ამომღებზე Task Scheduler იმავე rclone-ის ბრძანებებს .bat ფაილიდან უშვებს; rclone იქაც ზუსტად ისე იქცევა.

აღდგენა bucket-იდან#

backup, რომელიც არავის აღუდგენია, ჰიპოთეზაა. აღადგინე ერთი, სანამ დაგჭირდება:

1. აირჩიე დღე და ჩამოტვირთე შენს PC-ზე: rclone copy store:game-backups/mc/daily/2026-10-07 ./restore-test.
2. გახსენი სამყარო თამაშის ლოკალურ ასლში ან სატესტო სერვერზე და მთავარ ბაზაში გაიარე.
3. ნამდვილი აღდგენისთვის გააჩერე თამაშის სერვერი, დაზიანებული სამყაროს საქაღალდე გვერდზე გადადე, ატვირთე აღდგენილი rclone-ით ან ფაილების მენეჯერით და გაუშვი სერვერი.

აღდგენის პირდაპირ SFTP-ით უკან გაგზავნა იგივენაირად მუშაობს, საპირისპირო მიმართულებით - rclone copy store:game-backups/mc/daily/2026-10-07 mc:/ - მაგრამ მხოლოდ გაჩერებულ სერვერზე, თორემ თამაშის შემდეგი შენახვა გადააწერს იმას, რაც ახლახან დააბრუნე. აღდგენის ტესტირება მანამ, სანამ დაგჭირდება ამას კვარტალურ ჩვევად აქცევს.

FAQ#

შეუძლია თამაშის სერვერს თავად ატვირთოს S3-ში?

პანელის თამაშის სერვერიდან - არა: მისი scheduler უშვებს კონსოლის ბრძანებებს, backup-ებს და კვების მოქმედებებს, და არა shell სკრიპტებს. ზოგ თამაშს აქვს plugin-ები, რომლებიც backup-ებს S3-ში ტვირთავს, და ისინი მუშაობს, თუ plugin-ს ენდობი. სხვა შემთხვევაში გარედან აიღე rclone-ით, როგორც ზემოთაა.

რამდენად ხშირად უნდა დავაკოპირო სამყარო გარე ადგილას?

სერვერების უმეტესობისთვის ყოველდღიურად, ყველაზე მშვიდ საათში. დაამატე ხელით ასლი ყოველი თამაშის განახლებისა და ყოველი მნიშვნელოვანი plugin-ის ცვლილების წინ. დიდი სამყაროს ყოველსაათიანი ასლები იმაზე მეტი ჯდება, ვიდრე იცავს.

პანელის backup არ კმარა?

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

უნდა დავშიფრო თამაშის სამყაროს backup-ები?

restic ნაგულისხმევად ყველაფერს შიფრავს. rclone-ში საცავის remote შეგიძლია crypt remote-ში შეფუთო. თამაშის სამყაროსთვის მთავარი მიზეზი ისაა, რომ კონფიგები ხშირად შეიცავს RCON-ისა და მონაცემთა ბაზის პაროლებს.

შეანელებს სამყაროს კოპირება სერვერს?

რამდენიმე ასეული მეგაბაიტის SFTP-ით წაკითხვა მსუბუქია, მაგრამ დიდმა სამყარომ დატვირთულ სერვერზე შეიძლება მოკლე შეფერხება გამოიწვიოს. გაუშვი დავალება ყველაზე მშვიდ საათში და გამოიყენე --bwlimit rclone-ში, თუ მოთამაშეები შეამჩნევენ.