Rclone: fjärrlagringar, datajämförelse och VFS-drift

Rclone är ett verktyg med öppen källkod för dataförflyttning för lokala filsystem, nätverksprotokoll, molnlagringar och objektlagring. Rclone-projektsidan beskriver det som ett kommandoradsprogram för hantering av filer på molnlagringar. Det ger dessa system ett gemensamt gränssnitt för listning, kopiering, synkronisering, verifiering, mount, kryptering och tjänsteåtkomst. Denna enhetlighet är användbar, men får inte förväxlas med enhetlig lagringssemantik: hashar, ändringstider, versal-/gemenkänslighet, tomma kataloger, metadata, serverbaserade kopior och konsistens skiljer sig mellan backends.

För administratörer är rclone inte en ”molnutforskare”, utan en datapipeline. Dess korrekthet beror på källa och mål, riktning, jämförelsekriterium, filteruppsättning, raderingsregel, retry-tillstånd, autentiseringsuppgifter, backendfunktioner och avslutande verifiering. En process kan ha överfört 100 procent av bytena och ändå vara sakligt felaktig om den använder fel namnrymd, en inaktuell listningsvy eller en ofullständig filteruppsättning.

Förklaringen följer ett rclone-kommando från källa och fjärrlagring via jämförelse, checker och transfers till backend. Filter, Crypt, VFS, automatisering, säkerhet och verifiering förklaras därefter längs samma jobbflöde.

Rclone översätter en enhetlig fil- och katalogmodell till API:erna hos mycket olika lagringstjänster. Artikeln börjar därför med fjärrlagring och backendfunktioner, behandlar sedan kopieringssemantik och verifiering och avslutar med mount, säkerhet och återställning.

Arkitektur: kommando, filsystemmodell och backend

Programmet, som är skrivet i Go, kopplar samman flera lager:

  1. Kommando och jobbdefinition: copy, sync, move, check, bisync, mount, serve eller ett RC-anrop definierar riktning och operation.
  2. Filter och jämförelse: sökvägsregler, storlek, ändringstid, hash, metadata och flaggor avgör den betraktade objektmängden och likheten.
  3. Överföringsmotor: lister, checker och transferworkers planerar operationer, begränsar parallellitet och samlar fel.
  4. Fs/Object-gränssnittsmodell: Rclone modellerar kataloger, objekt och valfria backendfunktioner via gemensamma Go-gränssnitt.
  5. Backendadaptrar: S3, SFTP, WebDAV, Drive, OneDrive, lokala filsystem och andra tjänster översätter kontraktet till sina API:er.
  6. Transport och leverantör: HTTP/TLS, SSH/SFTP eller lokal I/O möter rate limits, konsistens, versionshantering och leverantörspolicy.

Den officiella backendöversikten visar uttryckligen vilka system som stöder hashar, ModTime, skiftlägesokänsliga namn, dubbletter, MIME-typer och metadata (Overview of cloud storage systems). Källträdet separerar backends, kommandon och den gemensamma fs-gränssnittsmodellen; officiella byggen paketerar de valda adaptrarna i en binärfil (rclone source repository, Install from source).

Syntax för fjärrlagring och namnrymd

En konfigurerad fjärrlagring adresseras som name:pfad. Kolonet skiljer fjärrlagringsnamnet från sökvägen; en lokal sökväg utan fjärrprefix använder Local-backenden. Anslutningssträngar som :sftp,host=example.net:/data kan instansiera en backend utan ett sparat fjärrlagringsnamn. Denna flexibilitet ökar samtidigt risken att ett skrivfel betecknar en lokal i stället för en fjärrsökväg (Rclone documentation – remotes).

Vid katalogkommandon överför Rclone innehållet i källsökvägen, inte automatiskt namnet på källkatalogen. Semantiken motsvarar det avslutande snedstreck som är välbekant från rsync. Källa, mål och förväntat målträd dokumenteras därför som konkreta exempel i runbooken (rclone copy).

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

rclone version identifierar binärfil, operativsystem och bygge; rclone config file visar den faktiskt laddade konfigurationen; rclone listremotes inventerar fjärrlagringar; rclone backend features ger funktionerna för den upplösta backenden; rclone about hämtar kapacitetsinformation, om tjänsten tillhandahåller den.

Backendfunktioner och genomlysande skillnader

Det gemensamma gränssnittet kan bara använda funktioner som backenden eller en wrapper tillhandahåller. Viktiga skillnader är:

FunktionBetydelseEffekt vid frånvaro eller avvikelse
gemensam hashleverantörsspecifikt innehållsfingeravtryckjämförelsen faller tillbaka på storlek/ModTime eller nedladdning
skrivbar ModTimekälltiden kan anges utan ny uppladdningidentiskt innehåll kan överföras igen
serverbaserad Copy/Movedata stannar hos leverantörenannars nedladdning/uppladdning eller Copy plus Delete
ListR/Fast Listrekursiv listning med färre anropfler API-förfrågningar eller mer klientminne
Change Pollingsignalerar externa ändringarVFS ser ändringar först efter att cachen löpt ut
tomma katalogerverkligt katalogobjekt/markörtomma mappar försvinner i bucketmodeller
Case SensitivityA och a kan särskiljasoändlig synkronisering eller namnkonflikt vid målet
Duplicate Namesflera objekt med samma namnsökvägen är ingen entydig identifierare
Metadata/MIMEextra attribut kan läsas/skrivasACL:er eller verksamhetsmetadata följer inte automatiskt

Supportnivåerna bedömer backends utifrån tester och funktioner, inte ett generellt funktionslöfte (Backend Support Tiers). Leverantörs- och backenddokumentation är därför del av jobbdefinitionen. En S3-kompatibel tjänst kan ha andra gränser för multipart, hash eller Server-Side Copy än en annan S3-leverantör.

Konfiguration, autentiseringsuppgifter och upplösningsordning

rclone.conf lagrar definitioner av fjärrlagringar och ofta OAuth-token eller åtkomstuppgifter. ”Obscured” lösenordsfält är ingen säker kryptering. Hela konfigurationen kan krypteras med ett lösenord; för obevakade jobb kan ett externt Password Command leverera hemligheten från en Secret Store (Configuration encryption, rclone config encryption).

Rclone kan hämta backendalternativ från kommandoraden, fjärrspecifika miljövariabler, backendövergripande variabler och konfigurationsfilen. Prioritetsordningen måste dokumenteras för tjänster och containrar, eftersom en ärvd variabel kan skriva över den förväntade rclone.conf (Environment variables). Debugloggar visar upplösta alternativ, men kan innehålla känsliga slutpunkter eller sökvägar.

Administratörer skyddar minst:

  • rclone.conf och dess filbehörigheter;
  • konfigurationslösenordet respektive Password Command;
  • OAuth-refresh-token, Client Secrets, Access Keys och SSH Private Keys;
  • Crypt-lösenord och valfritt salt;
  • behörigheter för tjänstekonto, bucket och mapp;
  • filter- och jobbdefinitioner som del av Change Control.

En konfigurationsbackup utan dekrypteringshemlighet är ingen testad återställning. Omvänt får en krypterad konfiguration med svagt lösenord inte lagras offentligt.

När fjärrlagring, namnrymd och åtkomstuppgifter har klargjorts avgör det valda kommandot dataeffekten. Särskilt sync är ingen ofarlig kopiering, utan genomdriver ena sidan som önskad sanning.

Copy, Sync och Move: riktning är policy

rclone copy kopierar nya eller olika filer till målet och raderar inga extra objekt där. rclone sync gör målet till en avbild av källan och kan då radera målobjekt. rclone move kopierar respektive flyttar och tar bort källan först efter en lyckad filoperation.

Dessa kommandon är inte utbytbara:

OperationSkriver över målRaderar extra målobjektRaderar källaTypisk användning
copyför objekt som bedömts vara olikanejnejimport, seed, additiv replikering
syncjajanejauktoritativ enkelriktad spegling
movejanejefter lyckad överföringinmatning, arkivöverlämning
copyto/movetoenskilt objekt med explicit målnamnnejendast movetoatomisk operation för enskild fil
bisyncpå båda sidorberoende på fastställt deltamöjligt på båda sidorkontrollerad dubbelriktad replikering
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

--dry-run förhindrar ändringar, men bevisar endast de listningar och alternativ som var synliga vid testtillfället. --check-first separerar jämförelse- och överföringsfasen. --backup-dir flyttar överskrivna eller raderade målobjekt till en separat sökväg, förutsatt att backenden stöder den nödvändiga serverbaserade operationen (Global options – backup-dir and retries). Combined Report klassificerar lika, saknade, olika och felaktiga sökvägar.

Vad betyder ”identisk”?

Rclone hoppar som standard över filer baserat på storlek och ändringstid eller använder en gemensam hash när kommando och backend tillåter det. Det exakta fingeravtrycket beror på funktioner och flaggor. --checksum, --size-only, --ignore-times, --update, --ignore-size, metadataalternativ och ModTime-precision ändrar beslutet (Overview – Hash and ModTime).

En leverantörsspecifik ETag är inte universellt en innehålls-MD5. Multipartuppladdning, kryptering eller leverantörsimplementering kan förändra dess betydelse. Rclone använder den hashfunktion som backenden uttryckligen deklarerar, inte ett generellt ETag-antagande.

Mellan skiftlägeskänsligt Linux och normalt skiftlägesokänsligt Windows kan report.pdf och Report.pdf inte mappas utan förlust. Molnlagringar kan tillåta dubbla namn eller egna objekt-ID:n. En förkontroll av namnkonflikter och otillåtna tecken är därför del av varje migrering.

Överföringsmotor, parallellitet och Pacer

Överföringsmotorn listar källa och mål, jämför poster, planerar kontroller och överföringar samt kör backendoperationer parallellt. --checkers styr parallella kontroller, --transfers överföringarna. --fast-list kan minska API-anrop, men kräver mer minne eftersom stora listningar samlas in (Rclone documentation – performance options).

Parallellitet är inte enbart ett hastighetsalternativ. Fler workers ökar öppna filer, minne, API-förfrågningar, multiparttillstånd och belastning på leverantören. För små objekt dominerar listnings-/förfrågningslatens, för stora objekt bandbredd och multipartkonfiguration. Moln-till-moln-kopior kan stanna på serversidan eller gå via rclone-värden; detta kontrolleras i loggen och backendfunktionen.

Backends implementerar pacing för API-rate limits. Low-Level-Retries hanterar enskilda förfrågningar; High-Level-Retries upprepar en misslyckad helhetsoperation. Först slutstatus avgör om tidigare fel kompenserades framgångsrikt (Retries). En scheduler utvärderar processens exitkod och inte förekomsten av ordet ERROR någonstans i loggen.

Filter definierar datamängden

Include-, Exclude-, Size-, Age- och Files-from-regler avgör vilka sökvägar som är synliga. Filter relaterar till den angivna roten; ett shellglob i källsökvägen ersätter ingen rclone-filterregel. Ordningen mellan Include och Exclude kan vara relevant (Rclone Filtering).

Ändras ett filter ändras den sakliga datamängden. Vid sync kan tidigare synliga objekt framstå som raderade; --delete-excluded är särskilt farligt. Filterfiler versionshanteras, hashas och godkänns tillsammans med Dry-Run-rapport och jobbdefinition. Ett säkert test använder rclone ls eller lsf med samma regler innan ett skrivande kommando följer.

En exitkod utan överföringsfel bevisar endast körningen, inte fullständig likhet mellan båda bestånden. check jämför källor och mål med respektive backends funktioner.

Verifiering: Check i stället för överföringsräknare

rclone check ändrar inga data. Det jämför storlek och gemensamma hashar, kan skapa rapporter för träffar, skillnader och saknade sökvägar samt läsa innehåll med --download när ingen gemensam fjärrhash finns. För Crypt finns rclone cryptcheck, som lämpligt jämför klartextkälla och krypterat 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" }

En hashjämförelse bevisar likhet för den använda algoritmen och namnrymden. Den bevisar inte automatiskt ACL:er, retention, leverantörsobjektversioner, katalogmetadata eller verksamhetsmässig läsbarhet. För kritiska arkiv kompletterar ett återställningstest den tekniska kontrollen.

Crypt: kryptering av data och namn

Crypt är en wrapperbackend ovanpå en annan fjärrlagring. Filinnehåll krypteras med NaCl SecretBox baserat på XSalsa20 och Poly1305; fil- och katalognamn transformeras normalt också (Crypt backend). Leverantören ser chiffertext, storleksmönster, åtkomsttider och antal objekt; Crypt är därför skydd för innehåll och namn, inte fullständig anonymisering av trafik eller metadata.

Lösenord och valfritt salt lagras endast ”obscured” i konfigurationen, om inte hela konfigurationen är krypterad. Förlust av båda återställningsuppgifterna gör data oläsbara. Före rotation eller ändring av namnkryptering testas en andra, läsande fjärrlagring mot samma data.

Crypt ändrar storlekar och hashmöjligheter. En vanlig check mellan klartext och chiffertext kan därför inte bara förvänta sig samma leverantörshash. cryptcheck eller en kontrollerad nedladdningssökväg är rätt kontrollnivå.

Kopieringskommandon arbetar uttryckligen med objekt. En VFS-mount måste däremot återskapa löpande filsystemoperationer och behöver för detta cache, skrivläge och tydliga konsistensantaganden.

VFS-mount: objektlagring är inget POSIX-filsystem

rclone mount presenterar en fjärrlagring som ett filsystem via FUSE respektive WinFsp. VFS-lagret översätter filoperationer till objektoperationer. Eftersom molnobjekt vanligtvis inte kan ändras i mitten eller utökas godtyckligt buffrar eller ersätter Rclone objekt.

Fyra cachelägen ger olika kontrakt:

LägeLokal filcacheSkrivbeteendeDriftgräns
offingendirekt och begränsatingen Seek/Read-Write som för normal fil; misslyckad uppladdning svårare att upprepa
minimalendast vid nödvändiga Read-Write-falldelvis buffratinte all Open-/Seek-semantik är möjlig
writesskrivna filer lokaltuppladdning efter Close/Writebacklokal cache är ännu ingen fjärrcommit
fullReads och Writes lokalt, delvis sparsehög filsystemkompatibilitetövervaka diskbehov, Eviction och cachekonsistens

Directory Cache håller namn och metadata i minnet. Externa ändringar visas först via polling eller efter utgång respektive flush. Buffer gäller per öppen fil; maximalt minnesbehov ökar med buffer-size × open files. Två processer får inte använda samma överlappande VFS-cache med aktiv File Caching, eftersom detta kan skada 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

I Windows tillhandahåller WinFsp filsystembryggan; i Linux och andra Unixsystem använder Rclone FUSE. En tjänst väntar på nätverk, konfiguration och mountberedskap, har en kontrollerad unmountsökväg och övervakar lokalt cachevolume. Container-mounts kräver ytterligare enhets- och mount-propagation-behörigheter och utökar behörighetsytan (Rclone mount in Docker).

Bisync: två sanningskällor

rclone bisync identifierar ändringar på båda sidor utifrån sparade listningar och överför deltan dubbelriktat. Därmed skapas beständigt jobbtillstånd utanför användardata. En förlorad eller inkonsekvent arbetskatalog kan kräva en resync-fas.

Bisync har säkerhetskontroller för nåbarhet och ovanligt många raderingar. Filterändringar ändrar den synliga datamängden och tvingar medvetet fram en resync. Om applikationer ändrar innehåll utan att ändra storlek och ModTime kan standardidentifieringen misslyckas. Dubbelriktad synkronisering används därför bara när konfliktpolicy, clock-/timestampbeteende, Access Checks, Max-Delete, backup av arbetsfiler och mänsklig lösning är dokumenterade.

Bisync är inget multi-master-filsystem med distribuerad låsning. Samtidiga redigeringar, namnändringar och offlineperioder förblir verksamhetsmässiga konflikter.

Remote Control API, Metrics och Serve-lägen

Med --rc eller rclone rcd öppnar Rclone ett HTTP-API. Det kan starta jobb, konfigurera fjärrlagringar, läsa eller skriva lokala filer och under vissa omständigheter köra OS-kommandon i rclone-användarens kontext. Dokumentationen bedömer därför åtkomst till RC som likvärdig med shellåtkomst (Remote Control / API).

RC lyssnar som standard lokalt. Vid nätverksexponering krävs stark autentisering, TLS eller en skyddad reverse proxy, brandväggsallowlist och minimala processbehörigheter. --rc-no-auth hör inte hemma på ett nåbart gränssnitt. OpenMetrics-slutpunkten kan exponera överförings- och jobbmetrik; även där kan fjärrlagringsnamn och sökvägar vara känsliga 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

Invoke-WebRequest och curl kontrollerar den lokala HTTP-slutpunkten. rclone rc använder samma API och tar över autentiseringsparametrar från jobbkonfigurationen.

Rclone kan dessutom erbjuda fjärrlagringar via HTTP, WebDAV, SFTP, FTP, NFS, DLNA eller S3-kompatibla Serve-lägen. Därmed ändras systemrollen från klient till server. Lyssnaradress, autentisering, protokollsäkerhet, VFS-cache och datarättigheter härdas då som för en fristående tjänst (Rclone serve).

Loggning, statistik och exitkoder

Loggar skiljer mellan DEBUG, INFO, NOTICE och ERROR. För maskinbearbetning finns JSON-loggning. Statistik visar checks, transfers, fel, byte, hastighet och ETA. En kort Transferred-räknare är inget varaktigt revisionsbevis; ett jobb lagrar starttid, käll-/målrot, filterhash, Rclone-bygge, upplösta icke-känsliga alternativ, slutstatistik och exitkod.

De dokumenterade exitkoderna skiljer mellan framgång, syntaxfel, saknade sökvägar, tillfälliga, mindre allvarliga och fatala fel samt uppnådda överförings- eller tidsgränser (List of exit codes). --error-on-no-transfer kan separat signalera en lyckad körning utan överföring. Schedulers och övervakning behandlar koderna efter jobbtyp; ett förväntat tomt inkrementellt jobb bedöms annorlunda än en utebliven daglig export.

En High-Level-Retry kan lösa tidiga felmeddelanden framgångsrikt. Omvänt kan en process överföra mycket och ändå avslutas nonzero på grund av få olösta objekt. Larm utlöses för slutstatus, antal fel, uttömda retries, jobblängd, utebliven heartbeat och verifieringsresultat.

Säkerhet i datavägen

Rclone ärver behörigheterna för sitt პროცესskonto och fjärrlagringsuppgifterna. En sync med Delete-rättigheter är en högt privilegierad raderingsagent. Least Privilege separerar läsande källa, skrivande mål, versionerings-/retentionsrättigheter och administrativa bucketåtgärder.

TLS-certifikatkontroll förblir aktiv. --no-check-certificate inaktiverar kedje- och värdnamnskontroll och är enligt dokumentationen endast avsett för tester (TLS options). SFTP-backends kontrollerar Host Keys med en underhållen Known-Hosts- eller fingerprintpolicy; API-slutpunkter omdirigeras inte genom okontrollerade proxier.

Filter, --backup-dir, objektversionshantering och Object Lock begränsar olika risker. En backupkatalog i samma konto skyddar inte mot kontokompromettering eller radering hos leverantören. Storage, Kryptering och Härdning behandlar de underliggande kontrollytorna.

Diagnosen skiljer mellan lokal sökväg, Rclone-filter, backend-API, autentisering, rate limit och nätverksväg. Bara så blir det synligt om en fil aldrig valdes, inte överfördes eller visades annorlunda av målet.

Nätverks- och backenddiagnostik

Ett rclone-felmeddelande kan komma från namnupplösning, TCP, TLS, proxy, leverantörsautentisering, API-rate limit, backendöversättning, lokalt filsystem eller jämförelselogik. Diagnosen följer vägen:

  1. Bekräfta binärfil, konfigurationssökväg och upplöst fjärrlagringsnamn.
  2. Kontrollera DNS, port och TLS för den konkreta slutpunkten.
  3. Använd rclone lsd eller lsjson som minimalt läsande backendtest.
  4. Samla request-/retryfas och backendfunktioner med -vv utan att publicera hemligheter.
  5. Kontrollera källa/mål, filter och fingeravtrycksbeslut.
  6. Korrelera slutstatus, exitkod och leverantörens revisionslogg.
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

Resolve-DnsName, Test-NetConnection, dig, nc, openssl s_client, rclone lsd och rclone lsjson separerar transport, autentisering, listning och objektsynlighet. Headerdumps granskas före vidarebefordran för token, signaturer, cookies och sökvägar. DNS, TCP, TLS och Felsökning fördjupar faserna.

Typiska felbilder

Rclone rapporterar ofta steget där ett jobb synligt misslyckas, inte automatiskt grundorsaken. Tabellen kopplar därför symptom, sannolik utlösare och beviset som bekräftar eller motbevisar antagandet.

SymptomSannolik orsakBevisFelaktig snabblösning
Filer kopieras på nytt vid varje körningModTime/hash saknas gemensamt eller precisionen avvikerbackendfunktioner, -vv, checkrapportange blint --size-only
Målobjekt försvinnersynkriktning, filter eller Delete-alternativDry-Run-/Combined-rapport, jobbdefinitionstarta bara om jobbet
Mount visar gamla namnDirectory Cache eller saknad pollingVFS-statistik, RC vfs/forget, leverantörslistningavsluta processen hårt
Mountskrivning saknas på fjärrenfil öppen, Writeback väntar, cache fullVFS-cache och loggradera lokal cache
Hashcheck är inte möjligingen gemensam hash, Crypt eller multipartsemantikbackendöversikt, hashsum, check --downloadanta att ETag är MD5
RC svarar externtför bred lyssnaradress/saknad autentiseringsocketlista, brandvägg, RC-flaggorbara hålla URL:en hemlig
Bisync avbryts efter filterändringarbetstillstånd skyddar mot felaktiga raderingarBisync-logg och filterhashradera arbetsfiler och starta normalt
Exitkod nonzero trots många överförda filerkvarstående fel efter retriesslutlogg, felrapporttolka överföringsräknare som framgång

Backup, återställning och reconciliation

Rclone ingår ofta i en backup, men är självt ingen oföränderlig backupmodell. sync replikerar raderingar och krypteringsskador. copy bevarar extra målobjekt, men kan skriva över befintliga versioner. Skydd uppstår genom målversionshantering, Retention/Object Lock, separata autentiseringsuppgifter, --backup-dir, oföränderliga snapshots och återställningstester.

Återställningsuppsättningen omfattar:

  • godkänd rclone-binärfil eller verifierbar releaseartefakt;
  • krypterad rclone.conf plus separat dekrypteringshemlighet;
  • leverantörsautentiseringsuppgifter och deras återanskaffning;
  • Crypt-lösenord och salt;
  • jobb-, filter- och miljödefinitioner;
  • Bisync-arbetsfiler;
  • VFS-cacheobjekt som inte laddats upp och deras tilldelning;
  • Dry-Run-, Combined-, Check- och exitkodrapporter;
  • målets versionerings-, retention- och återställningsförfarande.

En återställning utförs till en separat sökväg och kontrolleras sedan med hash, antal, storlek, stickprov på metadata och applikationstest. Reconciliation jämför Source of Truth, målversioner, VFS-Writeback och schedulertillstånd. Backup och Disaster Recovery beskriver RPO/RTO och övergripande godkännande.

Teknisk historia

Nick Craig-Wood inledde projektet med en första commit i november 2012. Grundaren dokumenterade detta ursprung på fjortonde årsdagen och länkade till det ursprungliga källläget (Happy 14th Birthday rclone, initial commit).

Rclone övertog den välbekanta riktningssyntaxen från rsync, men ersatte dess blockbaserade deltaantaganden med objekt- och leverantörsoperationer. Molnlagringar erbjuder normalt inget serverbaserat gränssnitt för rsync rolling checksum; Rclone jämför kompletta objekt baserat på tillgängliga fingeravtryck och överför dem därefter.

Med det växande antalet backends utvecklades den centrala Fs/Object-gränssnittsmodellen med valfria funktioner. Crypt lade till kryptering på klientsidan; Mount och VFS gjorde objektlagring tillgänglig för filbaserade applikationer; Remote Control API byggdes ut kraftigt 2018; Bisync lade till beständig dubbelriktad avstämning. Changelog dokumenterar denna utveckling och säkerhetsrelevanta korrigeringar. För drift är den därför det tidsberoende komplementet till denna arkitekturartikel.

Den tekniska linjen förblir konsekvent: en portabel Go-binärfil, många inbyggda backends, gemensamma kommandon och uttryckligen genomlysande leverantörsskillnader. Just dessa skillnader gör Rclone kraftfullt för administratörer och samtidigt revisionskrävande.

Checklista för administratörer

Före ett produktionsjobb finns minst följande punkter dokumenterade:

  • Binärfilens ursprung, konfigurationssökväg och fjärrupplösning är entydiga.
  • Källa, mål, riktning och förväntat målträd finns i runbooken.
  • Backendfunktioner för hash, ModTime, Case, Metadata, Copy/Move och listning är kontrollerade.
  • Filterfil och jobbparametrar är versionshanterade; Dry Run och Combined Report har godkänts.
  • Delete-, Max-Delete-, Backup-Dir-, versionshanterings- och retentionpolicy passar ihop.
  • Autentiseringsuppgifter har endast nödvändiga rättigheter; Config, Crypt-lösenord och salt kan återställas.
  • Transfers, Checkers, Pacer och bandbredd respekterar värd och leverantör.
  • VFS-cache har egen volym, kapacitetslarm, ordnad stoppning och Writeback-kontroll.
  • RC/Serve lyssnar endast kontrollerat och skyddas som shellåtkomst.
  • Framgång bevisas genom slutstatus, exitkod, checkrapport och återställningstest.

Källor

Nya artiklar via e-post

Ett kort meddelande när en ny praktisk artikel om meddelandetjänster, säkerhet eller Microsoft 365 publiceras.

Adressen används endast för nyhetsbrevet. Avsluta med ett klick. Integritet

Förstorad infografik