Overføring av Store Filer Mellom Servere med rsync via SSH

rsync-kommandoen over SSH er en av de mest praktiske metodene for å flytte store filer mellom to servere raskt, sikkert og pålitelig. Spesielt når det gjelder websidefiler på flere hundre GB, backup-arkiv, mediemapper eller applikasjonsdata, gir rsync en betydelig hastighetsfordel sammenlignet med klassiske kopieringsmetoder, ettersom den kun overfører de endrede blokkene. Den grunnleggende bruken er slik: filene på kilde-serveren synkroniseres kryptert til målserveren via SSH-tunnelen; hvis forbindelsen brytes, kan prosessen gjenopptas der den slapp.

Ved serverflytting, oppgradering av hosting, bytte av datasenter eller backup-operasjoner er både hastighet og dataintegritet viktig. Å laste ned et stort arkiv i én del og deretter laste opp igjen, er både tidkrevende og kan føre til at man må starte forfra ved tilkoblingsfeil. Her kommer rsync inn i bildet, da den kan bevare filens tidsstempler, tillatelser, eierinformasjon og mappestruktur. Derfor er den ofte foretrukket av Linux-systemadministratorer, DevOps-team og webhosting-eksperter i daglige operasjoner.

I denne guiden vil vi gå gjennom prosessen med å overføre store filer mellom to Linux-servere via SSH med rsync, trinn for trinn, med ekte kommandeksempler. Vi vil også dele parametere for ytelsesforbedring, sikkerhetskontroller, feilsituasjoner, testoverføringsmetoder og punkter å være oppmerksom på før du går over til produksjonsmiljø. Hvis du planlegger å migrere til en ny VPS eller hosting-miljø, må du forsikre deg om at det er tilstrekkelig diskplass, SSH-tilgang og riktige brukerrettigheter på både kilde- og målserveren. For relevant infrastrukturvalg, sjekk Hostragons VPS-serverløsninger og Linux hostingpakker.

Hva er rsync og hvorfor velges det for å overføre store filer?

rsync er et kraftig kommandolinjeverktøy som brukes til å synkronisere filer og kataloger mellom lokale systemer eller eksterne servere. Den viktigste funksjonen er delta-overføringsalgoritmen. Denne algoritmen overfører ikke hele filen hver gang, men kun de endrede delene. For eksempel, hvis det kun er 2 GB endringer i en 80 GB backup-fil, er det mulig å overføre de endrede blokkene i stedet for hele filen under passende forhold.

SSH gjør overføringen kryptert. På denne måten sender ikke rsync kommandoen dataene som klar tekst over nettverket. Denne funksjonen er spesielt viktig for kunde-data, e-handelsordre, mediearkiv, database-backuper og spesielle applikasjonsfiler. I hosting-verdenen er databeskyttelse ikke bare begrenset til SSL-sertifikater; overføringskanalen mellom servere må også være sikker. Når du bruker SSL-sertifikat for webtrafikk, bør SSH-kryptering foretrekkes for filoverføring mellom servere.

rsync er mer fleksibel enn FTP eller manuelle nedlastings- og opplastingsmetoder. Den kan bevare tillatelser, overføre symboliske lenker, slette filer på målserveren som er slettet på kilde-serveren, begrense båndbredde og teste hva som skal gjøres før overføringen. Dette kontrollnivået gir betydelige fordeler ved risikable oppgaver som overføring av store filer.

Når bør du bruke rsync-kommandoen over SSH?

rsync-kommandoen over SSH er ideell for overføring av store, mange eller hyppig endrede filer. For enkle visuelle mapper kan manuell SFTP være tilstrekkelig, men når det gjelder tusenvis av filer, ulike tillatelser og store arkiver, blir rsync et mye mer pålitelig alternativ.

• Hvis du flytter en nettside fra en gammel server til en ny VPS-server.
• Hvis du overfører kataloger med tusenvis av mediefiler, som for eksempel WordPress uploads-mappen.
• Hvis du kopierer daglige, ukentlige eller månedlige sikkerhetskopier til en annen server.
• Hvis du gjør endringer i datasenter eller hosting-leverandør.
• Hvis du synkroniserer applikasjonsfiler mellom produksjons- og backup-miljøer.
• Hvis du planlegger langvarige overføringer med risiko for tilkoblingsbrudd.

For eksempel, å laste ned en 250 GB mediemappe til skrivebordet ditt og deretter laste det opp til den nye serveren, innebærer to separate overføringer. Dette forlenger den totale tiden og kan flaskehalse hjem- eller kontorinternettforbindelsen din. Med rsync kan du overføre direkte fra kilde-server til målserver, og dermed eliminere dette mellomsteget.

Forberedelser før du begynner

Å vite kommandoen for en vellykket rsync-operasjon er ikke nok. Det er viktig å kontrollere forholdene på kilde- og målserverne for å redusere risikoen for datatap eller ufullstendige overføringer under prosessen. Følgende kontroller må alltid utføres i produksjonsmiljøer.

1. Bekreft SSH-tilgang

Det må være mulig å etablere en SSH-tilkobling fra kilde-serveren til målserveren. Den standard tilkoblingen kan testes slik: ssh bruker@mål-server-ip. Hvis SSH kjører på en annen port, kan tilkoblingen testes med: ssh -p 2222 bruker@mål-server-ip. Hvis denne testen mislykkes, vil ikke rsync fungere heller. Brannmur, Fail2ban, SSH-port, brukertillatelser og passord eller nøkkelsjekk må kontrolleres.

2. Kontroller at rsync-pakken er installert

De fleste Linux-distribusjoner leveres med rsync installert; det er likevel viktig å kontrollere det. På Debian- og Ubuntu-baserte systemer kan rsync --version brukes. Hvis det ikke er installert, kan det installeres med apt install rsync. For AlmaLinux, Rocky Linux eller CentOS-distribusjoner kan dnf install rsync eller yum install rsync brukes. Hvis du bruker en Linux-basert VPS på Hostragons, tar installasjonen vanligvis bare noen sekunder.

3. Beregn diskplassen

Overføringen vil stoppe hvis det ikke er nok ledig plass på målserveren. For å se størrelsen på kilde-katalogen kan du bruke du -sh /kilde/katalog. Diskstatusen på målserveren bør kontrolleres med df -h kommandoen. I praksis må det ikke bare være plass tilsvarende filstørrelsen, men også plass til midlertidige filer og logger. For eksempel, hvis du skal flytte 500 GB data, er det sunnere å planlegge minst 550-600 GB tilgjengelig plass på målserveren.

4. Planlegg kritiske tjenester og endrede filer

Filer på live nettsider kan endres under overføringen. Spesielt brukeropplastinger, cache-mapper og loggfiler oppdateres kontinuerlig. Ved store overførsler overføres først hoveddataene, deretter settes nettstedet i vedlikeholdsmodus for å kjøre en siste rsync. Slik kan nedetiden reduseres til minutter. For WordPress-nettsteder kan du bruke støtteinnhold som Guide for flytting av WordPress hosting for å fullføre prosessen din.

Grunnleggende rsync-kommando: Overføre filer mellom to servere

Den mest brukte grunnleggende strukturen er som følger: rsync -avz /kilde/katalog/ bruker@mål-ip:/mål/katalog/. Her er -a arkivmodus som prøver å bevare tillatelser, tidsstempler og symboliske lenker. -v gir detaljert utdata. -z anvender komprimering under overføringen. Skråstreken på slutten av katalogen er en viktig detalj. Hvis du skriver /kilde/katalog/, kopieres innholdet i katalogen til målet; hvis du skriver /kilde/katalog, opprettes katalogen selv under målet.

La oss tenke oss et eksempel: Du ønsker å flytte 180 GB webfiler fra /var/www/site/public_html/ mappen på den gamle serveren til /var/www/site/public_html/ katalogen på den nye serveren. Kommandoen vil fungere slik: rsync -avz /var/www/site/public_html/ root@203.0.113.20:/var/www/site/public_html/. Denne prosessen overfører filer fra kilde-serveren til målserveren over SSH.

Hvis du ikke ønsker å bruke root-brukeren, er det tryggere å opprette en spesifikk bruker med skrive tilgang til den aktuelle katalogen på målserveren. For eksempel kan du bruke en bruker kalt deploy og justere eierskapet til mappen deretter. Selv om det er praktisk å jobbe direkte med root i produksjonsmiljøer, anbefales det av sikkerhetsmessige årsaker å bruke en bruker med begrensede rettigheter.

Anbefalte sikre og robuste rsync-parametere

Ved store filoverføringer er det ikke alltid tilstrekkelig å bruke bare grunnleggende kommandoer. Det er nødvendig å bruke ekstra parametere for å håndtere tilkoblingsbrudd, delvise filer, feil sletteoperasjoner eller treg nettverk. Følgende kommando er et solid utgangspunkt for mange reelle overføringsscenarier:

rsync -aHAXv --numeric-ids --partial --progress --append-verify -e ssh /kilde/katalog/ bruker@mål-ip:/mål/katalog/

I denne kommandoen hjelper -a med å bevare arkivmodus, -H bevarer hardlenkeinformasjon, -A bevarer ACL-tillatelser, og -X bevarer verdiene for utvidede attributter. --numeric-ids baserer seg på ID-verdier i stedet for brukernavn og gruppe navn; dette kan være nyttig når brukernavnene er forskjellige på ulike servere. --partial lar delvise filer bli liggende uten å slette dem. --progress viser statusen for overføringen. --append-verify hjelper spesielt med store filer ved å bekrefte den tilføjede delen når den gjenopptas.

Hver parameter er kanskje ikke nødvendig i alle systemer. For eksempel kan bruken av -aHAX være tilstrekkelig for en enkel overføring av et nettsted, mens bevaring av ACL og utvidede attributtdata kan bli kritisk i applikasjoner med spesifikke filrettigheter. Derfor er det viktig å gjøre en testoverføring først.

Hvordan bruke en annen SSH-port?

For sikkerhet kan SSH-porten kjøre på en annen port enn 22. I så fall må SSH-parametere spesifiseres i rsync. Eksempel: rsync -avz -e ssh -p 2222 /kilde/katalog/ bruker@mål-ip:/mål/katalog/. Men verdien av -e parameteren må brukes sammen med kommandoen. Den riktige bruken er som følger: rsync -avz -e 'ssh -p 2222' /kilde/katalog/ bruker@mål-ip:/mål/katalog/.

På grunn av at enkelte paneler og JSON kan oppføre seg forskjellig med enkelt anførselstegn, må du sørge for at anførselstegnene er riktig når du skriver direkte i terminalen. Hvis du oppretter forbindelse med SSH-nøkkel, kan -i parameteren også legges til: rsync -avz -e 'ssh -p 2222 -i /root/.ssh/id_rsa' /kilde/katalog/ bruker@mål-ip:/mål/katalog/. Denne metoden brukes ofte i automatiserte og cron-baserte backup-jobber.

Test før overføring: Bruk av --dry-run

En av de mest profesjonelle trinnene å ta før man flytter store data, er å bruke --dry-run. Denne parameteren kopierer ikke filer, men viser hvilke filer som vil bli overført. Dermed kan feil katalog, feil målsti eller uventede sletteoperasjoner oppdages på forhånd.

Eksempel på testkommando: rsync -avz --dry-run /var/www/site/ bruker@mål-ip:/var/www/site/. Du vil se filene som skal overføres, de opprettede katalogene og en oppsummering av prosessen. Hvis du planlegger å bruke --delete, blir dry-run enda mer kritisk. Fordi --delete kan slette filer på målet som ikke finnes på kilden. Når det brukes riktig, gjør det målet til et speilbilde av kilden; hvis det brukes på feil katalog, kan det føre til betydelig datatap.

Den profesjonelle rekkefølgen for operasjonen er vanligvis slik: først testes SSH, deretter kontrolleres diskplassen, så kjøres rsync --dry-run, en ekte test gjøres med en liten katalog, og til slutt startes hovedoverføringen. Denne tilnærmingen krever noen ekstra minutter, men forhindrer feil overføringer som kan ta timer.

Ytelsesinnstillinger for komprimering, båndbredde og kryptering

rsyncs ytelse avhenger ikke bare av filstørrelsen. CPU-kraften til serverne, disktypene, nettverksforsinkelsen, båndbredden og antall filer er også viktige. Mange små filer kan overføres langsommere enn en stor fil; fordi metadata-prosesser må gjøres for hver fil. VPS-miljøer med NVMe-disker kan ha betydelig bedre skannings- og skriveytelse. Derfor er det fornuftig å vurdere NVMe VPS server alternativer hvis du planlegger store overføringer.

-z komprimeringsparameteren gir fordeler for tekstfiler, logger og enkelte typer backup. Men for allerede komprimerte filer som zip, tar.gz, jpg, mp4 eller gzip, kan det bruke CPU uten å gi stort utbytte. Hvis du overfører store mediefiler mellom to kraftige servere med 1 Gbps båndbredde, kan du oppnå bedre ytelse uten å bruke -z. Omvendt kan -z gi betydelig besparelser med lav båndbredde og teksttunge filer.

For å begrense båndbredden kan --bwlimit brukes. For eksempel setter --bwlimit=50000 en grense på omtrent 50 MB/s. Dette er viktig for å unngå å kvele nettverkstrafikken til den aktive nettsiden. Å gjøre full hastighetsoverføring på produksjonsserveren i travle timer kan påvirke brukeropplevelsen negativt. Det er en god praksis å planlegge overføringer om natten, sette båndbreddegrenser og overvåke load average-verdiene under prosessen.

Sammenligning av rsync, scp, SFTP og FTP

Det finnes flere metoder for filoverføring; men hver metode har sine styrker og svakheter. Tabellen nedenfor oppsummerer hvilken verktøy som er mer passende under scenarier med store filer og serveroverføringer.

Som tabellen viser, skiller rsync seg spesielt ut ved gjentatte synkroniseringer og overføring av store data. scp er enkel og praktisk, men er ikke like kraftig som rsync når det gjelder å oppdage endrede filer. FTP er ikke egnet for moderne sikkerhetsstandarder når det brukes uten kryptering. FTP-tilgang i hosting-paneler kan være praktisk; men for kritiske overføringer mellom servere bør SSH-baserte metoder foretrekkes.

Eksempel på arbeidsflyt for å flytte en live nettside

Når du flytter en nettside fra en gammel server til en ny, er målet ikke bare å kopiere filene. DNS, database, SSL, PHP-versjon, filrettigheter og e-postkonfigurasjon må også kontrolleres. Nedenfor er et eksempel på arbeidsflyt for en nettside med store filer for å oppnå lav nedetid.

• Forbered webserver, PHP, database og nødvendige moduler på den nye serveren.
• Senk DNS TTL-verdien for domenet til for eksempel 300 sekunder før flyttingen. Du kan vurdere Domenesjekk og domeneadministrasjon siden for domeneforvaltning.
• Start den første rsync-overføringen mens nettstedet er aktivt. Dette trinnet overfører mesteparten av de store dataene.
• Ta en sikkerhetskopi av databasen og overfør den til den nye serveren.
• Sett nettstedet i kort vedlikeholdsmodus.
• Kjør den andre rsync-kommandoen for å synkronisere de siste endrede filene.
• Oppdater databasen igjen eller bruk en inkrementell strategi.
• Kontroller filrettighetene, nettstedets oppstart og logger på den nye serveren.
• Installer eller forny SSL-sertifikatet. For dette kan installasjon av SSL-sertifikat innholdet være nyttig.
• Omdiriger DNS-postene til den nye IP-adressen.

I denne metoden skjer den lengste overføringen av hovedfiler mens nettstedet kjører. Nedetid skjer kun under den siste synkroniseringen og DNS-overgangen. Denne tilnærmingen kan redusere nedetiden fra flere timer til bare noen få minutter for WordPress-nettsteder med store mediearkiv.

Kontroll av dataintegritet

Når overføringen er fullført, er det ikke nok at kommandoen er ferdig. Antall filer, størrelser og kritiske filer må kontrolleres. For enkel kontroll kan du sammenligne katalogstørrelsene på kilde- og målserveren ved å bruke du -sh kommandoen. Men på grunn av forskjeller i filsystemblokkene, kan verdiene se forskjellige ut. For mer detaljert kontroll kan rsync kjøres med de samme parameterne igjen. Hvis det ikke er noen nye filer som skal overføres, vil utdataene være på minimumsnivå.

For sjekk av sjekksum kan rsync -avc --dry-run /kilde/katalog/ bruker@mål-ip:/mål/katalog/ brukes. Her sammenligner -c filene med sjekksum i tillegg til tidsstempel og størrelse. Dette kan skape CPU- og diskbelastning med veldig store data, så vær forsiktig med bruken. Denne ekstra bekreftelsen gir trygghet for kritiske arkiver, database dump-filer eller kundedokumenter.

Hvis du har flyttet en nettside, må du også utføre kontroller på applikasjonsnivå. Hjemmesiden, administrasjonspanelet, bildefilopplasting, betalingsside, kontaktskjema og feillogger bør inspiseres. I e-handelsnettsteder er det ikke nok å bare flytte filene; betalingsintegrasjoner og cron-jobber må også testes på den nye serveren.

Vanlige feil og løsninger

Feilmelding: Permission denied

Denne feilen oppstår vanligvis på grunn av SSH-brukertillatelser, skrive tilgang til mål-katalogen eller nøkkelsjekk. Prøv først å opprette en normal SSH-tilkobling med samme bruker. Hvis tilkoblingen er vellykket, kan du teste å opprette en fil i mål-katalogen. Hvis nødvendig, kan du gi eierskapet av mål-mappen til den aktuelle brukeren med chown, eller planlegge en strategi basert på sudo.

Feilmelding: No space left on device

Overføringen stopper når det ikke er tilstrekkelig plass igjen på mål-disken. Kontroller diskpartisjonene med df -h. Noen ganger er ikke hoveddisken full, men /tmp eller målmonteringspunktet er fullt. Ved store overføringer kan loggfiler, gamle sikkerhetskopier og cache-mapper ryddes. For en permanent løsning kan det være nødvendig å utvide disken eller oppgradere til en VPS-plan med høyere kapasitet.

Feilmelding: Connection reset eller Broken pipe

Under langvarige overføringer kan det oppstå nettverksbrudd. Hvis du bruker --partial og --append-verify, kan du kjøre kommandoen på nytt for å fortsette der du slapp. I tillegg kan SSH keepalive-innstillinger være nyttige. På klientsiden kan en innstilling som ServerAliveInterval 60 redusere sjansen for at forbindelsen brytes.

Veldig treg overføring

Treghet kan skyldes antall filer, disk I/O-begrensninger, kompresjonsbelastning eller nettverkskapasitet. Hvis det er mange små filer, kan det i noen tilfeller være raskere å opprette et tar-arkiv først; men på den måten reduseres rsyncs fordel med filbaserte endringer. Test ved å fjerne -z parameteren for store og allerede komprimerte filer. I tillegg kan verktøy som iotop, htop og iftop hjelpe deg med å identifisere om flaskehalsen ligger i CPU, disk eller nettverk.

Beste sikkerhetspraksis

Sikkerhet må ikke overses under filoverføring mellom servere. Spesielt root-tilgang, SSH-nøkler og sikkerhetskopifiler bør betraktes som sensitive. Først og fremst anbefales det å bruke SSH-nøkkel i stedet for passordbasert innlogging. Tillatelsene for nøkkelfilene bør holdes strengt, private nøkler bør ikke deles, og de bør beskyttes med passphrase når det er mulig.

Å opprette en midlertidig bruker for overføringen og kun gi tilgang til nødvendige kataloger er en god metode. Etter at prosessen er fullført, kan brukerens rettigheter fjernes eller kontoen deaktiveres. Å begrense SSH-tilgang til bestemte IP-adresser reduserer også angrepsflaten. Brannmurregler, Fail2ban og oppdatert OpenSSH-versjon bør være blant de grunnleggende kontrollene.

Hvis database dump-filer, kundedokumenter eller arkiver som inneholder personlig informasjon skal overføres, bør unødvendige midlertidige filer ryddes bort etter overføringen på både kilde- og målserveren. I tillegg utgjør det en alvorlig sikkerhetsrisiko å la backup-filer som .sql, .zip eller .tar være i webrotkatalogen. Disse filene bør oppbevares i en katalog som er stengt for webtilgang, eller slettes etter at prosessen er avsluttet.

Bruke rsync for automatisk sikkerhetskopiering

rsync kan brukes ikke bare for engangs overføringer, men også for regelmessige sikkerhetskopier. For eksempel kan en cron-jobb defineres for å sende en spesifikk katalog til en backup-server hver natt. I dette scenariet opprettes det en sikker tilkobling uten passord ved hjelp av SSH-nøkkel, rsync overfører kun endrede filer, og en båndbreddegrense kan pålegges.

Eksempel på logikk: rsync -a --delete --bwlimit=30000 /var/www/site/ backup@backup-ip:/backup/site/. Denne kommandoen kan synkronisere mål-katalogen med kilden. Men på grunn av --delete parameteren, må det brukes med forsiktighet. Hvis en fil utilsiktet slettes i kilden, vil den også bli slettet på målet. Derfor bør kritiske sikkerhetskopieringsstrategier inkludere snapshot, daglige mapper eller versjoneringsstøttede løsninger.

I hosting-operasjoner er 3-2-1 sikkerhetskopieringsregelen en god referanse: Det bør være minst 3 kopier av dataene, fordelt på 2 forskjellige medier, med 1 kopi i et annet sted. rsync gjør kopieringsdelen av denne strategien mellom serverne praktisk. For mer omfattende infrastruktur kan du styrke planen din med Sikkerhetskopieringsløsninger og tjenester for bedrift hosting.

Siste sjekkliste

Før du starter overføringen av store filer, reduserer det risikoen for feil å følge denne korte listen. Denne listen bør spesielt bli en standard prosedyre i produksjonsmiljøer.

• Er rsync installert på kilde- og målserverne?
• Ble SSH-tilkoblingen testet med riktig bruker og port?
• Er det tilstrekkelig diskplass på målserveren?
• Ble den første prosessen kontrollert med --dry-run?
• Ble vedlikeholdsmodus og den siste synkroniseringen planlagt for den aktive nettsiden?
• Ble målveien bekreftet dersom --delete skal brukes?
• Vil filstørrelser, tillatelser og applikasjonstester bli utført etter overføringen?
• Vil midlertidige sikkerhetskopier og dump-filer bli sikkert ryddet bort?

Disse kontrollene kan virke enkle, men de vanligste problemene i virkeligheten oppstår ofte på grunn av feil målmappe, manglende tillatelser, utilstrekkelig diskplass og uplanlagt DNS-overgang. En planlagt rsync-prosess reduserer både overføringstiden og øker sjansen for vellykket migrering.

Ofte stilte spørsmål

Hvis tilkoblingen brytes ved bruk av rsync-kommandoen over SSH, starter overføringen på nytt?

Nei, hvis de riktige parameterne brukes, vil det ikke starte på nytt. --partial og --append-verify alternativene hjelper til med å bevare delvise store filer og bidrar til at overføringen fortsetter der den slapp når kommandoen kjøres på nytt. Likevel kan det være lurt å kontrollere diskplassen på målet og statusen til delvise filer før du kjører kommandoen på nytt for kritiske overføringer.

Kan man overføre databasen direkte med rsync?

rsync overfører filer; det er ikke sunt å kopiere aktive databasefiler direkte. For MySQL eller MariaDB bør mysqldump eller fysiske backupverktøy brukes, og den resulterende backup-filen bør overføres til målserveren med rsync. For live-systemer må det planlegges vedlikeholdsmodus eller replikasjonsstrategi for å sikre datakonsistens.

Er root-tilgang nødvendig på begge serverne for å bruke rsync?

Root-tilgang er ikke nødvendig. En bruker med skrivetillatelser til mål-katalogen er tilstrekkelig. Men hvis fil-eierskap, systemkataloger, ACL eller spesifikke tillatelser må bevares, kan høyere rettigheter være nødvendige. Av sikkerhetsmessige grunner er det best å bruke en bruker med begrensede rettigheter når det er mulig.

Er --delete parameteren trygg?

--delete er svært nyttig for å synkronisere målkatalogen med kilden, når den brukes riktig; men hvis den brukes på feil målmappe, kan det føre til tap av filer. Derfor bør kommandoer som inkluderer --delete alltid testes med --dry-run først, og kilde- og målveiene må bekreftes nøye.

Er rsync eller scp bedre for store filoverføringer?

For enkle engangskopier kan scp være tilstrekkelig; men for store filer, mange filer og gjentatte synkroniseringer er rsync vanligvis bedre. Fordi den kan oppdage endrede data, gjenoppta delvise overføringer, begrense båndbredden og tilby testmodus.

Oppsummering og neste skritt

Å overføre store filer mellom to servere med rsync-kommandoen over SSH er en rask, sikker og håndterbar metode. Med de riktige parameterne kan den motstå tilkoblingsbrudd, spare tid ved kun å overføre endrede filer og redusere nedetid under migrering av aktive nettsteder. For best resultat, start med SSH- og disk-kontroller, test med --dry-run, og planlegg hovedoverføringen nøye.

Hvis du planlegger å migrere til en ny server, høy kapasitet lagring eller mer ytelsesdyktig hosting-infrastruktur, kan du se på løsningene til Hostragons; med VPS, hosting, domene og SSL-alternativer, kan du gjøre migreringsprosessen din sikrere. Begynn med små tester for en problemfri overgang, mål resultatene, og planlegg den siste synkroniseringen nøye.