Kommandot rsync via SSH är en av de mest praktiska metoderna för att snabbt, säkert och avbrottssäkert överföra stora filer mellan två servrar i Linux. Speciellt när det gäller webbplatsfiler som är hundratals GB stora, backup-arkiv, mediamappar eller applikationsdata, ger rsync en betydande hastighetsfördel jämfört med traditionella kopieringsmetoder, eftersom det bara överför de ändrade blocken. Grundprincipen är att filerna på källservern synkroniseras krypterat till måservern via en SSH-tunnel; om anslutningen bryts kan processen fortsätta där den slutade.
Vid serverflytt, hostinguppgradering, datacenterbyte eller backupoperationer är både hastighet och dataintegritet viktiga. Att ladda ner och ladda upp ett stort arkiv som en helhet tar tid och kan leda till att man måste börja om vid anslutningsproblem. Här kommer rsync in i bilden och kan bevara tidsstämplar, behörigheter, ägarskapsinformation och mappstrukturer. Därför föredras det ofta av Linux-systemadministratörer, DevOps-team och webbhotellsexperter i dagliga operationer.
I den här guiden kommer vi steg för steg att gå igenom processen för att överföra stora filer mellan två Linux-servrar med rsync via SSH, med verkliga exempel på kommandon. Vi kommer också att dela med oss av parametrar för att öka prestandan, säkerhetskontroller, felhanteringsscenarier, metoder för testöverföring och punkter att tänka på innan vi går över till produktionsmiljö. Om du planerar att byta till en ny VPS eller hostingmiljö, se till att du har tillräckligt med diskutrymme, SSH-åtkomst och rätt användarbehörigheter på både käll- och måservern innan du följer denna guide. Du kan kolla in sidorna Hostragons VPS-serverlösningar och Linux Hosting Paket för relaterade infrastrukturalternativ.
Vad är rsync och varför föredras det för överföring av stora filer?
Rsync är ett kraftfullt kommandoradsverktyg som används för att synkronisera filer och kataloger mellan lokala system eller fjärrservrar. Dess mest framträdande egenskap är deltaöverföringsalgoritmen. Denna algoritm överför inte hela filen varje gång, utan bara de ändrade delarna. Till exempel, om det finns endast 2 GB förändringar i en backupfil som är 80 GB stor, kan man under lämpliga förhållanden överföra de ändrade blocken istället för att flytta hela filen igen.
SSH krypterar överföringen. På så sätt överför rsync inte filinnehållet som klartext över nätverket. Denna funktion är särskilt viktig för kunddata, e-handelsbeställningar, mediearkiv, databasbackuper och specifika applikationsfiler. Dataskydd i hostingvärlden handlar inte bara om SSL-certifikat; överföringskanalen mellan servrar måste också vara säker. När du använder SSL-certifikat för webbplatstrafik bör SSH-kryptering också användas vid filöverföringar mellan servrar.
Rsync är mer flexibelt än FTP eller manuella nedladdnings- och uppladdningsmetoder. Det kan bevara behörigheter, överföra symboliska länkar, radera saknade filer på målet, begränsa bandbredd och testa vad som ska göras innan överföring. Denna kontrollnivå ger en stor fördel vid riskfyllda operationer som att överföra stora filer.
När bör du använda rsync via SSH?
Kommandot rsync via SSH är särskilt idealiskt för att flytta stora, många eller frekvent ändrade filer. För en enkel visuell mapp kan man klara sig med manuell SFTP; men när det handlar om tusentals filer, olika behörigheter och stora arkiv blir rsync ett mycket mer pålitligt alternativ.
- Om du flyttar en webbplats från en gammal server till en ny VPS-server.
- Om du överför kataloger som innehåller tusentals mediefiler, som WordPress uploads-mappen.
- Om du kopierar dagliga, veckovisa eller månatliga backuper till en annan server.
- Om du byter datacenter eller hostingleverantör.
- Om du synkroniserar applikationsfiler mellan produktions- och backup-miljöer.
- Om du planerar långvariga överföringar med risk för anslutningsavbrott.
Till exempel, om du laddar ner en 250 GB stor mediamapp till din stationära dator och sedan laddar upp den till den nya servern, innebär det att du gör två separata överföringar. Detta förlänger den totala tiden och kan göra din hem- eller kontorsinternetanslutning till en flaskhals. Med rsync kan du överföra direkt från källservern till måservern och eliminera detta mellanled.
Vad behövs innan du börjar?
För en framgångsrik rsync-operation räcker det inte att bara känna till kommandot. Att kontrollera förhållandena på både käll- och måservern minskar risken för dataförlust eller avbrutna överföringar. Nedan följer kontroller som måste göras i produktionsmiljöer.
1. Bekräfta SSH-åtkomst
Det måste vara möjligt att upprätta en SSH-anslutning från källservern till måservern. Den standardanslutningen testas så här: ssh användare@mål-server-ip. Om SSH körs på en annan port, testas anslutningen enligt följande: ssh -p 2222 användare@mål-server-ip. Om detta test misslyckas kommer rsync inte att fungera heller. Brandvägg, Fail2ban, SSH-port, användarbehörighet och lösenords- eller nyckelverifiering bör kontrolleras.
2. Kontrollera att rsync-paketet är installerat
De flesta Linux-distributioner kommer med rsync förinstallerat; det är ändå bra att kontrollera. På Debian- och Ubuntu-baserade system kan kommandot rsync --version användas. Om det inte är installerat kan det laddas ner med apt install rsync. För AlmaLinux, Rocky Linux eller CentOS-varianter används kommandona dnf install rsync eller yum install rsync. Om du använder en Linux-baserad VPS hos Hostragons tar installationen vanligtvis bara några sekunder.
3. Beräkna diskutrymme
Om det inte finns tillräckligt med ledigt utrymme på måservern kommer överföringen att avbrytas. För att se storleken på källdirectory kan du använda du -sh /källdir-mapp. På målet bör diskstatus kontrolleras med df -h. I praktiken bör det inte bara finnas tillräckligt med utrymme för filstorleken, utan även för temporära filer och loggar. Om du planerar att överföra 500 GB data är det klokt att ha minst 550-600 GB tillgängligt på målet.
4. Planera kritiska tjänster och ändrade filer
Filer på aktiva webbplatser kan ändras under överföringen. Speciellt användaruppladdningar, cachemappar och loggfiler uppdateras kontinuerligt. Vid stora överföringar överförs först huvuddata och sedan sätts systemet i underhållsläge för att köra en sista rsync. På så sätt kan driftstoppet reduceras till minuter. Du kan slutföra din plan med stödavsnitt som Guide för överföring av WordPress hosting.
Grundläggande rsync-kommando: Överför filer mellan två servrar
Det vanligast använda grundläggande kommandot ser ut så här: rsync -avz /källdir/ användare@mål-ip:/mål/directory/. Här är -a arkivläge och försöker bevara information som behörigheter, tidsstämplar och symboliska länkar. -v ger detaljerad output. -z tillämpar komprimering under överföringen. Snedstrecket i slutet av katalognamnet är en viktig detalj. Om du skriver /källdir/ kopieras innehållet i mappen till målet; om du skriver /källdir kopieras själva mappen till målet.
Låt oss tänka på ett exempel: Du vill flytta 180 GB webbplatsfiler från /var/www/site/public_html/ på den gamla servern till /var/www/site/public_html/ på den nya servern. Kommandot fungerar enligt följande: rsync -avz /var/www/site/public_html/ root@203.0.113.20:/var/www/site/public_html/. Denna process överför filer från källservern till måservern via SSH.
Om du inte vill använda root är det säkrare att skapa en specifik användare med skrivbehörighet till den aktuella katalogen på måservern. Du kan till exempel använda en användare som heter deploy och justera ägarskapet av nödvändiga mappar därefter. Även om det är praktiskt att arbeta direkt med root i produktionsmiljöer, rekommenderas det av säkerhetsskäl att använda en användare med begränsade rättigheter.
Rekommenderade säkra och hållbara rsync-parametrar
Vid stora filöverföringar är det inte alltid rätt att nöja sig med det grundläggande kommandot. För anslutningsavbrott, partiella filer, felaktiga borttagningsåtgärder eller långsamma nätverk bör ytterligare parametrar användas. Följande kommando är en solid utgångspunkt för många verkliga överföringsscenarier:
rsync -aHAXv --numeric-ids --partial --progress --append-verify -e ssh /källdir/ användare@mål-ip:/mål/directory/
I detta kommando hjälper -a arkivläge, -H hårdkopplingsinformation, -A ACL-behörigheter och -X utökade attribut att bevaras. --numeric-ids baseras på ID-värden istället för användar- och gruppnamn; det kan vara användbart när användarnamn skiljer sig mellan olika servrar. --partial lämnar kvar partiella filer utan att ta bort dem. --progress visar överföringsstatus. --append-verify hjälper särskilt stora filer att bekräfta den tillagda delen när de fortsätter från där de slutade.
Inte varje parameter är nödvändig i varje system. Till exempel kan användning av -aHAX vara tillräckligt vid en enkel webbplatsöverföring, medan bevarande av ACL och utökade attribut kan vara kritiskt i en applikation som använder specifika filbehörigheter. Därför är det viktigt att göra en testöverföring först.
Vad ska kommandot se ut som om du använder en annan SSH-port?
För säkerhet kan SSH-porten köras på en annan port än 22. I så fall anges SSH-parametern inom rsync. Exempel: rsync -avz -e ssh -p 2222 /källdir/ användare@mål-ip:/mål/directory/. Men -e-parametern måste användas tillsammans med rätt värde. Den korrekta användningen ser ut så här: rsync -avz -e 'ssh -p 2222' /källdir/ användare@mål-ip:/mål/directory/.
Eftersom användning av enkla citattecken kan bete sig annorlunda i JSON och vissa paneler, se till att citattecknen är korrekta när du skriver direkt i terminalen. Om du ansluter med en SSH-nyckel kan parametern -i också läggas till: rsync -avz -e 'ssh -p 2222 -i /root/.ssh/id_rsa' /källdir/ användare@mål-ip:/mål/directory/. Denna metod används ofta i automatisering och cron-baserade backupjobb.
Test innan överföring: Användning av --dry-run
En av de mest professionella stegen att ta före en stor datamängd överföring är att använda --dry-run. Denna parameter kopierar inte filerna på riktigt; den visar bara vilka filer som kommer att överföras. På så sätt kan du identifiera felaktiga mappar, felaktiga destinationer eller oväntade borttagningsåtgärder i förväg.
Exempel på testkommando: rsync -avz --dry-run /var/www/site/ användare@mål-ip:/var/www/site/. Du kommer att se de filer som ska överföras, de mappar som kommer att skapas och en sammanfattning av processen. Om du planerar att använda --delete blir --dry-run ännu viktigare. Eftersom --delete kan radera filer som inte finns på källan från målet, är det avgörande att använda det korrekt; felaktig användning kan leda till betydande dataförlust.
Den professionella arbetsordningen är vanligtvis följande: först görs SSH-testet, sedan kontrolleras diskutrymmet, därefter körs rsync --dry-run, en verklig test görs med en liten katalog och slutligen påbörjas huvudöverföringen. Denna metod kan kräva några extra minuter, men den förhindrar överföringar som kan ta timmar att åtgärda.
Prestanda genom komprimering, bandbredd och krypteringsinställningar
Rsyncs prestanda beror inte bara på filstorleken. CPU-kraften på servrarna, typ av disk, nätverksfördröjning, bandbredd och antal filer spelar också en viktig roll. Många små filer kan överföras långsammare än en stor fil eftersom metadata måste behandlas för varje fil. I VPS-miljöer med NVMe-diskar kan filskanning och skrivprestanda vara avsevärt bättre. Därför är det klokt att överväga NVMe VPS-server om du planerar intensiva överföringar.
Parametern -z för komprimering är till nytta för textfiler, loggar och vissa typer av backuper. Men för redan komprimerade zip-, tar.gz-, jpg-, mp4- eller gzip-filer kan det öka CPU-användningen utan att ge mycket fördelar. Om du flyttar stora mediefiler mellan två kraftfulla servrar med 1 Gbps-anslutning kan du få bättre prestanda utan att använda -z. Å andra sidan kan -z ge betydande besparingar vid låg bandbredd och texttunga filer.
För att begränsa bandbredden kan --bwlimit användas. Till exempel begränsar --bwlimit=50000 till cirka 50 MB/s. Detta är viktigt för att inte kväva nätverkstrafiken på en aktiv webbplats. Att överföra med full hastighet under rusningstider på produktionsservern kan påverka användarupplevelsen negativt. Det är en bra praxis att planera överföringar under natten, sätta bandbreddsgränser och övervaka lastvärdena under processen.
Jämförelse mellan rsync, scp, SFTP och FTP

Det finns flera metoder för filöverföring, men varje metod har sina styrkor och svagheter. Tabellen nedan sammanfattar när varje verktyg är mer lämpligt för överföring av stora filer och serverflytt.
| Metod | Säkerhet | Fortsätta från där det slutade | Prestanda för stora filer | Optimalt användningsområde |
|---|---|---|---|---|
| rsync + SSH | Hög | Stark | Mycket bra | Serverflytt, backup, synkronisering |
| scp | Hög | Begränsad | Medel | Snabb kopiering av få filer |
| SFTP | Hög | Klientberoende | Medel | Manuell filhantering |
| FTP | Låg | Klientberoende | Variabel | Gamla system där säkerhet inte är kritisk |
Som tabellen visar är rsync särskilt framträdande vid upprepade synkroniseringar och överföring av stora data. Scp är enkelt och användbart, men är inte lika kraftfullt som rsync när det gäller att smart upptäcka ändrade filer. FTP är inte lämpligt för moderna säkerhetsstandarder om det används utan kryptering. FTP-åtkomst är praktisk i hostingpaneler, men vid kritiska överföringar mellan servrar bör SSH-baserade metoder föredras.
Exempel på arbetsflöde för att flytta en aktiv webbplats
Syftet med att flytta en webbplats från en gammal server till en ny server är inte bara att kopiera filer. DNS, databas, SSL, PHP-version, filbehörigheter och e-postkonfiguration bör också kontrolleras. Nedan följer ett exempel på arbetsflöde för en stor webbplats med låga avbrott.
- Förbered webbserver, PHP, databas och nödvändiga moduler på den nya servern.
- För att underlätta överföringen, sänk DNS TTL-värdet för domänen till en låg nivå som 300 sekunder. Du kan överväga sidan Domänsökning och domänhantering för domänhantering.
- Starta den första rsync-överföringen medan webbplatsen är aktiv. Detta steg överför det mesta av den stora datamängden.
- Ta en backup av databasen och överför den till den nya servern.
- Sätt webbplatsen i kort underhållsläge.
- Kör det andra rsync-kommandot för att synkronisera de senaste ändrade filerna.
- Uppdatera databasen igen eller använd en inkrementell strategi.
- Kontrollera filbehörigheterna, webbplatsens start och loggar på den nya servern.
- Installera eller förnya SSL-certifikatet. För detta kan innehållet installation av SSL-certifikat vara användbart.
- Dirigera DNS-posterna till den nya IP-adressen.
I denna metod görs den längsta överföringen av huvudfilerna medan webbplatsen fortfarande är aktiv. Driftstopp uppstår endast under den sista synkroniseringen och DNS-övergången. Denna metod kan minska timmar av driftstopp till bara några minuter för stora mediearkiv på WordPress-webbplatser.
Kontroll av dataintegritet
När överföringen är klar är det inte tillräckligt att bara kommandot har avslutats. Antalet filer, storlekar och kritiska filer bör kontrolleras. För en enkel kontroll kan katalogstorlekarna jämföras med kommandot du -sh på både käll- och målservrar. Men på grund av skillnader i filsystemets block kan värdena se olika ut. För mer detaljerad kontroll kan rsync köras igen med samma parametrar. Om det inte finns några nya filer som ska överföras bör outputen vara minimal.
För checksum-kontroll kan kommandot rsync -avc --dry-run /källdir/ användare@mål-ip:/mål/directory/ användas. Här hjälper -c-parametern till att jämföra filerna med tidsstämpel och storlek, samt checksum. Det bör användas med försiktighet på mycket stora data, eftersom det kan skapa CPU- och diskbelastning. Denna extra verifiering ger trygghet vid kritiska arkiv, databasdump-filer eller kunddokument.
Om du har flyttat en webbplats, gör även en kontroll på applikationsnivå. Startsidan, administrationspanelen, bilduppladdning, betalningssidan, kontaktformuläret och fel-loggar bör granskas. För e-handelssajter är det inte tillräckligt att bara flytta filer; betalningsintegrationer och cron-jobb bör också testas på den nya servern.
Vanliga fel och lösningar
Fel: Permission denied
Detta fel uppstår vanligtvis på grund av SSH-användarbehörighet, skrivbehörighet för målmappen eller nyckelverifiering. Försök först att etablera en normal SSH-anslutning med samma användare. Om anslutningen lyckas, testa att skapa en fil i målmappen. Vid behov kan ägarskapet av den aktuella mappen ges till den berörda användaren med chown, eller en strategi med sudo kan planeras.
Fel: No space left on device
När det inte finns tillräckligt med utrymme kvar på måldisken avbryts överföringen. Kontrollera diskpartitionerna med df -h. Ibland är den primära disken inte full, men /tmp eller målmappen kan vara det. Vid stora överföringar kan loggfiler, gamla backuper och cachemappar rensas. För en permanent lösning kan det vara nödvändigt att öka disken eller byta till en VPS-plan med högre kapacitet.
Fel: Connection reset eller Broken pipe
Vid långvariga överföringar kan nätverksavbrott inträffa. Om du använder --partial och --append-verify kan du köra kommandot igen för att fortsätta från där det slutade. SSH keepalive-inställningar kan också vara till hjälp. På klientsidan kan en inställning som ServerAliveInterval 60 minska risken för att anslutningen bryts vid inaktivitet.
Fel: Mycket långsam överföring
Långsamhet kan bero på antalet filer, disk I/O-gränser, komprimeringsbörda eller nätverkskapacitet. Om det finns många små filer kan det i vissa fall vara snabbare att först skapa ett tar-arkiv; men då minskar rsyncs fördelar när det gäller filbaserade förändringar. Testa att ta bort -z-parametern för stora och redan komprimerade filer. Använd också verktyg som iotop, htop och iftop för att avgöra var flaskhalsen ligger, om det är CPU, disk eller nätverk.
Bästa säkerhetspraxis
Säkerheten får inte förbises vid filöverföring mellan servrar. Särskilt root-åtkomst, SSH-nycklar och backupfiler bör betraktas som känsliga. Det rekommenderas att använda SSH-nycklar istället för lösenordsinloggning. Behörigheterna för nyckelfiler bör hållas strikta, privata nycklar får inte delas och, om möjligt, bör de skyddas med en passphrase.
Det är en bra metod att skapa en temporär användare för överföringen och ge endast åtkomst till nödvändiga kataloger. Efter att processen är klar kan behörigheterna för denna användare tas bort eller kontot inaktiveras. Att begränsa SSH-åtkomst till specifika IP-adresser kan också minska attackytan. Brandväggsregler, Fail2ban och en uppdaterad version av OpenSSH bör ingå i grundkontrollerna.
Om databasdumpfiler, kunddokument eller arkiv som innehåller personlig data flyttas, bör onödiga temporära filer rensas både på källan och målet efter överföringen. Att lämna backupfiler som .sql, .zip eller .tar under webbroten utgör en allvarlig säkerhetsrisk. Dessa filer bör lagras i en mapp som är stängd för webbåtkomst, eller raderas efter att processen är avslutad.
Användning av rsync för automatisk backup
Rsync kan användas inte bara för engångsöverföringar utan också för regelbundna backuper. Till exempel kan en cron-jobb definieras för att skicka en specifik mapp till backupservern varje natt. I detta scenario upprättas en säker anslutning utan lösenord med SSH-nyckel, rsync överför endast de ändrade filerna och en bandbreddsgräns kan tillämpas.
Exempel på logik: rsync -a --delete --bwlimit=30000 /var/www/site/ backup@backup-ip:/backup/site/. Detta kommando kan synkronisera målmappen med källan. Men det bör användas med försiktighet på grund av --delete-parametern. Om en fil oavsiktligt raderas på källan, raderas den också på målet. Därför bör kritiska backupstrategier föredra snapshot-lösningar, dagliga mappar eller versionering.
I hostingoperationer är 3-2-1 backupregeln en bra referens: Det ska finnas minst 3 kopior av datan, i 2 olika miljöer, med 1 kopia på en annan plats. Rsync gör det praktiskt att skapa dessa kopior mellan servrar. För mer omfattande infrastruktur kan du stärka din plan med Backup-lösningar och tjänster för företags hosting.
Sista kontrollista
Innan du påbörjar överföringen av stora filer, är det viktigt att följa den här korta listan för att minska risken för fel. Denna lista bör särskilt bli en standardprocedur i produktionsmiljöer.
- Är rsync installerat på både käll- och måserver?
- Har SSH-anslutningen testats med rätt användare och port?
- Finns det tillräckligt med diskutrymme på måserver?
- Kontrollerades den första processen med --dry-run?
- Har underhållsläge och den sista synkroniseringen planlagts för den aktiva webbplatsen?
- Har målmappen verifierats noggrant om --delete ska användas?
- Ska filstorlekar, behörigheter och applikationstester göras efter överföringen?
- Ska temporära backup- och dumpfiler rensas på ett säkert sätt?
Även om dessa kontroller verkar enkla, är de vanligaste problemen i verkligheten ofta orsakade av felaktiga målmappadresser, bristande behörigheter, otillräckligt diskutrymme och oplanerade DNS-övergångar. En planerad rsync-process förkortar både överföringstiden och ökar chansen för ett framgångsrikt genomförande.
Vanliga frågor
Vad händer om anslutningen bryts när jag använder rsync via SSH, börjar överföringen om från början?
Nej, om rätt parametrar används börjar den inte om från början. Alternativen --partial och --append-verify hjälper till att bevara de ofullständiga stora filerna och gör att kommandot kan fortsätta från där det slutade när det körs igen. Det är dock bra att kontrollera diskutrymme och status för ofullständiga filer innan du kör kommandot igen vid kritiska överföringar.
Kan jag överföra en databas direkt med rsync?
Rsync flyttar filer; det är inte hälsosamt att direkt kopiera aktiva databasfiler. För MySQL eller MariaDB bör mysqldump eller fysiska backupverktyg användas, och den resulterande backupfilen bör överföras till måservern med rsync. För att säkerställa dataintegritet i aktiva system bör underhållsläge eller replikationsstrategi planeras.
Behöver jag root-åtkomst på båda servrarna för att använda rsync?
Root-åtkomst är inte ett krav. En användare med skrivbehörighet till målmappen är tillräcklig. Men om filägarskap, systemkataloger, ACL eller specifika behörigheter måste bevaras, kan högre behörigheter krävas. Av säkerhetsskäl är det alltid bättre att arbeta med en användare med begränsade rättigheter om möjligt.
Är --delete-parametern säker?
--delete är mycket användbar när den används korrekt för att synkronisera målmappen med källan, men felaktig användning kan leda till datarförlust. Därför bör kommandon som innehåller --delete alltid testas med --dry-run först, och käll- och målmappadresser bör noggrant verifieras.
Vilket är bättre för stora filöverföringar, rsync eller scp?
För engångsöverföringar av få filer kan scp vara tillräckligt, men för stora filer, många filer och upprepade synkroniseringar är rsync vanligtvis bättre. Det kan upptäcka ändringar i datan, fortsätta avbrutna överföringar, begränsa bandbredd och erbjuder testläge.
Sammanfattning och nästa steg
Att överföra stora filer mellan servrar med rsync via SSH är en snabb, säker och hanterbar metod. Med rätt parametrar blir den motståndskraftig mot anslutningsavbrott, sparar tid genom att bara överföra ändrade filer och minskar driftstopp vid flytt av aktiva webbplatser. För bästa resultat, kontrollera först SSH och diskutrymme, testa med --dry-run och planera sedan huvudöverföringen noggrant.
Om du planerar att byta till en ny server, högkapacitetslagring eller en mer prestandaorienterad hostinginfrastruktur kan du kolla på Hostragons lösningar; med VPS, hosting, domän och SSL-alternativ kan du göra din överföringsprocess mer säker. Börja med små tester för en smidig övergång, mät resultaten och planera den sista synkroniseringen noggrant.