Rclone: Remotes, datasammenligning og VFS-drift

Rclone er et åpen kildekode-verktøy for dataflytting for lokale filsystemer, nettverksprotokoller, skylagringsstasjoner og objektlagring. Rclone-prosjektsiden beskriver det som et kommandolinjeprogram for å administrere filer på skylagring. Det gir disse systemene et felles grensesnitt for listing, kopiering, synkronisering, verifisering, mount, kryptering og tjenestetilgang. Denne ensartetheten er nyttig, men må ikke forveksles med ensartet lagringssemantikk: Hashes, endringstider, store/små bokstaver, tomme kataloger, metadata, kopier på serversiden og konsistens varierer mellom backender.

For administratorer er rclone ikke en «skyutforsker», men en datapipeline. Korrektheten avhenger av kilde og mål, retning, sammenligningskriterium, filtermengde, slettingsregel, retrytilstand, credentials, backendfunksjoner og endelig verifisering. En prosess kan ha overført 100 prosent av bytene og likevel være faglig feil dersom den bruker feil navneområde, en utdatert listingvisning eller en ufullstendig filtermengde.

Forklaringen følger en rclone-kommando fra kilde og remote via sammenligning, checkers og transfers til backenden. Filtre, Crypt, VFS, automatisering, sikkerhet og verifisering forklares deretter langs samme jobbvei.

Rclone oversetter en enhetlig fil- og katalogmodell til API-ene for svært ulike lagringstjenester. Artikkelen starter derfor med remote og backendfunksjoner, behandler deretter kopieringssemantikk og verifisering og avslutter med mount, sikkerhet og recovery.

Arkitektur: Kommando, filsystemmodell og backend

Programmet, som er skrevet i Go, kobler sammen flere lag:

1. Kommando og jobbdefinisjon: copy, sync, move, check, bisync, mount, serve eller et RC-kall definerer retning og operasjon.
2. Filtre og sammenligning: Stiregler, størrelse, endringstid, hash, metadata og flagg bestemmer objektmengden som vurderes, og hva som er likt.
3. Overføringsmotor: Listere, checkers og overføringsarbeidere planlegger operasjoner, begrenser parallellitet og samler feil.
4. Fs/Object-grensesnittmodell: Rclone modellerer kataloger, objekter og valgfrie backendfunksjoner gjennom felles Go-grensesnitt.
5. Backendadaptere: S3, SFTP, WebDAV, Drive, OneDrive, lokale filsystemer og andre tjenester oversetter kontrakten til sine API-er.
6. Transport og leverandør: HTTP/TLS, SSH/SFTP eller lokal I/O møter rate limits, konsistens, versjonering og leverandørpolicy.

Den offisielle backendoversikten viser eksplisitt hvilke systemer som støtter hasher, ModTime, navn som ikke skiller mellom store og små bokstaver, duplikater, MIME-typer og metadata (Overview of cloud storage systems). Kildetreet skiller mellom backender, kommandoer og den felles fs-grensesnittmodellen; offisielle builds pakker de valgte adapterne i én binærfil (rclone source repository, Install from source).

Remote-syntaks og navneområde

En konfigurert remote adresseres som name:pfad. Kolonet skiller remote-navnet fra stien; en lokal sti uten remote-prefiks bruker Local-backenden. Connection strings som :sftp,host=example.net:/data kan instansiere en backend uten lagret remote-navn. Denne fleksibiliteten øker samtidig risikoen for at en skrivefeil angir en lokal i stedet for ekstern sti (Rclone documentation – remotes).

Ved katalogkommandoer overfører Rclone innholdet i kildestien, ikke automatisk navnet på kildekatalogen. Semantikken tilsvarer den avsluttende skråstreken man kjenner fra rsync. Kilde, mål og forventet målstruktur dokumenteres derfor som konkrete eksempler i runbooken (rclone copy).

rclone version
rclone config file
rclone listremotes --long
rclone backend features archive:
rclone about archive:

rclone version
rclone config file
rclone listremotes --long
rclone backend features archive:
rclone about archive:

rclone version identifiserer binærfil, operativsystem og build; rclone config file viser konfigurasjonen som faktisk er lastet; rclone listremotes inventariserer remotes; rclone backend features leverer funksjonene til den oppløste backenden; rclone about spør etter kapasitetsinformasjon dersom tjenesten tilbyr den.

Backendfunksjoner og synlige forskjeller

Det felles grensesnittet kan bare bruke funksjoner som backenden eller en wrapper tilbyr. Viktige forskjeller er:

Supportnivåene vurderer backender basert på tester og funksjoner, ikke et generelt funksjonsløfte (Backend Support Tiers). Leverandør- og backenddokumentasjon er derfor del av jobbdefinisjonen. En S3-kompatibel tjeneste kan ha andre grenser for multipart, hash eller Server-Side Copy enn en annen S3-leverandør.

Konfigurasjon, credentials og oppløsningsrekkefølge

rclone.conf lagrer remote-definisjoner og ofte OAuth-tokener eller tilgangsdata. «Obscured» passordfelt er ikke sikker kryptering. Hele konfigurasjonen kan krypteres med et passord; for ubetjente jobber kan en ekstern Password Command levere hemmeligheten fra en Secret Store (Configuration encryption, rclone config encryption).

Rclone kan hente backendalternativer fra kommandolinjen, remote-spesifikke miljøvariabler, backendomfattende variabler og konfigurasjonsfilen. Prioritetsrekkefølgen må dokumenteres for tjenester og containere, fordi en arvet variabel kan overskrive den forventede rclone.conf (Environment variables). Debuglogger viser oppløste alternativer, men kan inneholde sensitive endepunkter eller stier.

Administratorer beskytter minst:

• rclone.conf og filrettighetene for denne;
• konfigurasjonspassord eller Password Command;
• OAuth-refresh-tokener, Client Secrets, Access Keys og SSH Private Keys;
• Crypt-passord og valgfritt salt;
• rettigheter for tjenestekonto, bucket og mappe;
• filter- og jobbdefinisjoner som del av change control.

En konfigurasjonsbackup uten dekrypteringshemmeligheten er ikke testet recovery. Omvendt må en kryptert konfigurasjon med svakt passord ikke lagres offentlig.

Når remote, navneområde og tilgangsdata er avklart, bestemmer den valgte kommandoen datavirkningen. Særlig sync er ikke en ufarlig kopi, men håndhever én side som ønsket sannhet.

Copy, Sync og Move: Retning er policy

rclone copy kopierer nye eller forskjellige filer til målet og sletter ingen ekstra objekter der. rclone sync gjør målet til et bilde av kilden og kan slette målobjekter for å oppnå dette. rclone move kopierer eller flytter og fjerner først kilden etter en vellykket filoperasjon.

Disse kommandoene er ikke utbyttbare:

rclone sync 'D:\Export' 'archive:current' `
  --dry-run --check-first --backup-dir 'archive:history/prechange' `
  --combined '.\sync-plan.txt' --log-level INFO --log-file '.\sync-dry-run.log'
if ($LASTEXITCODE -ne 0) { throw "rclone dry-run failed: $LASTEXITCODE" }
Get-Content '.\sync-plan.txt' | Group-Object { $_[0] } | Select-Object Name,Count

rclone sync /srv/export archive:current \
  --dry-run --check-first --backup-dir archive:history/prechange \
  --combined ./sync-plan.txt --log-level INFO --log-file ./sync-dry-run.log
test "$?" -eq 0 || exit "$?"
cut -c1 ./sync-plan.txt | sort | uniq -c

--dry-run hindrer endringer, men beviser bare listingene og alternativene som var synlige ved testtidspunktet. --check-first skiller sammenlignings- og overføringsfasen. --backup-dir flytter overskrevne eller slettede målobjekter til en separat sti, dersom backenden støtter den nødvendige serveroperasjonen (Global options – backup-dir and retries). Combined Report klassifiserer like, manglende, ulike og feilaktige stier.

Hva betyr «identisk»?

Rclone hopper som standard over filer på grunnlag av størrelse og endringstid, eller bruker en felles hash når kommando og backend tillater det. Det nøyaktige fingeravtrykket avhenger av funksjoner og flagg. --checksum, --size-only, --ignore-times, --update, --ignore-size, metadataalternativer og ModTime-presisjon endrer beslutningen (Overview – Hash and ModTime).

En ETag på leverandørsiden er ikke universelt en innholds-MD5. Multipart-opplasting, kryptering eller leverandørimplementasjon kan endre dens betydning. Rclone bruker hashfunksjonen som backenden eksplisitt erklærer, ikke en generell ETag-antakelse.

Mellom Linux som skiller store og små bokstaver og vanligvis Windows som ikke gjør det, kan report.pdf og Report.pdf ikke avbildes uten tap. Skylagringsstasjoner kan tillate dupliserte navn eller egne objekt-ID-er. En forhåndskontroll av navnekollisjoner og ugyldige tegn er derfor del av enhver migrering.

Overføringsmotor, parallellitet og Pacer

Overføringsmotoren lister kilde og mål, sammenligner oppføringer, planlegger kontroller og overføringer og utfører backendoperasjoner parallelt. --checkers styrer parallelle kontroller, --transfers styrer overføringene. --fast-list kan redusere API-kall, men trenger mer minne fordi store listings samles (Rclone documentation – performance options).

Parallellitet er ikke bare et hastighetsalternativ. Flere arbeidere øker åpne filer, minne, API-forespørsler, multiparttilstander og belastningen på leverandøren. For små objekter dominerer listing-/forespørselslatens, for store objekter båndbredde og multipartkonfigurasjon. Sky-til-sky-kopier kan forbli på serversiden eller gå via rclone-verten; dette kontrolleres i loggen og backendfunksjonene.

Backender implementerer pacing for API-rate limits. Low-Level-Retries håndterer enkeltforespørsler; High-Level-Retries gjentar en mislykket totaloperasjon. Først sluttstatus avgjør om tidligere feil ble kompensert (Retries). En scheduler vurderer prosessens exitkode og ikke forekomsten av ordet ERROR et sted i loggen.

Filtre definerer datamengden

Include-, Exclude-, Size-, Age- og Files-from-regler bestemmer hvilke stier som er synlige. Filtre gjelder den angitte roten; en shellglob i kildestien erstatter ikke en rclone-filterregel. Rekkefølgen på Include og Exclude kan være relevant (Rclone Filtering).

Når et filter endres, endres den faglige datamengden. Ved sync kan tidligere synlige objekter fremstå som slettet; --delete-excluded er særlig farlig. Filterfiler versjoneres, hashes og godkjennes sammen med Dry-Run-rapport og jobbdefinisjon. En sikker test bruker rclone ls eller lsf med de samme reglene før en skrivende kommando følger.

En exitkode uten overføringsfeil beviser bare kjøringen, ikke fullstendig likhet mellom begge bestandene. check sammenligner kilder og mål med funksjonene til den aktuelle backenden.

Verifisering: Check i stedet for overføringsteller

rclone check endrer ingen data. Den sammenligner størrelse og felles hasher, kan lage rapporter for treff, forskjeller og manglende stier og med --download lese innhold når ingen felles remote-hash finnes. For Crypt finnes rclone cryptcheck, som egnet sammenligner klartekstkilde og kryptert mål.

rclone check 'D:\Export' 'archive:current' `
  --combined '.\check-report.txt' --checkers 8 `
  --log-level INFO --log-file '.\check.log'
$code = $LASTEXITCODE
Get-Content '.\check-report.txt' | Group-Object { $_[0] } | Select-Object Name,Count
if ($code -ne 0) { throw "Integrity check failed: $code" }

rclone check /srv/export archive:current \
  --combined ./check-report.txt --checkers 8 \
  --log-level INFO --log-file ./check.log
code=$?
cut -c1 ./check-report.txt | sort | uniq -c
test "$code" -eq 0 || exit "$code"

En hashsammenligning beviser likhet for algoritmen og navneområdet som brukes. Den beviser ikke automatisk ACL-er, retention, leverandørens objektversjoner, katalogmetadata eller faglig lesbarhet. For kritiske arkiver supplerer en restoretest den tekniske kontrollen.

Crypt: Data- og navnekryptering

Crypt er en wrapperbackend over en annen remote. Filinnhold krypteres med NaCl SecretBox basert på XSalsa20 og Poly1305; filnavn og katalognavn transformeres som standard også (Crypt backend). Leverandøren ser ciphertext, størrelsesmønstre, tilgangstider og antall objekter; Crypt er derfor innholds- og navnebeskyttelse, ikke fullstendig trafikk- eller metadataanonymisering.

Passord og valgfritt salt lagres bare «obscured» i konfigurasjonen, med mindre hele konfigurasjonen er kryptert. Tap av begge recoveryopplysningene gjør dataene uleselige. Før rotasjon eller endring av navnekrypteringen testes en andre, lesende remote mot de samme dataene.

Crypt endrer størrelser og hashmuligheter. En vanlig check mellom klartekst og ciphertext kan derfor ikke uten videre forvente samme leverandørhash. cryptcheck eller en kontrollert nedlastingssti er riktig kontrollnivå.

Kopieringskommandoer arbeider eksplisitt med objekter. Et VFS-mount må derimot gjenskape løpende filsystemoperasjoner fra dette og trenger derfor cache, skrivemodus og klare konsistensforutsetninger.

VFS-mount: Objektlagring er ikke et POSIX-filsystem

rclone mount presenterer en remote som et filsystem via FUSE eller WinFsp. VFS-laget oversetter filoperasjoner til objektoperasjoner. Ettersom skyobjekter normalt ikke kan endres i midten eller utvides vilkårlig, bufferlagrer eller erstatter Rclone objekter.

Fire cachemoduser representerer ulike kontrakter:

Directory Cache holder navn og metadata i minnet. Eksterne endringer vises først via polling eller etter utløp eller flush. Buffer gjelder per åpen fil; maksimalt minnebehov øker med buffer-size × open files. To prosesser må ikke bruke samme overlappende VFS-cache med aktiv File Caching, fordi dette kan ødelegge data (VFS file caching).

rclone mount crypt-archive: X: `
  --vfs-cache-mode writes --cache-dir 'D:\rclone-cache\archive' `
  --vfs-cache-max-size 100G --vfs-cache-min-free-space 20G `
  --log-file 'D:\Logs\rclone-mount.log' --log-level INFO

rclone mount crypt-archive: /mnt/archive \
  --vfs-cache-mode writes --cache-dir /var/cache/rclone/archive \
  --vfs-cache-max-size 100G --vfs-cache-min-free-space 20G \
  --log-file /var/log/rclone-mount.log --log-level INFO

På Windows leverer WinFsp filsystembroen; på Linux og andre Unix-systemer bruker Rclone FUSE. En tjeneste venter på nettverk, konfigurasjon og mountberedskap, har en kontrollert unmount-sti og overvåker lokalt cachevolum. Container-mounts krever ytterligere device- og mount-propagation-rettigheter og utvider privilegieflaten (Rclone mount in Docker).

Bisync: To sannhetskilder

rclone bisync oppdager endringer på begge sider ved hjelp av lagrede listings og overfører deltaer toveis. Dette oppretter vedvarende jobbtilstand utenfor brukerdataene. En tapt eller inkonsistent arbeidskatalog kan kreve en resync-fase.

Bisync har sikkerhetskontroller for tilgjengelighet og uvanlig mange slettinger. Filterendringer endrer den synlige datamengden og tvinger bevisst frem en resync. Dersom applikasjoner endrer innhold uten å endre størrelse og ModTime, kan standarddetektering svikte. Toveis synkronisering brukes derfor bare når konfliktpolicy, klokke-/timestampatferd, Access Checks, Max-Delete, backup av arbeidsfiler og menneskelig løsning er dokumentert.

Bisync er ikke et multi-master-filsystem med distribuert låsing. Samtidige redigeringer, omdøpinger og offlinefaser forblir faglige konflikter.

Remote Control API, Metrics og Serve-moduser

Med --rc eller rclone rcd åpner Rclone et HTTP-API. Det kan starte jobber, konfigurere remotes, lese eller skrive lokale filer og under visse omstendigheter utføre OS-kommandoer i konteksten til rclone-brukeren. Dokumentasjonen vurderer derfor tilgang til RC som ekvivalent med shelltilgang (Remote Control / API).

RC lytter som standard lokalt. Ved nettverksdeling kreves sterk autentisering, TLS eller en beskyttet reverse proxy, brannmurallowlist og minimale prosessrettigheter. --rc-no-auth hører ikke hjemme på et tilgjengelig grensesnitt. OpenMetrics-endepunktet kan eksponere overførings- og jobbmetrikker; også her kan remote-navn og stier være sensitive metadata.

rclone rc core/version
rclone rc core/stats
$metrics = Invoke-WebRequest 'http://127.0.0.1:5572/metrics'
$metrics.StatusCode
$metrics.Content | Select-String 'rclone_' | Select-Object -First 20

rclone rc core/version
rclone rc core/stats
curl --silent --show-error --fail http://127.0.0.1:5572/metrics | grep '^rclone_' | head -n 20

Invoke-WebRequest og curl kontrollerer det lokale HTTP-endepunktet. rclone rc bruker samme API og overtar autentiseringsparametere fra jobbkonfigurasjonen.

Rclone kan dessuten tilby remotes via HTTP, WebDAV, SFTP, FTP, NFS, DLNA eller S3-kompatible Serve-moduser. Systemrollen skifter da fra klient til server. Lytteradresse, autentisering, protokollsikkerhet, VFS-cache og datarettigheter herdes deretter som for en selvstendig tjeneste (Rclone serve).

Logging, statistikk og exitkoder

Logger skiller mellom DEBUG, INFO, NOTICE og ERROR. JSON-logging er tilgjengelig for maskinbehandling. Statistikk viser checks, transfers, feil, byte, hastighet og ETA. En kortvarig Transferred-teller er ikke et varig revisjonsbevis; en jobb lagrer starttid, kilde-/målrot, filterhash, Rclone-build, oppløste ikke-sensitive alternativer, sluttstatistikk og exitkode.

De dokumenterte exitkodene skiller mellom suksess, syntaksfeil, manglende stier, midlertidige, mindre alvorlige og fatale feil samt nådde overførings- eller tidsgrenser (List of exit codes). --error-on-no-transfer kan signalisere en vellykket kjøring uten overføring separat. Schedulere og overvåking behandler kodene etter jobbtype; en forventet tom inkrementell jobb vurderes annerledes enn en uteblitt daglig eksport.

En High-Level-Retry kan løse tidlige feilmeldinger. Omvendt kan en prosess overføre mye og til slutt ende nonzero på grunn av få uløste objekter. Det alarmeres på sluttstatus, feilantall, oppbrukte retries, jobbvarighet, manglende heartbeat og verifiseringsresultat.

Sikkerhet i datastien

Rclone arver rettighetene til prosesskontoen og remote-credentials. En sync med sletterettigheter er en høyt privilegert sletteagent. Least Privilege skiller mellom lesende kilde, skrivende mål, versjonerings-/retentionrettigheter og administrative buckethandlinger.

TLS-sertifikatkontroll forblir aktiv. --no-check-certificate deaktiverer kontroll av kjede og vertsnavn og er ifølge dokumentasjonen kun beregnet for testing (TLS options). SFTP-backender kontrollerer Host Keys med en vedlikeholdt Known-Hosts- eller fingerprintpolicy; API-endepunkter omdirigeres ikke av ukontrollerte proxier.

Filtre, --backup-dir, objektversjonering og Object Lock begrenser ulike risikoer. En backupkatalog i samme konto beskytter ikke mot kontokompromittering eller sletting hos leverandøren. Storage, Kryptering og Herding behandler de underliggende kontrollflatene.

Diagnosen skiller mellom lokal sti, Rclone-filter, backend-API, autentisering, rate limit og nettverksvei. Bare slik blir det synlig om en fil aldri ble valgt, ikke ble overført eller ble fremstilt annerledes av målet.

Nettverks- og backenddiagnose

En rclone-feilmelding kan stamme fra navneoppløsning, TCP, TLS, proxy, leverandørautentisering, API-rate limit, backendoversettelse, lokalt filsystem eller sammenligningslogikk. Diagnosen følger stien:

1. Bekreft binærfil, konfigurasjonssti og oppløst remote-navn.
2. Kontroller DNS, port og TLS for det konkrete endepunktet.
3. Bruk rclone lsd eller lsjson som en minimal lesende backendtest.
4. Registrer forespørsels-/retryfase og backendfunksjoner med -vv, uten å publisere hemmeligheter.
5. Kontroller kilde/mål, filtre og fingeravtrykksbeslutning.
6. Korreler sluttstatus, exitkode og leverandørens revisjonslogg.

Resolve-DnsName $env:RCLONE_ENDPOINT
Test-NetConnection $env:RCLONE_ENDPOINT -Port 443
rclone lsd archive: -vv --dump headers --log-file '.\rclone-debug.log'
rclone lsjson archive:health --max-depth 1 --metadata

dig +short "$RCLONE_ENDPOINT"
nc -vz "$RCLONE_ENDPOINT" 443
openssl s_client -connect "$RCLONE_ENDPOINT:443" -servername "$RCLONE_ENDPOINT" -brief </dev/null
rclone lsd archive: -vv --dump headers --log-file ./rclone-debug.log
rclone lsjson archive:health --max-depth 1 --metadata

Resolve-DnsName, Test-NetConnection, dig, nc, openssl s_client, rclone lsd og rclone lsjson skiller transport, autentisering, listing og objektsynlighet. Headerdumper kontrolleres for tokener, signaturer, cookies og stier før de deles. DNS, TCP, TLS og Feilsøking utdyper fasene.

Typiske feilbilder

Rclone rapporterer ofte trinnet der en jobb synlig feiler, ikke nødvendigvis den opprinnelige årsaken. Tabellen kobler derfor symptom, sannsynlig utløsende faktor og beviset som bekrefter eller avkrefter antakelsen.

Backup, recovery og reconciliation

Rclone er ofte del av en backup, men er i seg selv ikke en uforanderlig backupmodell. sync replikerer slettinger og krypteringsskade. copy bevarer ekstra målobjekter, men kan overskrive eksisterende versjoner. Beskyttelse oppstår gjennom målversjonering, Retention/Object Lock, separate credentials, --backup-dir, uforanderlige snapshots og restoretester.

Følgende inngår i recoverysettet:

• godkjent rclone-binærfil eller verifiserbart releaseartefakt;
• kryptert rclone.conf pluss separat dekrypteringshemmelighet;
• leverandørcredentials og gjenanskaffelse av dem;
• Crypt-passord og salt;
• jobb-, filter- og miljødefinisjoner;
• Bisync-arbeidsfiler;
• ikke-opplastede VFS-cacheobjekter og deres tilordning;
• Dry-Run-, Combined-, Check- og exitkoderapporter;
• målets prosedyrer for versjonering, retention og restore.

En restore utføres til en separat sti og kontrolleres deretter med hash, antall, størrelse, metadatastikkprøve og applikasjonstest. Reconciliation sammenligner Source of Truth, målversjoner, VFS-Writeback og schedulertilstand. Backup og Disaster Recovery beskriver RPO/RTO og overordnet akseptanse.

Teknisk historie

Nick Craig-Wood startet prosjektet med en første commit i november 2012. Grunnleggeren dokumenterte denne opprinnelsen ved fjortenårsjubileet og lenket til den første kildetilstanden (Happy 14th Birthday rclone, initial commit).

Rclone tok i bruk den velkjente retningssyntaksen fra rsync, men erstattet dets blokkbasserte deltaforutsetninger med objekt- og leverandøroperasjoner. Skylagring tilbyr normalt ikke et servergrensesnitt for rsync Rolling Checksum; Rclone sammenligner hele objekter med tilgjengelige fingeravtrykk og overfører dem tilsvarende.

Med et voksende antall backender utviklet den sentrale Fs/Object-grensesnittmodellen seg, med valgfrie funksjoner. Crypt la til kryptering på klientsiden; Mount og VFS gjorde objektlagring tilgjengelig for filbaserte applikasjoner; Remote Control API ble kraftig utvidet i 2018; Bisync la til vedvarende toveis avstemming. Changelog dokumenterer denne utviklingen og sikkerhetsrelevante rettelser. For drift er den derfor det tidsavhengige supplementet til denne arkitekturartikkelen.

Den tekniske linjen forblir konsistent: én portabel Go-binærfil, mange innebygde backender, felles kommandoer og eksplisitt synlige leverandørforskjeller. Nettopp disse forskjellene gjør Rclone kraftig for administratorer og samtidig revisjonskrevende.

Administrator-sjekkliste

Før en produksjonsjobb må minst følgende punkter være dokumentert:

• Binærfilopprinnelse, konfigurasjonssti og remote-oppløsning er entydige.
• Kilde, mål, retning og forventet målstruktur står i runbooken.
• Backendfunksjoner for hash, ModTime, Case, Metadata, Copy/Move og Listing er kontrollert.
• Filterfil og jobbparametere er versjonert; Dry Run og Combined Report er godkjent.
• Delete-, Max-Delete-, Backup-Dir-, versjonerings- og retentionpolicy passer sammen.
• Credentials har bare nødvendige rettigheter; Config, Crypt-passord og salt kan gjenopprettes.
• Transfers, Checkers, Pacer og båndbredde respekterer vert og leverandør.
• VFS-cache har eget volum, kapasitetsalarm, kontrollert stopp og Writeback-kontroll.
• RC/Serve lytter bare kontrollert og er beskyttet som shelltilgang.
• Suksess bevises med sluttstatus, exitkode, Check-rapport og restoretest.

Kilder

• Rclone
• Overview of cloud storage systems
• rclone source repository
• Install from source
• Rclone documentation – remotes
• rclone copy
• rclone version
• rclone config file
• rclone listremotes
• rclone backend features
• rclone about
• Backend Support Tiers
• rclone config encryption
• rclone sync
• rclone move
• Rclone Filtering
• rclone check
• rclone cryptcheck
• Crypt backend
• rclone mount
• WinFsp documentation
• Rclone mount in Docker
• rclone bisync
• rclone rcd
• Remote Control / API
• Invoke-WebRequest
• curl manual
• rclone rc
• Rclone serve
• Resolve-DnsName
• Test-NetConnection
• dig manual
• nc(1)
• openssl-s_client(1)
• rclone lsd
• rclone lsjson
• Happy 14th Birthday rclone
• Initial rclone commit
• Rclone Changelog