restic restore და check: როგორ დააბრუნო მონაცემები S3-იდან

restic-იდან მონაცემების დასაბრუნებლად snapshot-ს პოულობ restic snapshots-ით, შიგნით იხედები restic ls-ით და აღადგენ ცარიელ საქაღალდეში: restic restore <id> --target /tmp/restore --include <path>. ერთი ფაილი ან მონაცემთა ბაზის dump უფრო სწრაფად გამოდის restic dump-ით, ხოლო restic mount საშუალებას გაძლევს ყველა snapshot საქაღალდესავით დაათვალიერო, როცა ჯერ არ იცი, რას ეძებ. restic check --read-data-subset წინასწარ ამტკიცებს, რომ საჭირო მონაცემები ისევ იკითხება. არცერთი ეს არ მუშაობს repository-ის პაროლის გარეშე და თუ ის დაიკარგა, მას ვერავინ დაგიბრუნებს - ვერც restic და ვერც storage-ის პროვაიდერი.

repository-ის მომზადება, backup-ის სკრიპტი და retention განხილულია პოსტში restic backups to S3. ეს პოსტი მეორე ნახევარია: დღე, როცა მონაცემები გჭირდება, და სწავლებები, რომლებიც ამ დღეს მოსაწყენს ხდის. აქ ყველაფერი ვარაუდობს restic 0.17-ს ან უფრო ახალს; სადაც flag უფრო ახალია ან ძველი ვერსიები სხვაგვარად იქცევა, ეს ნათქვამია.

repository-ში ისევ შესვლა#

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

გჭირდება ზუსტად სამი რამ: repository-ის მისამართი (endpoint, bucket და prefix), წვდომის გასაღებების წყვილი, რომელსაც bucket-ის წაკითხვა შეუძლია, და repository-ის პაროლი. ამათი საშუალებით restic-ის მქონე ნებისმიერ მანქანას შეუძლია აღდგენა.

export AWS_ACCESS_KEY_ID=RNAKEXAMPLE123export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEYexport AWS_DEFAULT_REGION=us-east-1export RESTIC_REPOSITORY=s3:https://s3.example.com/my-bucket/restic/web-01export RESTIC_PASSWORD_FILE=/root/.restic-password

$ . /root/.restic-env$ restic cat config$ restic snapshots

restic cat config ყველაზე პატარა შესაძლო ტესტია: ის კითხულობს ერთ ობიექტს და ამოშიფრავს მას. თუ წარმატებით დასრულდა, endpoint-ი, გასაღებები და პაროლი სწორია, ხოლო ყველაფერი, რაც მერე ჩავარდება, იმის პრობლემაა, რასაც ითხოვ, და არა წვდომისა. ახალ მანქანაზე პირველი ბრძანება ჩვეულებრივზე ნელია, რადგან restic აგებს ლოკალურ metadata cache-ს საქაღალდეში ~/.cache/restic; ეს ნორმალურია და მხოლოდ ერთხელ ხდება.

წვდომის გასაღებები შესაცვლელი ნაწილია. თუ ისინი მხოლოდ მკვდარ სერვერზე ინახებოდა, შექმენი ახალი წყვილი storage-ის პროვაიდერის მართვის პანელიდან და გააგრძელე - repository-ს ყველაფერ ერთია, რომელმა გასაღებმა წაიკითხა. RE:NODE S3 storage-ზე გასაღებები თითო storage სერვერზე გენერირდება და პანელში ჩანს, ამიტომ დაკარგული secret key პანელში შესვლაა და არა კატასტროფა. პაროლი შეუცვლელი ნაწილია და მას ქვემოთ საკუთარი თავი აქვს.

თუ სხვა მანქანაზე აღადგენ, როცა ძველს გულისხმობ, --host პირდაპირ მიუთითე. ახალ მანქანას სხვა hostname აქვს და ფილტრები, რომლებიც ნაგულისხმევად "ამ host-ს" ეძებენ, ვერაფერს იპოვიან.

სწორი snapshot-ის პოვნა#

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

$ restic snapshots --host web-01 --tag nightly$ restic snapshots --latest 3 --compact$ restic snapshots --path /srv/minecraft

ფილტრები ერთმანეთს ერწყმის: --host, --tag და --path ვიწროვებენ სიას, ხოლო --latest n თითოეულ ჯგუფში მხოლოდ n ყველაზე ახალ snapshot-ს აჩვენებს. --json გაძლევს ფორმატს, რომელიც სკრიპტს შეგიძლია გადასცე.

სიტყვა latest გაფრთხილებას იმსახურებს. ფილტრების გარეშე latest ნიშნავს მთელი repository-ის ყველაზე ახალ snapshot-ს, რაც უნდა შეიცავდეს ის. თუ შენი ღამის სკრიპტი /srv-ს ინახავს და მერე --stdin-from-command-ით mysqldump-საც ინახავს, ყველაზე ახალი snapshot მონაცემთა ბაზის dump-ია და restic restore latest --target /tmp/restore შენი სერვერის ნაცვლად ერთ SQL ფაილს მოგცემს. latest ყოველთვის რამესთან მიამაგრე:

$ restic restore latest --tag nightly --host web-01 --target /tmp/restore

როცა კანდიდატი გაქვს, სანამ რამეს აღადგენ, შიგნით ჩახედე:

$ restic ls a81d0b37 /srv/minecraft/world$ restic ls --long latest --tag nightly /etc/nginx$ restic find --host web-01 'server.properties'$ restic diff 4f2a1c9e a81d0b37

სამივე თითო საქმეს აკეთებს:

• restic ls ერთი snapshot-ის ფაილებს ჩამოთვლის, საჭიროების შემთხვევაში ერთი საქაღალდით შეზღუდულს. --long ამატებს ზომას, mode-სა და ცვლილების დროს, რაც გეუბნება, ფაილი ცუდ ცვლილებამდელია თუ მის შემდგომი.
• restic find ყველა snapshot-ში ეძებს სახელს ან pattern-ს და გეუბნება, რომელი snapshot-ები შეიცავს მას. ეს ყველაზე სწრაფი გზაა კითხვაზე "როდის არსებობდა ეს ფაილი ბოლოს?", როცა ვიღაცამ ის სამი კვირის წინ წაშალა.
• restic diff ადარებს ორ snapshot-ს და ჩამოთვლის დამატებულ (+), წაშლილ (-) და შეცვლილ (M) ფაილებს. როცა იცი, რომ რაღაც სამშაბათსა და ოთხშაბათს შორის გაფუჭდა, ამ ორი snapshot-ის diff ჩვეულებრივ გიჩვენებს, რა.

restic restore დეტალურად#

restore მთავარი ინსტრუმენტია. ის კითხულობს snapshot-ს, ჩამოტვირთავს მხოლოდ საჭირო pack-ებს და წერს ფაილებს მათი უფლებებით, დროის ნიშნულებით და, root-ით გაშვებისას, თავდაპირველი მფლობელით. ჩვეულებრივი მომხმარებლით გაშვებისას აღდგენილი ფაილები ამ მომხმარებელს ეკუთვნის.

# Whole snapshot into an empty directory$ restic restore a81d0b37 --target /tmp/restore# One directory$ restic restore a81d0b37 --target /tmp/restore --include /srv/minecraft/world# Everything except the noise$ restic restore a81d0b37 --target /tmp/restore \    --exclude /srv/minecraft/logs --exclude '*.tmp'# Contents of one directory, without the leading path$ restic restore a81d0b37:/srv/minecraft --target /tmp/mc

ბილიკები ისე ინახება, როგორიც იყო. /srv/minecraft/world-ის /tmp/restore-ში აღდგენა გვაძლევს /tmp/restore/srv/minecraft/world-ს და არა /tmp/restore/world-ს - რაც ხალხს ართმევს ნერვებს, როცა ფაილებს target-ის თავში ეძებენ. ბოლო მაგალითში snapshot:subfolder ფორმა ამ პრეფიქსს აშორებს: ის /srv/minecraft-ის შიგთავსს პირდაპირ /tmp/mc-ში აღადგენს.

include და exclude პარამეტრები backup-ის მხარეს ასახავს. --include და --exclude pattern-ებს იღებენ, --iinclude და --iexclude რეგისტრზე დამოუკიდებელია, ხოლო restic 0.17-დან --include-file და --exclude-file pattern-ებს ფაილიდან კითხულობენ, თითო ხაზზე ერთს. ერთი --include-ის გარეშე ყველაფერი აღდგება.

პარამეტრები, რომლებიც restic 0.17-ში დაემატა

ვერსია 0.17-მა restore ბევრად უფრო სასარგებლო გახადა იმ საქაღალდეში აღდგენისას, სადაც უკვე არის მონაცემები:

--overwrite if-changed --delete-თან ერთად restore-ს აქცევს rsync-თან ახლოს რაღაცად snapshot-იდან: უცვლელი ფაილები ხელუხლებელი რჩება, შეცვლილები თავიდან იწერება, ზედმეტები იშლება და target ზუსტი ასლი ხდება. ეს ყველაზე სწრაფი გზაა დიდი საქაღალდის უკან დასაბრუნებლად, სადაც მხოლოდ ცოტა რამ შეიცვალა, და ამავე დროს ამ პოსტის ყველაზე სახიფათო ბრძანება. ყოველთვის ჯერ გაუშვი --dry-run -vv-ით და წაიკითხე ფაილების სია, რომლებსაც წაშლიდა.

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

რამდენ ხანს გრძელდება

აღდგენის სიჩქარე ძირითადად ჩამოტვირთვის სიჩქარეა. restic pack-ებს პარალელურად იღებს რამდენიმე კავშირით (-o s3.connections=5 S3-ის ნაგულისხმევია; გაზრდა შეიძლება დაგეხმაროს სწრაფ არხსა და სწრაფ endpoint-ზე), ამოშიფრავს და ხსნის მათ და წერს ფაილებს. დაშორებული endpoint-ის repository საშინაო კავშირით იზღუდება ამ კავშირით და არა restic-ით. გაზომე ერთხელ რეალურ მონაცემებზე, როგორც ქვემოთ სწავლების თავშია აღწერილი, და ნუ დაეყრდნობი ვარაუდს.

restic dump: ერთი ფაილი, ერთი ბაზა, ერთი არქივი#

როცა ერთი ფაილი გინდა, სრული restore ზედმეტია. dump snapshot-იდან ერთი ფაილის შიგთავსს სტანდარტულ გამოსავალზე წერს:

$ restic dump a81d0b37 /etc/nginx/nginx.conf > /tmp/nginx.conf.old$ diff /tmp/nginx.conf.old /etc/nginx/nginx.conf

ეს ბუნებრივი გზაა --stdin-from-command-ით შენახული მონაცემთა ბაზის dump-ის აღსადგენად, რადგან dump-ს დისკზე ჩაწერა არასოდეს სჭირდება:

$ restic snapshots --tag mysql --latest 1$ restic dump --tag mysql latest /app.sql | mysql app_restore$ restic dump --tag postgres latest /app.sql | psql -d app_restore

ბილიკი ის --stdin-filename-ია, რომელიც backup-ის დროს მიუთითე და snapshot-ის path სვეტში ჩანს. ჯერ აღადგინე ახალ, ცარიელ ბაზაში (app_restore ზემოთ), შეადარე იმას, რასაც ელოდი, და მხოლოდ მერე მიუთითე აპლიკაცია მასზე ან გაცვალე სახელები. კონკრეტული ძრავის აღდგენის ნაბიჯები - მომხმარებლები, grant-ები, --no-owner Postgres-ის custom-format dump-ებისთვის - აღწერილია პოსტებში database backups and restores და mysqldump backup and restore.

საქაღალდის მიცემისას dump გამოიმუშავებს მის tar არქივს, ან zip-ს --archive zip-ით:

$ restic dump latest --tag nightly /srv/minecraft/world > world.tar$ restic dump --archive zip latest --tag nightly /srv/minecraft/world > world.zip

ეს მოსახერხებელია, როცა მონაცემები იქ უნდა მოხვდეს, სადაც restic არ არის დაყენებული - მაგალითად, არქივისთვის, რომელსაც game panel-ის ფაილ მენეჯერით ან SFTP-ით ტვირთავ, სადაც თვითონ სერვერი container-ში მუშაობს და restic არ აქვს.

restic mount: ყველა snapshot-ის დათვალიერება#

restic mount repository-ს FUSE-ით მხოლოდ წასაკითხი ფაილური სისტემის სახით წარმოადგენს:

$ mkdir -p /mnt/restic$ restic mount /mnt/resticNow serving the repository at /mnt/resticUse another terminal or tool to browse the contents of this folder.When finished, quit with Ctrl-c here or umount the mountpoint.

მეორე ტერმინალში repository ასე გამოიყურება:

/mnt/restic/  ids/        one directory per snapshot ID  snapshots/  one directory per snapshot time, plus 'latest'  hosts/      snapshots grouped by host name  tags/       snapshots grouped by tag

შეგიძლია cd გააკეთო snapshots/2026-10-07T04:30:09+02:00/srv/minecraft-ში, გაუშვა ls, grep, less ან diff -r ცოცხალი ხის წინააღმდეგ და ცალკეული ფაილები cp-ით გადმოიტანო. ეს საუკეთესო ინსტრუმენტია, როცა ჯერ არ იცი, რა გჭირდება - "კონფიგურაცია, როგორიც იყო, სანამ ვიღაცამ შეცვალა, გასულ კვირას რაღაც დროს" - რადგან ჩვეულებრივი ინსტრუმენტები ყველა snapshot-ზე ერთდროულად მუშაობენ.

შეზღუდვები:

• მას FUSE სჭირდება: Linux, macOS macFUSE-ით ან FreeBSD. Windows-ზე არ მუშაობს და container-ში ჩვეულებრივ არც იქ, რადგან იქ იშვიათად არის /dev/fuse ან მისი გამოყენების პრივილეგია. თუ mount-ი fusermount-ის უქონლობით ვარდება, Debian-სა და Ubuntu-ზე დააყენე fuse3 (ან fuse).
• მას მხოლოდ ის მომხმარებელი ხედავს, ვინც mount გააკეთა, თუ არ დაამატე --allow-other და სისტემა ამას /etc/fuse.conf-ში არ დაუშვებს.
• მასობრივი კოპირებისთვის ნელია. ყოველი წაკითხვა pack-ებს მოთხოვნისას იღებს და ამოშიფრავს; 20 GB საქაღალდის cp -r mount-იდან ბევრად უფრო ნელია, ვიდრე იმავე საქაღალდის restic restore, რომელიც ჩამოტვირთვებს წინასწარ გეგმავს. დასათვალიერებლად mount, აღსადგენად restore.

გააჩერე Ctrl-C-ით იმ ტერმინალში, სადაც დაიწყო, ან umount /mnt/restic-ით (ზოგ სისტემაზე fusermount -u).

repository-ის შემოწმება, სანამ დაგჭირდება#

restic check იმის გასაგებად გჭირდება, რომ repository დაზიანებულია სამშაბათს შუადღისას და არა გათიშვის დროს. მას ორი დონე აქვს.

$ restic check$ restic check --read-data-subset=5%$ restic check --read-data-subset=3/12$ restic check --read-data

უბრალო check სტრუქტურას ამოწმებს: რომ index თანმიმდევრულია, რომ ყოველი snapshot-ის tree სრულია და რომ ყოველი მითითებული chunk რომელიღაც pack-ში არსებობს. ის მხოლოდ metadata-ს კითხულობს და სწრაფად მთავრდება. pack-ებს არ ხსნის, ამიტომ ვერ შეამჩნევს pack-ს, რომლის ბაიტებიც დაიშალა.

--read-data ყველა pack-ს ჩამოტვირთავს და ყოველ chunk-ს თავის hash-თან ამოწმებს. ეს ერთადერთი სრული დადასტურებაა და დიდ repository-ზე ეს სრული ჩამოტვირთვაა, მასთან დაკავშირებული დროითა და egress-ით. --read-data-subset მის ნაწილს კითხულობს:

• --read-data-subset=5% ყოველ გაშვებაზე pack-ების შემთხვევით 5%-ს ირჩევს. ბევრი გაშვების განმავლობაში ის repository-ის უმეტესობას ფარავს, მაგრამ რომელიმე კონკრეტული pack-ის გარანტიის გარეშე.
• --read-data-subset=n/t pack-ებს t ჯგუფად ყოფს და კითხულობს ჯგუფს n. თუ იანვარში 1/12-ს გაუშვებ, თებერვალში 2/12-ს და ასე შემდეგ, მთელ repository-ს წელიწადში ერთხელ წაიკითხავ და ყოველ pack-ს ზუსტად ერთხელ.

თვის ნომრით n-ად აღებული ყოველთვიური cron job გონივრული ნაგულისხმევია repository-ებისთვის, რომელთა სრულად წაკითხვა ძალიან დიდია:

$ restic check --read-data-subset="$(date +%-m)/12"

სუფთა გაშვება მთავრდება სიტყვებით no errors were found. ყველაფერი სხვა გაჩერებას იმსახურებს. check შეცდომისას არანულოვანი კოდით გამოდის, ამიტომ დაგეგმილ გაშვებას იმავე გზით შეუძლია გაგაფრთხილოს, რომლითაც ჩავარდნილი backup - იხილე monitoring that tells you something.

როცა check შეცდომებს პოულობს

prune ან forget არ გაუშვა repository-ზე, რომელიც check-ს ვერ გადის; ზიანს უფრო რთულად გასაგებს გახდი. იარე თანმიმდევრობით:

1. გაუშვი restic check თავიდან ახალი cache-ით (--no-cache, ან ~/.cache/restic გვერდზე გადადე). დაზიანებულ ლოკალურ cache-ს შეუძლია შეცდომები გამოიღოს, რომლებიც repository-ს არ აქვს.
2. თუ პრობლემა index-შია, restic repair index (restic 0.16 და უფრო ახალი; ძველ ვერსიებში მას rebuild-index ჰქვია) თავიდან აგებს მას რეალურად არსებული pack-ებიდან.
3. თუ pack-ები აკლია ან დაზიანებულია, გაუშვი ახალი backup წყაროდან, სანამ წყარო ისევ არსებობს. chunk-ები, რომლებიც ისევ დისკზეა, თავიდან აიტვირთება და ყველა snapshot გამოჯანმრთელდება, რომელიც მათ იზიარებს.
4. მხოლოდ ამის შემდეგ განიხილე restic repair snapshots, რომელიც snapshot-ებს გადაწერს, რათა ნამდვილად დაკარგულ მონაცემებზე მითითებები მოაშოროს. ის ამ ფაილებს ისტორიიდან კარგავს; უკან არ აბრუნებს.

repository-ის დაზიანება ჯანმრთელ storage-ზე იშვიათია. როცა ხდება, მიზეზი ჩვეულებრივ restic-ის გარეთაა: storage, რომელმაც ობიექტები ჩუმად დაკარგა, bucket-ზე lifecycle წესი, რომელმაც ძველი ფაილები წაშალა, ან ორი ინსტრუმენტი, რომელიც ერთსა და იმავე prefix-ში წერს.

დაკარგული პაროლის რეალობა#

restic repository-ის ყოველი ობიექტი მთავარი გასაღებით არის დაშიფრული, ხოლო მთავარი გასაღები keys/ საქაღალდეში ინახება შენი პაროლით დაშიფრული. არ არსებობს არც უკანა კარი, არც reset ბმული და არც support ticket, რომელიც დაგეხმარება. თუ repository-ის ყველა პაროლი დაიკარგა, მონაცემები აღდგენადი არ არის - არც შენ, არც storage-ის პროვაიდერს, არც restic-ის დეველოპერებს. ეს დიზაინია, რომელიც ისე მუშაობს, როგორც განზრახული იყო.

შეგიძლია იზრუნო, რომ ეს არასოდეს მოხდეს:

$ restic key list$ restic key add          # asks for a new password$ restic key passwd       # changes the password of the current key$ restic key remove 3e1b0c9d

სამი ჩვევა ამას ასე ინარჩუნებს:

• გქონდეს ერთზე მეტი გასაღები. restic key add მეორე პაროლს ამატებს, რომელიც იმავე repository-ს ხსნის. ერთი შეინახე სერვერზე /root/.restic-password-ში, მეორე კი პაროლების მენეჯერში ან დალუქულ კონვერტში, რომელიც სერვერთან ერთად არ ინახება. ყოველი გასაღები ყველაფერს ხსნის; ისინი თანასწორია.
• შეამოწმე ასლი და არა მხოლოდ ორიგინალი. პაროლი პაროლების მენეჯერში ბეჭდური შეცდომით პაროლის backup არ არის. გახსენი repository შენახული ასლით ერთხელ: restic -r ... --password-file /tmp/pw-from-vault snapshots.
• იცოდე, რას არ აკეთებს პაროლის შეცვლა. key passwd და key remove ცვლიან იმას, ვინ შეძლებს მთავარი გასაღების გახსნას; მონაცემებს თავიდან არ შიფრავენ. ვისაც ოდესმე სამუშაო პაროლი და გასაღების ფაილის ასლი ჰქონდა, მაინც შეძლებს repository-ის ამოშიფვრას. თუ პაროლი გაჟონა, ერთადერთი რეალური გამოსავალი ახალი repository-ა: restic init ახალზე და restic copy იმ snapshot-ებისთვის, რაც გინდა.

წვდომის გასაღებები და პაროლი ცალკე საიდუმლოებებია. გაჟონილი S3 secret key ვინმეს საშუალებას აძლევს წაშალოს ან ჩამოტვირთოს შენი დაშიფრული pack-ები, მაგრამ არა წაიკითხოს ისინი; შეცვალე ის პროვაიდერის პანელში. გაჟონილი repository-ის პაროლი S3 გასაღებების გარეშე მათ არაფერს აძლევს, სანამ bucket-ამდეც არ მიაღწევენ. შეინახე ეს ორი ერთმანეთისგან ცალ-ცალკე.

restic restore-ის სასწავლო აღდგენა#

backup, რომელიც არასდროს აღგიდგენია, ჰიპოთეზაა. ზოგადი მეთოდი - რა გაზომო, რა ჩავარდება ხშირად, როგორ დაწერო runbook - აღწერილია პოსტში testing a restore before you need it. restic-ისთვის კონკრეტულად სწავლება იმდენად მოკლეა, რომ ყოველ კვარტალში შეგიძლია გაუშვა:

1. დაიწყე მანქანიდან, რომელიც სერვერი არ არის. ერთჯერადი VM, მეორე პატარა სერვერი, შენი ლეპტოპი. დააყენე restic. აზრი ისაა, რომ დაამტკიცო: შეგიძლია აღდგენა ორიგინალი მანქანიდან არაფრის გამოყენების გარეშე.
2. გამოიყენე მხოლოდ ის, რაც გარეთ ინახება. Endpoint, bucket და prefix, წვდომის გასაღები, პაროლი - პაროლების მენეჯერიდან და არა სერვერიდან გადაწერილი. თუ რამისთვის სერვერზე უნდა შეხედო, ჩაიწერე: ეს დამოკიდებულებაა, რომელიც შენს აღდგენას იმაზე აქვს, რაც ჩავარდა.
3. აირჩიე ძველი snapshot. არა latest: retention-ში მოქცეული ყველაზე ძველი ამოწმებს, რომ retention იმუშავა და ძველი მონაცემები ხელუხლებელია.
4. აღადგინე ტაიმერით. time restic restore <id> --target /tmp/restore --verify. ჩაიწერე ზომა და დრო. ეს რიცხვი, შენი ყველაზე დიდი სერვერის ზომაზე გაყოფილი, ამ კავშირზე შენი რეალური აღდგენის დროა.
5. ბაზაც აღადგინე. restic dump ... | mysql app_restore ან ექვივალენტი, შემდეგ დათვალე სტრიქონები მნიშვნელოვან ცხრილებში და იპოვე ყველაზე ახალი დროის ნიშნული.
6. შეამოწმე შიგთავსი. მოძებნე canary - ფაილი ან ბაზის სტრიქონი backup-ის თარიღით - და რამდენიმე მთავარი ფაილი diff-ით შეადარე წყაროს. თუ შეგიძლია, გაუშვი აპლიკაცია აღდგენილ მონაცემებზე.
7. გაუშვი მონაცემთა შემოწმებაც, სანამ იქ ხარ. restic check --read-data-subset=1/12 repository-ის მეთორმეტედს ამატებს მტკიცებულებებს.
8. ჩაიწერე, რა აკლდა. კონფიგურაციის ფაილი backup-ის ბილიკების გარეთ, startup flag, საიდუმლო, რომელიც მხოლოდ environment ცვლადში ცხოვრობდა. შეასწორე backup და არა მხოლოდ runbook.

game server-ებისთვის იგივე სწავლება ადასტურებს, რომ world აღდგება და ჩაიტვირთება; save-flush წესები, რომლებიც world-ს საერთოდ თანმიმდევრულს ხდის, აღწერილია პოსტში game server backups to S3.

შეცდომები, რომლებსაც აღდგენისას შეხვდები#

შენიშვნები თითოეულზე:

• არასწორი პაროლი. შეამოწმე, რომ RESTIC_PASSWORD_FILE იმ ფაილზე მიუთითებს, რაზეც ფიქრობ, და რომ ფაილში პაროლია და სხვა არაფერი - არც წინა ჰარი, არც მეორე ხაზი. 0.17-დან restic არასწორი პაროლისას კოდით 12 გამოდის, რასაც სკრიპტებს შეუძლია დაუკვირდეს.
• repository არ არსებობს. prefix მისამართის ნაწილია. s3:https://s3.example.com/my-bucket/restic/web-01 და .../my-bucket/restic/web01 სხვადასხვა repository-ებია და ერთ-ერთი არ არსებობს. bucket-ის შიგთავსი ნებისმიერი S3 კლიენტით ჩამოთვალე, რომ ნახო, რა არის რეალურად. თუ endpoint-ს path-style მისამართი სჭირდება, დაამატე -o s3.bucket-lookup=path, როგორც ამას განმარტავს S3 path-style vs virtual-hosted.
• დაბლოკილია. restore, ls, dump და mount არაექსკლუზიურ lock-ს იღებენ და backup-ებთან ერთად მუშაობენ, მაგრამ prune-თან ერთად არა. თუ სხვა პროცესი არ მუშაობს, restic unlock მოძველებულ lock-ებს უსაფრთხოდ შლის. აღდგენისთვის, რომელსაც ლოდინი არ შეუძლია, --no-lock მხოლოდ წასაკითხ ბრძანებებზე lock-ს გამოტოვებს იმ რისკით, რომ წაიკითხავ, სანამ prune შენ ქვეშ მონაცემებს შლის.
• ხელმოწერის შეცდომები. ან secret key არასწორია, ან მანქანის საათი იმდენადაა გადახრილი, რომ მოთხოვნის ხელმოწერა უარყოფილია. ყველაფერზე ადრე საათი NTP-ით გაასწორე.

FAQ#

შემიძლია restic backup-ის აღდგენა restic-ის გარეშე?

არა. repository დაშიფრულია, შეკუმშულია და chunk-ებადაა დაყოფილი; სხვა ვერაფერი ვერ კითხულობს მას. restic ერთი სტატიკური binary-ია Linux-ის, macOS-ის, Windows-ისა და BSD-სთვის, ამიტომ ჩამოტვირთვის ბმული შენს runbook-ში შეინახე. თუ რამისთვის უბრალო არქივი გჭირდება, რაც restic-ს ვერ გაუშვებს, მოამზადე ის restic dump-ით მანქანაზე, რომელსაც შეუძლია.

შემიძლია Windows-ზე აღვადგინო Linux-ის backup?

დიახ, restic restore ოპერაციულ სისტემებს შორის მუშაობს. Unix-ის მფლობელობა და უფლებების ზოგიერთი ბიტი NTFS-ზე ვერ გადავა და mount Windows-ზე ხელმისაწვდომი არ არის, მაგრამ ფაილების შიგთავსი ხელუხლებელი დაბრუნდება.

როგორ აღვადგინო მხოლოდ ერთი წაშლილი ფაილი?

იპოვე ბოლო snapshot, რომელშიც ის იყო, restic find --host web-01 'filename'-ით, შემდეგ restic dump <id> /full/path/to/file > file. ეს მხოლოდ იმ ფაილს წერს და დანარჩენ საქაღალდეს არ ეხება.

გადაწერს თუ არა restore target-ში უფრო ახალ ფაილებს?

ნაგულისხმევად დიახ: --overwrite always არსებულ ფაილებს ცვლის. restic 0.17-დან შეგიძლია აირჩიო if-newer, რომ snapshot-ზე ახალი ფაილები დარჩეს, ან never, რომ მხოლოდ ნაკლული ფაილები შეეხოს. ცარიელ საქაღალდეში აღდგენა კითხვას საერთოდ აცილებს.

რამდენად ხშირად გავუშვა check read-data-ით?

უბრალო check ყოველკვირეულად, ხოლო მორიგეობითი --read-data-subset=n/12 ყოველთვიურად ყველა pack-ს წელიწადში ერთხელ კითხულობს, ყოველ ჯერზე სრული ჩამოტვირთვის გარეშე. პატარა repository-ზე სრული --read-data თვეში ერთხელ საკმარისად იაფია, რომ უბრალოდ გააკეთო.

საკმარისია თუ არა restic repository ერთ S3 სერვერზე?

როგორც ერთი ასლი, დიახ. RE:NODE S3 storage, მაგალითად, ერთ ასლს ინახავს NVMe-ზე ერთ ლოკაციაზე, რეპლიკაციის გარეშე - ეს კარგი მანქანიდან მოშორებული ასლია და არა შენი ერთადერთი. restic copy მეორე repository-ში სხვაგან დანარჩენს ფარავს, როგორც ამას S3 storage sizing and the 3-2-1 rule განიხილავს.