rclone S3 საცავთან: sync, copy, mount და crypt

rclone ის ხელსაწყოა, რომელსაც მიმართავ, როცა გინდა ფაილები შენს მანქანას, სერვერსა და S3 საცავს შორის გადაიტანო იმაზე მეტი კონტროლით, ვიდრე AWS CLI გაძლევს. დააკონფიგურირე s3 ტიპის ერთი remote პროვაიდერით Other, შენი endpoint-ით, access key-ით, secret key-ით, ნებისმიერი რეგიონით და force_path_style = true-ით, და შემდეგ rclone copy, rclone sync, rclone mount და დაშიფრული crypt ფენა ყველა მასთან იმუშავებს. ბრძანებები მარტივია; სიფრთხილეს მოითხოვს sync, რადგან ის შლის. ეს პოსტი remote-ს აწყობს, ხსნის, როგორ წყვეტს rclone, რა გადაიტანოს, და აჩვენებს flag-ებს, რომლებიც დაგეგმილ job-ს სწრაფს, შენი გამტარუნარიანობის მიმართ თავაზიანს და საკუთარი შეცდომებისგან დაცულს ხდის.

Remote-ის კონფიგურაცია#

დააყენე rclone rclone.org-იდან (ერთი binary ფაილი; დისტრიბუციების პაკეტები ხშირად ძალიან ჩამორჩება) და შეამოწმე rclone version. შემდეგ შექმენი remote. ინტერაქტიული გზაა rclone config, სადაც ირჩევ s3-ს, შემდეგ პროვაიდერს Other ზოგადი S3-თავსებადი სერვისისთვის. პირდაპირი გზა ერთი ბრძანებაა:

$ rclone config create renode s3 \    provider=Other \    access_key_id=RNAKEXAMPLE123 \    secret_access_key=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY \    endpoint=https://s3.example.com \    region=us-east-1 \    force_path_style=true \    no_check_bucket=true

რაც კონფიგურაციის ფაილში ამას წერს - rclone config file დაბეჭდავს, სად არის ის:

[renode]type = s3provider = Otheraccess_key_id = RNAKEXAMPLE123secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEYendpoint = https://s3.example.comregion = us-east-1force_path_style = trueno_check_bucket = true

პარამეტრები, რომლებსაც მნიშვნელობა აქვს:

• provider = Other - ეუბნება rclone-ს, რომ არცერთი პროვაიდერის თავისებურებები არ ივარაუდოს.
• endpoint - საბაზისო URL. ჰოსტის სახელი HTTPS-ით სწორი არჩევანია ყველაფრისთვის, რაც ინტერნეტს კვეთს; http://host:port მუშაობს, მაგრამ მონაცემებს ღია ტექსტად აგზავნის.
• region - ნებისმიერი სახელი, რომელსაც სერვერი იღებს; ის მოთხოვნის ხელმოწერის ნაწილია. ყველა ხელსაწყოში ერთნაირი შეინარჩუნე.
• force_path_style = true - bucket URL-ის გზაში იწერება და არა ქვედომენში. ეს rclone-ის ნაგულისხმევია, მაგრამ მისი ცალსახად მითითება გიცავს პროვაიდერის preset-ისგან, რომელიც მას გამორთავს.
• no_check_bucket = true - rclone-ს უკრძალავს, ყოველი ატვირთვის წინ bucket-ის შექმნა სცადოს. სასარგებლოა, როცა bucket უკვე არსებობს, და აუცილებელი, როცა შენს key-ებს bucket-ების შექმნის უფლება შეიძლება არ ჰქონდეს.

RE:NODE-ზე პანელი გაჩვენებს საცავის სერვერისთვის გენერირებულ access key-სა და secret key-ს, და პირველი bucket შენთვის იქმნება. Endpoint არის გეგმის მისამართი და პორტი უბრალო HTTP-ით, ან შენი საკუთარი ჰოსტის სახელი HTTPS-ით, როგორც კი მისი A ჩანაწერი გეგმის proxy slot-ზე მიუთითებს, რომელიც სერტიფიკატზე ზრუნავს.

კონფიგურაციის ფაილი secret key-ს ინახავს. ან ფაილი დაიცავი (chmod 600), ან მთელი კონფიგურაცია დაშიფრე rclone config-ით და "Set configuration password" ოფციით, პაროლს კი გაშვებისას RCLONE_CONFIG_PASS-ში გადასცემ. კონტეინერებისა და CI-ისთვის remote შეიძლება მთლიანად გარემოს ცვლადებში ცხოვრობდეს - RCLONE_CONFIG_RENODE_TYPE=s3, RCLONE_CONFIG_RENODE_ENDPOINT=... და ასე შემდეგ, თითო თითოეულ პარამეტრზე - ფაილის გარეშე.

პირველი ბრძანებები და გზის სინტაქსი#

გზები ასე იწერება: remote:bucket/prefix. ლოკალური გზა უბრალოდ გზაა.

$ rclone lsd renode:                       # buckets$ rclone lsf renode:my-bucket/backups/     # one level, names only$ rclone ls renode:my-bucket               # every object with size$ rclone size renode:my-bucket             # object count and total bytes$ rclone ncdu renode:my-bucket             # interactive usage browser

rclone ncdu ყველაზე სწრაფი გზაა იმის გასარკვევად, რა ავსებს bucket-ს - ის მთელ ხეს გადის და ზომის მიხედვით დათვალიერების საშუალებას გაძლევს, როგორც Unix ხელსაწყო, რომლის სახელიც ატარებს.

copy, sync, move: რას აკეთებს თითოეული#

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

# ყოველთვის ჯერ შეხედე$ rclone sync /srv/data renode:my-bucket/data --dry-run# შემდეგ გააკეთე, ზღვრით იმაზე, რამდენის წაშლა შეუძლია$ rclone sync /srv/data renode:my-bucket/data --max-delete 50

--dry-run ჩამოთვლის, რა მოხდებოდა. --interactive (-i) ყოველი დესტრუქციული მოქმედების წინ გეკითხება. --max-delete 50 გაშვებას წყვეტს, თუ ის 50-ზე მეტ ფაილს წაშლიდა, და ეს არის დამცავი, რომელიც იჭერს შემთხვევას "წყაროს დისკი არ იყო მიერთებული და ცარიელი ჩანდა".

sync დამცავი ბადით

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

$ rclone sync /srv/data renode:my-bucket/current \    --backup-dir renode:my-bucket/archive/$(date +%F) \    --max-delete 100 --log-file /var/log/rclone-data.log --log-level INFO

Backup დირექტორია დანიშნულების იმავე remote-ზე უნდა იყოს და მას არ უნდა ფარავდეს. S3-ზე მასში ფაილის "გადატანა" სერვერის მხარის კოპირებაა პლუს წაშლა, ასე რომ არაფერი ჩამოიტვირთება. ძველ არქივის საქაღალდეებს თავად ასუფთავებ - rclone purge renode:my-bucket/archive/2026-07-01-ით, ან პატარა სკრიპტით, რომელიც შენახვის ვადაზე ძველ საქაღალდეებს შლის, ან rclone delete --min-age 90d renode:my-bucket/archive-ით.

როგორ წყვეტს rclone, რა გადაიტანოს#

ნაგულისხმევად rclone ადარებს ზომასა და ცვლილების დროს. S3-ს ობიექტის ჩაწერის დროის გარდა ცვლილების საკუთარი დრო არ აქვს, ამიტომ rclone ატვირთვისას წყარო ფაილის დროს ობიექტის მეტამონაცემებში (X-Amz-Meta-Mtime) ინახავს და შესადარებლად უკან კითხულობს. ამ მეტამონაცემების წაკითხვა ობიექტზე ერთი HEAD მოთხოვნა ჯდება, რაც დიდ ხეებზე ნელია.

Flag-ები, რომლებიც შედარებას ცვლის:

S3-ზე ატვირთვებისთვის --checksum ჩვეულებრივ საუკეთესო არჩევანია: ის სწრაფია, რადგან ჩამონათვალში ETag ჩვეულებრივი ატვირთვებისთვის MD5-ს შეიცავს, და ზუსტია. რამდენიმე ნაწილად ატვირთული ფაილებისთვის ETag MD5 არ არის; rclone მათი ატვირთვისას ნამდვილ MD5-ს მეტამონაცემებში (X-Amz-Meta-Md5chksum) ინახავს, ასე რომ შედარება მაინც შეუძლია - მაგრამ სხვა ხელსაწყოებით ატვირთულ ობიექტებს ის შეიძლება არ ჰქონდეთ.

--fast-list მთელ bucket-ს ნაკლები მოთხოვნით ჩამოთვლის, ჩამონათვალის შესანახი მეხსიერების ფასად. რამდენიმე მილიონ ობიექტამდე bucket-ებზე ის ჩვეულებრივ უფრო სწრაფია; მცირე მეხსიერების მქონე მანქანაზე და უზარმაზარ bucket-ზე გამორთული დატოვე.

rclone check src dst გადატანის გარეშე ადარებს, ხოლო --one-way მხოლოდ იმას ამოწმებს, რომ წყაროში არსებული ყველაფერი დანიშნულებაზეც არის. გაუშვი პირველი დიდი ატვირთვის შემდეგ და შემდეგ პერიოდულად.

ფილტრები#

rclone-ის ფილტრის წესები წყვეტს, რომელი ფაილები შევიდეს:

# მხოლოდ .tar.gz და .sql.gz ფაილები$ rclone copy /srv/backups renode:my-bucket/backups \    --include "*.tar.gz" --include "*.sql.gz"# ყველაფერი ქეშებისა და ლოგების გარდა, ერთი დალაგებული ფილტრების სიით$ rclone sync /srv/site renode:my-bucket/site --filter-from filters.txt

- cache/**- *.log- node_modules/**+ **

ნუ აურევ --include-სა და --exclude-ს ერთ ბრძანების ხაზზე; rclone-ის დოკუმენტაცია გაფრთხილებს, რომ შედეგის წინასწარ თქმა ძნელია. გამოიყენე --filter ან --filter-from, სადაც ყოველი ხაზი იწყება +-ით ან --ით და პირველი შესაბამისი წესი იმარჯვებს. --max-age 7d გაშვებას ბოლო დროს შეცვლილ ფაილებზე ზღუდავს, ხოლო --min-size და --max-size ზომით ფილტრავს. ნებისმიერი ფილტრი rclone ls --filter-from filters.txt /srv/site-ით გამოსცადე, სანამ sync-ში ენდობი.

სიჩქარე და გამტარუნარიანობის ლიმიტები#

rclone ერთდროულად 4 ფაილს გადაიტანს (--transfers 4), 8 checker-ით, რომლებიც ფაილებს პარალელურად ადარებენ (--checkers 8). ატვირთვის ზღვარზე დიდი ფაილები - ნაგულისხმევად 200 MiB (--s3-upload-cutoff) - multipart ნაწილებად იტვირთება 5 MiB-ით (--s3-chunk-size), თითო ფაილზე ერთდროულად ოთხი ნაწილით (--s3-upload-concurrency).

Multipart ატვირთვების მეხსიერება დაახლოებით ნაწილის ზომაა გამრავლებული ატვირთვის პარალელიზმზე და გადატანების რაოდენობაზე - 64 MiB x 8 x 4 არის 2 GiB, რაც პატარა სერვერისთვის ზედმეტია. ეს მნიშვნელობები მანქანას მოარგე.

--bwlimit ბაიტებშია წამში და არა ბიტებში: --bwlimit 10M არის 10 MiB/s, დაახლოებით 84 Mbit/s. ის იღებს განრიგს, ასე რომ backup-ს შეუძლია დღისით ნელა იაროს და ღამით სრული სიჩქარით იმუშაოს:

$ rclone sync /srv/data renode:my-bucket/current \    --bwlimit "08:00,2M 19:00,8M 23:00,off"

ატვირთვისა და ჩამოტვირთვის ცალკე ლიმიტები ასე იწერება: --bwlimit 4M:off (ატვირთვა 4 MiB/s, ჩამოტვირთვა შეუზღუდავი). თამაშის სერვერისთვის ან ვებ სერვერისთვის, რომელიც არხს backup job-თან იყოფს, დღის ლიმიტი განსხვავებაა backup-ს შორის, რომელსაც ვერავინ ამჩნევს, და backup-ს შორის, რომელიც lag-ს იწვევს.

Bucket-ის მიერთება დისკად#

rclone mount remote-ს ფაილურ სისტემად წარმოადგენს. Linux-ზე მას სჭირდება FUSE (fuse3); Windows-ზე სჭირდება WinFsp და დისკის ასოზე ერთდება; macOS-ზე სჭირდება macFUSE ან FUSE-T.

# Linux$ mkdir -p /mnt/bucket$ rclone mount renode:my-bucket /mnt/bucket --vfs-cache-mode writes --daemon$ fusermount -u /mnt/bucket        # unmount# Windowsrclone mount renode:my-bucket X: --vfs-cache-mode writes

--vfs-cache-mode პარამეტრი წყვეტს, რამდენად ერთგულად იქცევა მიერთებული bucket დისკივით:

• off - წაკითხვა და ჩაწერა პირდაპირ სტრიმდება; ბევრი აპლიკაცია ვარდება, რადგან ჩაწერისას ფაილში გადაადგილება არ შეუძლია.
• writes - ჩასაწერად გახსნილი ფაილები ლოკალურ დისკზე ბუფერდება და დახურვისას იტვირთება. გონივრული ნაგულისხმევი.
• full - წაკითხვებიც ქეშირდება, ასე რომ აპლიკაციებს დიდ ფაილებში თავისუფლად გადაადგილება შეუძლიათ. ლოკალურ დისკს --vfs-cache-max-size-მდე იყენებს.

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

დაშიფვრა crypt-ით#

crypt remote სხვა remote-ს ახვევს და ფაილების შიგთავსს - და სურვილისამებრ სახელებსაც - შენი მანქანიდან გასვლამდე შიფრავს. საცავის პროვაიდერი მხოლოდ შემთხვევითი სახის ობიექტებს ხედავს.

$ rclone config create renode-crypt crypt \    remote=renode:my-bucket/encrypted \    filename_encryption=standard \    directory_name_encryption=true \    password='a-long-passphrase-you-keep-somewhere-safe' \    --obscure

--obscure ეუბნება rclone-ს, რომ პაროლი ღია ტექსტად არის მოცემული და კონფიგურაციის ფაილში ჩაწერამდე უნდა შეინიღბოს. Flag-ის გარეშე rclone გამოიცნობს, და მისი დოკუმენტაცია გაფრთხილებს, რომ გრძელი passphrase, რომელიც მხოლოდ base64 სიმბოლოებისგან შედგება, შეიძლება უკვე შენიღბულად ჩაითვალოს.

ამის შემდეგ renode-crypt: ნებისმიერი სხვა remote-ივით გამოიყენე: rclone copy /srv/backups renode-crypt:backups. ფაილები bucket-ში encrypted/-ის ქვეშ არეული სახელებით ჩნდება.

დაშიფრული ფაილების სახელები ორიგინალებზე გრძელია, და ძალიან გრძელმა სახელებმა ან ღრმა გზებმა შეიძლება key-ის სიგრძის ლიმიტს გადააჭარბოს. filename_encryption = obfuscate უფრო მოკლე სახელებს იძლევა სუსტი დაცვით; off სახელებს წაკითხვადს ტოვებს და მხოლოდ შიგთავსს შიფრავს. Crypt-თან --checksum საზღვარს გავლით აღარ მუშაობს, რადგან შენახული მონაცემები წყაროსგან განსხვავდება; rclone ზომასა და ცვლილების დროზე გადადის. rclone cryptcheck დაშიფრულ remote-ს წყაროსთან ამოწმებს.

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

განრიგით გაშვება#

დაგეგმილი rclone job მოსაწყენი და ხმამაღალი უნდა იყოს: მოსაწყენი, როცა მუშაობს, ხმამაღალი, როცა არა. პატარა wrapper სკრიპტი ორივეს აკეთებს.

#!/bin/shset -euLOG=/var/log/rclone-offsite.log/usr/bin/rclone sync /srv/backups renode:my-bucket/current \    --backup-dir "renode:my-bucket/archive/$(date +%F)" \    --checksum --max-delete 100 \    --bwlimit "08:00,2M 23:00,off" \    --log-file "$LOG" --log-level INFO \  || { echo "offsite sync failed, see $LOG" | mail -s "rclone failed" you@example.com; exit 1; }

30 4 * * * /usr/local/bin/offsite-sync.sh

rclone 0 სტატუსით მხოლოდ მაშინ სრულდება, როცა ყველაფერი გადავიდა. სტატუსი 1 სინტაქსის ან გამოყენების შეცდომაა, 3 ნიშნავს, რომ დირექტორია ვერ მოიძებნა, 4 - ფაილი ვერ მოიძებნა, ხოლო უფრო მაღალი მნიშვნელობები ფარავს ხელახალი ცდების ამოწურვასა და ფატალურ შეცდომებს, ასე რომ არანულოვანი სტატუსი ყოველთვის ყურადღებას იმსახურებს. rclone უკვე იმეორებს ჩავარდნილ ოპერაციებს (ნაგულისხმევად --retries 3) და დაბალი დონის მოთხოვნებს (--low-level-retries 10), ასე რომ ჩავარდნა, რომელიც ამას გადაურჩება, ნამდვილია.

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

FAQ#

rclone თუ AWS CLI?

მხოლოდ S3-ზე ფაილების ატვირთვისა და ჩამოტვირთვისთვის ორივე მუშაობს. rclone-ს აქვს უკეთესი ფილტრები, გამტარუნარიანობის განრიგები, --backup-dir, მიერთება, დაშიფვრა და ათობით სხვა საცავის სისტემის მხარდაჭერა, ასე რომ ერთ ხელსაწყოს შეუძლია S3-სა და ნებისმიერ სხვა რამეს შორის კოპირება. AWS CLI საცნობარო იმპლემენტაციაა და უკეთესი ხელსაწყო დაბალი დონის S3 ოპერაციებისთვის; მას ფარავს AWS CLI-ის გამოყენება S3 საცავთან.

რატომ ცდილობს rclone ჩემი bucket-ის შექმნას?

ნაგულისხმევად ის ატვირთვამდე ამოწმებს, არსებობს თუ არა დანიშნულების bucket, და თუ არ არსებობს, ქმნის მას. თუ შენს key-ებს bucket-ების შექმნის უფლება არ აქვს, ეს ვარდება. no_check_bucket = true remote-ში ან --s3-no-check-bucket ბრძანების ხაზზე ამ შემოწმებას გამოტოვებს.

შეუძლია rclone-ს ორ S3 პროვაიდერს შორის პირდაპირ კოპირება?

კი: rclone copy renode:my-bucket other:their-bucket. ერთი remote-ის შიგნით rclone სერვერის მხარის კოპირებას იყენებს; სხვადასხვა პროვაიდერს შორის კი მონაცემებს იმ მანქანის გავლით სტრიმავს, რომელზეც rclone მუშაობს, ამიტომ გაუშვი ის სადმე, სადაც ორივესთან კარგი კავშირია.

rclone sync backup არის?

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

როგორ გავუშვა rclone განრიგით?

Cron-იდან ან systemd timer-იდან, --log-file-ით და --log-level INFO-თი, და არანულოვან სტატუსზე გაფრთხილება დააყენე. დაგეგმილ sync-ებზე --max-delete შეინარჩუნე. Backup job-ის თანმიმდევრობას იმ რამეებთან, რაზეც ის დამოკიდებულია, ფარავს გეგმიური ამოცანები, რომლებიც ღირს.