SSH를 통한 rsync 명령어로 두 서버 간 대용량 파일 빠르게 전송하기

SSH를 통한 rsync 명령어는 두 서버 간에 대용량 파일을 빠르고 안전하며 중단 없이 전송하는 데 사용되는 가장 실용적인 리눅스 방법 중 하나입니다. 특히 수백 GB 크기의 웹사이트 파일, 백업 아카이브, 미디어 폴더 또는 애플리케이션 데이터를 이동할 때 rsync는 변경된 블록만 전송하기 때문에 전통적인 복사 방법보다 상당한 속도 이점을 제공합니다. 기본 사용 원리는 다음과 같습니다: 소스 서버의 파일이 SSH 터널을 통해 대상 서버에 암호화되어 동기화됩니다; 연결이 끊어지면 작업이 중단된 곳에서 계속 진행됩니다.

서버 이동, 호스팅 업그레이드, 데이터 센터 교체 또는 백업 작업에서 속도만큼 데이터 무결성도 중요합니다. 대규모 아카이브를 한 번에 다운로드하고 다시 업로드하는 것은 시간 낭비일 뿐만 아니라 연결 오류가 발생할 경우 처음부터 다시 시작해야 할 수 있습니다. 이때 rsync가 개입하여 파일의 타임스탬프, 권한, 소유자 정보 및 폴더 구조를 유지할 수 있습니다. 따라서 리눅스 시스템 관리자, DevOps 팀 및 웹 호스팅 전문가들이 일상 작업에서 자주 선호합니다.

이 가이드에서는 두 리눅스 서버 간에 SSH를 통해 rsync로 대용량 파일을 이동하는 과정을 실제 명령어 예제를 통해 단계별로 다룰 것입니다. 또한 성능 향상 매개변수, 보안 점검, 오류 시나리오, 테스트 전송 방법 및 운영 환경으로 전환하기 전에 주의해야 할 사항을 공유할 것입니다. 새로운 VPS나 호스팅 환경으로 전환할 계획이 있다면 이 가이드를 시행하기 전에 소스 및 대상 서버에서 충분한 디스크 공간, SSH 접근 및 적절한 사용자 권한이 있는지 확인하세요. 관련 인프라 선택을 위해 Hostragons VPS 서버 솔루션 및 리눅스 호스팅 패키지 페이지를 참고하실 수 있습니다.

rsync란 무엇이며 대용량 파일 전송에 왜 선호되는가?

rsync는 파일과 디렉토리를 로컬 시스템 또는 원격 서버 간에 동기화하는 데 사용되는 강력한 명령줄 도구입니다. 가장 중요한 특징은 델타 전송 알고리즘입니다. 이 알고리즘은 파일 전체를 매번 다시 전송하는 대신 변경된 부분만 전송합니다. 예를 들어 80GB 크기의 백업 파일에서 단 2GB의 변경 사항이 있을 경우, 적절한 조건에서는 전체 파일을 다시 전송하는 대신 변경된 블록만 전송할 수 있습니다.

SSH는 전송을 암호화하여 rsync 명령어가 네트워크를 통해 데이터를 전송할 때 파일 내용을 일반 텍스트로 전송하지 않습니다. 이 기능은 특히 고객 데이터, 전자상거래 주문 기록, 미디어 아카이브, 데이터베이스 백업 및 특정 애플리케이션 파일에 중요합니다. 호스팅 세계에서 데이터 보안은 단순히 SSL 인증서에 국한되지 않습니다; 서버 간 전송 채널 또한 안전해야 합니다. 웹사이트 트래픽을 위해 SSL 인증서를 사용할 때, 서버 간 파일 전송에서도 SSH를 통한 암호화를 선택해야 합니다.

rsync는 FTP 또는 수동 다운로드-업로드 방법보다 더 유연합니다. 권한을 유지하고, 심볼릭 링크를 전송하며, 삭제된 파일을 대상에서도 삭제할 수 있고, 대역폭을 제한하며 전송 전 어떤 작업을 수행할지 테스트할 수 있습니다. 대용량 파일 전송과 같은 위험한 작업에서 이러한 제어 수준은 상당한 장점을 제공합니다.

언제 SSH를 통한 rsync 명령어를 사용해야 하는가?

SSH를 통한 rsync 명령어는 특히 대용량, 다수 또는 자주 변경되는 파일을 전송할 때 이상적입니다. 간단한 시각적 폴더의 경우 수동 SFTP가 충분할 수 있지만, 수천 개의 파일, 다양한 권한 및 대규모 아카이브가 관련된 경우 rsync는 훨씬 더 신뢰할 수 있는 선택이 됩니다.

구서버에서 새로운 VPS 서버로 웹사이트를 이동하는 경우.
WordPress uploads 폴더와 같이 수천 개의 미디어 파일이 포함된 디렉토리를 전송하는 경우.
일일, 주간 또는 월간 백업을 다른 서버로 복사하는 경우.
데이터 센터 또는 호스팅 제공업체를 변경하는 경우.
애플리케이션 파일을 운영 및 백업 환경 간에 동기화하는 경우.
연결이 끊어질 가능성이 있는 장시간 전송을 계획하는 경우.

예를 들어 250GB 크기의 미디어 폴더를 데스크톱 컴퓨터로 다운로드한 후 새로운 서버에 업로드하는 것은 두 개의 별도의 전송을 의미합니다. 이는 전체 시간을 늘릴 뿐만 아니라 집이나 사무실의 인터넷 연결을 병목 상태로 만들 수 있습니다. rsync를 사용하여 소스 서버에서 대상 서버로 직접 전송함으로써 이 중간 단계를 없앨 수 있습니다.

시작하기 전에 필요한 것들

성공적인 rsync 작업을 위해 명령어를 아는 것만으로는 충분하지 않습니다. 소스 및 대상 서버 조건을 점검하면 작업 중 발생할 수 있는 데이터 손실이나 중단된 전송 위험을 줄일 수 있습니다. 아래의 점검 사항은 운영 환경에서는 반드시 수행해야 합니다.

1. SSH 접근 확인

소스 서버에서 대상 서버로 SSH 연결이 가능해야 합니다. 표준 연결은 다음과 같이 테스트합니다: ssh 사용자@대상서버-ip. 만약 SSH가 다른 포트에서 작동하고 있다면 연결은 다음과 같이 시도됩니다: ssh -p 2222 사용자@대상서버-ip. 이 테스트가 성공하지 않으면 rsync도 작동하지 않습니다. 방화벽, Fail2ban, SSH 포트, 사용자 권한 및 비밀번호 또는 키 확인을 점검해야 합니다.

2. rsync 패키지가 설치되어 있는지 확인

대부분의 리눅스 배포판에 rsync가 기본적으로 설치되어 있지만, 여전히 확인이 필요합니다. Debian 및 Ubuntu 기반 시스템에서는 rsync --version 명령어를 사용할 수 있습니다. 설치되어 있지 않은 경우 apt install rsync로 설치할 수 있습니다. AlmaLinux, Rocky Linux 또는 CentOS 계열에서는 dnf install rsync 또는 yum install rsync 명령어를 사용합니다. Hostragons에서 리눅스 기반 VPS를 사용하고 있다면 설치는 보통 몇 초 내에 완료됩니다.

3. 디스크 공간 확인

대상 서버에 충분한 여유 공간이 없다면 전송이 중단됩니다. 소스 디렉토리의 크기를 확인하기 위해 du -sh /소스/디렉토리 형식을 사용할 수 있습니다. 대상에서는 df -h 명령어로 디스크 상태를 점검해야 합니다. 실제로는 파일 크기만큼의 공간뿐만 아니라 임시 파일과 로그를 위한 공간도 남겨두어야 합니다. 예를 들어 500GB의 데이터를 전송하려면 최소 550-600GB의 사용 가능한 공간을 계획하는 것이 더 건강합니다.

4. 중요한 서비스 및 변경되는 파일 계획하기

실시간으로 운영되는 웹사이트에서는 파일이 전송 중에 변경될 수 있습니다. 특히 사용자 업로드, 캐시 폴더 및 로그 파일은 지속적으로 업데이트됩니다. 대규모 전송에서는 먼저 주요 데이터가 전송되고, 이후 유지 보수 모드로 전환하여 최종 rsync를 더 실행합니다. 이렇게 하면 중단 시간을 몇 분으로 줄일 수 있습니다. WordPress 사이트의 경우 워드프레스 호스팅 이전 가이드와 같은 지원 콘텐츠로 작업 계획을 완성할 수 있습니다.

기본 rsync 명령어: 두 서버 간 파일 전송

가장 자주 사용하는 기본 구조는 다음과 같습니다: rsync -avz /소스/디렉토리/ 사용자@대상-ip:/대상/디렉토리/. 여기서 -a는 아카이브 모드로 권한, 타임스탬프, 심볼릭 링크와 같은 정보를 유지하려고 합니다. -v는 자세한 출력을 제공합니다. -z는 전송 중 압축을 적용합니다. 디렉토리의 마지막에 있는 슬래시는 중요한 세부 사항입니다. /소스/디렉토리/라고 작성하면 디렉토리의 내용이 대상에 복사되며; /소스/디렉토리라고 쓰면 디렉토리 자체가 대상 아래에 생성됩니다.

예시 시나리오를 생각해 보겠습니다: 구 서버의 /var/www/site/public_html/ 폴더에 있는 180GB의 웹 파일을 새로운 서버의 /var/www/site/public_html/ 디렉토리로 이동하고 싶습니다. 명령어는 다음과 같이 작동합니다: rsync -avz /var/www/site/public_html/ root@203.0.113.20:/var/www/site/public_html/. 이 작업은 소스 서버에서 대상 서버로 SSH를 통해 파일을 전송합니다.

root 사용을 원하지 않으면, 대상 서버의 관련 디렉토리에 쓰기 권한이 있는 별도의 사용자를 만드는 것이 더 안전합니다. 예를 들어 deploy라는 사용자를 사용할 수 있으며 필요한 디렉토리 소유권을 이에 맞게 설정할 수 있습니다. 운영 환경에서는 root로 작업을 수행하는 것이 편리하지만 보안 측면에서 제한된 권한을 가진 사용자를 선호하는 것이 좋습니다.

다른 SSH 포트를 사용하는 경우 명령어는 어떻게 되어야 하나?

보안을 위해 SSH 포트가 22 대신 다른 포트에서 작동할 수 있습니다. 이 경우 rsync 내에서 SSH 매개변수를 지정해야 합니다. 예: rsync -avz -e ssh -p 2222 /소스/디렉토리/ 사용자@대상-ip:/대상/디렉토리/. 그러나 명령줄에서 -e 매개변수의 값은 함께 사용해야 합니다. 올바른 사용 원리는 다음과 같습니다: rsync -avz -e 'ssh -p 2222' /소스/디렉토리/ 사용자@대상-ip:/대상/디렉토리/.

JSON 및 일부 패널에서 단일 따옴표 사용이 다르게 동작할 수 있으므로 터미널에서 직접 입력할 때 따옴표가 올바른지 확인하세요. 만약 SSH 키로 연결을 시도하는 경우 -i 매개변수를 추가할 수도 있습니다: rsync -avz -e 'ssh -p 2222 -i /root/.ssh/id_rsa' /소스/디렉토리/ 사용자@대상-ip:/대상/디렉토리/. 이 방법은 자동화 및 cron 기반 백업 작업에서 자주 사용됩니다.

전송 전 테스트: --dry-run 사용하기

대량 데이터를 전송하기 전에 수행해야 할 가장 전문적인 단계 중 하나는 --dry-run을 사용하는 것입니다. 이 매개변수는 파일을 실제로 복사하지 않고 어떤 파일이 전송될지를 보여줍니다. 이렇게 하면 잘못된 디렉토리, 잘못된 대상 경로 또는 예상치 못한 삭제 작업을 미리 감지할 수 있습니다.

예시 테스트 명령어: rsync -avz --dry-run /var/www/site/ 사용자@대상-ip:/var/www/site/. 출력에서 전송할 파일, 생성할 디렉토리 및 작업 요약을 볼 수 있습니다. 만약 --delete 매개변수를 사용할 경우 dry-run은 더욱 중요해집니다. --delete는 소스에 없는 파일을 대상에서 삭제할 수 있기 때문입니다. 올바르게 사용되면 대상을 완벽하게 미러링하지만, 잘못된 디렉토리에서 사용하면 심각한 데이터 손실을 초래할 수 있습니다.

전문가의 작업 순서는 일반적으로 다음과 같습니다: 먼저 SSH 테스트를 진행한 후, 디스크 공간을 확인하고, 그 다음 rsync --dry-run을 실행한 후, 작은 디렉토리로 실제 테스트를 진행하고, 마지막으로 주요 전송을 시작합니다. 이 접근 방식은 몇 분의 추가 시간이 필요하지만, 수 시간에 걸친 잘못된 전송을 방지할 수 있습니다.

성능을 위한 압축, 대역폭 및 암호화 설정

rsync의 성능은 단순히 파일 크기에 의존하지 않습니다. 서버의 CPU 성능, 디스크 유형, 네트워크 지연, 대역폭 및 파일 수 또한 중요합니다. 매우 많은 작은 파일은 한 개의 큰 파일보다 더 느리게 전송될 수 있습니다. 각 파일마다 메타데이터 처리가 이루어지기 때문입니다. NVMe 디스크가 장착된 VPS 환경에서는 파일 스캔 및 쓰기 성능이 눈에 띄게 더 나을 수 있습니다. 따라서 집중적인 전송을 계획하고 있다면 NVMe VPS 서버 옵션을 고려하는 것이 좋습니다.

-z 압축 매개변수는 텍스트 파일, 로그 및 일부 백업 유형에서 유리합니다. 그러나 이미 압축된 zip, tar.gz, jpg, mp4 또는 gzip 파일에서는 CPU 소비가 발생해도 큰 이점을 제공하지 않을 수 있습니다. 1 Gbps 연결을 가진 두 개의 강력한 서버 간에 대용량 미디어 파일을 전송할 때 -z를 사용하지 않고 더 나은 성능을 얻을 수 있습니다. 반대로 낮은 대역폭과 텍스트 중심의 파일에서는 -z가 상당한 절약을 제공할 수 있습니다.

대역폭을 제한하기 위해 --bwlimit를 사용할 수 있습니다. 예를 들어 --bwlimit=50000은 약 50 MB/s 수준의 제한을 설정합니다. 이는 실시간 웹사이트의 네트워크 트래픽을 방해하지 않기 위해 중요합니다. 운영 서버에서 혼잡한 시간에 최대 속도로 전송을 수행하면 방문자 경험에 부정적인 영향을 미칠 수 있습니다. 전송을 야간 시간으로 계획하고, 대역폭 제한을 설정하며, 작업 중에 load average 값을 모니터링하는 것이 좋은 방법입니다.

rsync, scp, SFTP 및 FTP 비교

파일 전송을 위한 여러 방법이 있지만, 각 방법의 강점과 약점은 다릅니다. 아래 표는 대용량 파일 및 서버 전송 시나리오에서 어떤 도구가 언제 더 적합한지를 요약합니다.

rsync, scp, SFTP 및 FTP 비교
방법	보안	중단 지점에서 계속	대용량 파일 성능	가장 적합한 사용
rsync + SSH	높음	강력함	매우 좋음	서버 전송, 백업, 동기화
scp	높음	제한적	중간	소수의 파일을 빠르게 복사
SFTP	높음	클라이언트에 따라 다름	중간	수동 파일 관리
FTP	낮음	클라이언트에 따라 다름	변동적	보안이 중요하지 않은 구형 시스템

표에서 볼 수 있듯이 rsync는 특히 반복적인 동기화 및 대량 데이터 전송에서 두드러집니다. scp는 간단하고 사용하기 편리하지만, 변경된 파일을 똑똑하게 감지하는 데 있어 rsync만큼 강력하지 않습니다. FTP는 암호화 없이 사용될 경우 현대 보안 기준에 적합하지 않습니다. 호스팅 패널에서는 FTP 접근이 실용적일 수 있지만, 서버 간의 중요한 전송에서는 SSH 기반 방법을 선호해야 합니다.

실시간 웹사이트 전송을 위한 예시 작업 흐름

웹사이트를 구서버에서 새로운 서버로 전송할 때의 목적은 단순히 파일을 복사하는 것이 아닙니다. DNS, 데이터베이스, SSL, PHP 버전, 파일 권한 및 이메일 구성도 점검해야 합니다. 아래는 대규모 파일이 포함된 웹사이트에 대한 낮은 중단 시간을 지닌 예시 작업 흐름입니다.

새 서버에서 웹 서버, PHP, 데이터베이스 및 필요한 모듈을 준비합니다.
도메인의 DNS TTL 값을 전송 전 300초와 같은 낮은 값으로 설정합니다. 도메인 관리에 대한 도메인 조회 및 관리 페이지를 참고할 수 있습니다.
사이트가 라이브인 동안 첫 번째 rsync 전송을 시작합니다. 이 단계에서 대부분의 대용량 데이터가 전송됩니다.
데이터베이스 백업을 받고 새로운 서버로 전송합니다.
사이트를 짧은 시간 동안 유지 보수 모드로 전환합니다.
두 번째 rsync 명령어를 실행하여 변경된 마지막 파일들을 동기화합니다.
데이터베이스를 다시 최신 상태로 유지하거나 증분 전략을 사용합니다.
새 서버에서 파일 권한, 사이트 개방 및 로그를 확인합니다.
SSL 인증서를 설치하거나 갱신합니다. 이를 위해 SSL 인증서 설치 내용이 유용할 수 있습니다.
DNS 기록을 새로운 IP 주소로 포워딩합니다.

이 방법에서는 가장 긴 소요 시간이 드는 주요 파일 전송이 사이트가 작동하는 동안 수행됩니다. 중단은 마지막 동기화와 DNS 전환 중에만 발생합니다. 대규모 미디어 아카이브가 있는 WordPress 사이트에서는 이 접근 방식이 수시간에 걸친 중단을 몇 분으로 줄일 수 있습니다.

데이터 무결성 점검

전송이 완료되었다고 해서 명령어가 끝났다고만 할 수는 없습니다. 파일 수, 크기 및 중요한 파일을 점검해야 합니다. 간단한 점검을 위해 소스와 대상에서 du -sh 명령어를 통해 디렉토리 크기를 비교할 수 있습니다. 그러나 파일 시스템 블록 차이로 인해 값이 정확하게 동일하지 않을 수 있습니다. 보다 세부적인 점검을 위해 rsync를 동일한 매개변수로 다시 실행할 수 있습니다. 만약 전송할 새로운 파일이 없다면 출력은 최소화됩니다.

체크섬 검증을 위해 rsync -avc --dry-run /소스/디렉토리/ 사용자@대상-ip:/대상/디렉토리/를 사용할 수 있습니다. 여기서 -c 매개변수는 파일을 타임스탬프와 크기 외에 체크섬으로 비교합니다. 매우 큰 데이터에서는 CPU와 디스크 부하를 유발할 수 있으므로 주의해서 사용해야 합니다. 중요한 아카이브, 데이터베이스 덤프 파일 또는 고객 문서에 대해서는 이 추가 검증이 신뢰를 줍니다.

웹사이트를 이동했다면 애플리케이션 수준에서도 점검을 수행해야 합니다. 홈페이지, 관리 패널, 이미지 업로드, 결제 페이지, 연락처 양식 및 오류 로그를 검토해야 합니다. 전자상거래 사이트에서는 단순히 파일 이동만으로는 충분하지 않으며, 결제 통합 및 cron 작업도 새로운 서버에서 테스트해야 합니다.

일반적인 오류 및 해결 방법

Permission denied 오류

이 오류는 일반적으로 SSH 사용자 권한, 대상 디렉토리 쓰기 권한 또는 키 검증으로 인해 발생합니다. 먼저 동일한 사용자로 일반 SSH 연결을 시도해 보세요. 연결이 성공하면 대상 디렉토리에 파일 생성 테스트를 해보세요. 필요 시 대상 폴더 소유권을 chown으로 해당 사용자에게 부여하거나 sudo 기반 전략을 계획할 수 있습니다.

No space left on device 오류

대상 디스크에 충분한 공간이 없으면 전송이 중단됩니다. df -h로 디스크 파티션을 점검하세요. 때때로 기본 디스크는 가득 차지 않았지만 /tmp 또는 대상 마운트 지점이 가득 찼을 수 있습니다. 대규모 전송에서는 로그 파일, 오래된 백업 및 캐시 폴더를 정리할 수 있습니다. 영구적인 해결책으로는 디스크 용량을 늘리거나 더 높은 용량의 VPS 플랜으로 변경해야 할 수 있습니다.

Connection reset 또는 Broken pipe 오류

장시간 전송 중에는 네트워크 연결이 끊길 수 있습니다. --partial 및 --append-verify를 사용하고 있다면 명령어를 다시 실행하여 중단된 지점에서 계속할 수 있습니다. 또한 SSH keepalive 설정이 도움이 될 수 있습니다. 클라이언트 측에서 ServerAliveInterval 60과 같은 설정을 통해 연결이 유휴 상태에서 끊어지는 것을 줄일 수 있습니다.

전송 속도 저하

느림은 파일 수, 디스크 I/O 제한, 압축 부하 또는 네트워크 용량으로 인해 발생할 수 있습니다. 많은 작은 파일이 있는 경우 먼저 tar 아카이브를 생성하는 것이 일부 경우에 더 빠를 수 있지만, 이 경우 rsync의 파일 기반 변경 감지 이점이 줄어듭니다. 대형 및 이미 압축된 파일에서는 -z 매개변수를 제거하여 테스트해 보세요. 또한 iotop, htop 및 iftop과 같은 도구를 사용하여 병목이 CPU, 디스크 또는 네트워크 측에서 발생하고 있는지를 확인하세요.

보안을 위한 모범 사례

서버 간 파일 전송 중에는 보안을 간과해서는 안 됩니다. 특히 root 접근, SSH 키 및 백업 파일은 민감하게 다뤄야 합니다. 우선 비밀번호 기반 로그인 대신 SSH 키를 사용하는 것이 좋습니다. 키 파일의 권한은 엄격하게 유지하고, 개인 키는 공유하지 말고, 가능하면 패스프레이즈로 보호해야 합니다.

전송을 위해 임시 사용자를 생성하고 필요한 디렉토리만 접근할 수 있도록 하는 것이 좋은 방법입니다. 작업이 끝난 후 이 사용자의 권한을 제거하거나 계정을 비활성화할 수 있습니다. SSH 접근을 특정 IP 주소로 제한하는 것도 공격 표면을 줄이는 데 도움이 됩니다. 방화벽 규칙, Fail2ban 및 최신 OpenSSH 버전은 기본 점검 사항에 포함되어야 합니다.

데이터베이스 덤프 파일, 고객 문서 또는 개인 데이터가 포함된 아카이브를 이동할 경우 전송 후 소스 및 대상에서 불필요한 임시 파일을 정리해야 합니다. 또한 웹 루트 디렉토리 아래에 .sql, .zip 또는 .tar와 같은 백업 파일을 남기는 것은 심각한 보안 위험을 초래합니다. 이러한 파일은 가능하면 웹 접근이 차단된 디렉토리에 보관하거나 작업이 끝난 후 삭제해야 합니다.

자동 백업을 위한 rsync 사용

rsync는 단지 일회성 전송뿐만 아니라 정기적인 백업에도 사용할 수 있습니다. 예를 들어 매일 특정 폴더를 백업 서버로 전송하기 위해 cron 작업을 정의할 수 있습니다. 이 시나리오에서는 SSH 키로 비밀번호 없이 안전한 연결을 설정하고, rsync는 변경된 파일만 전송하며, 대역폭 제한을 적용할 수 있습니다.

예시 구조: rsync -a --delete --bwlimit=30000 /var/www/site/ backup@백업-ip:/backup/site/. 이 명령어는 대상 디렉토리를 소스와 동기화할 수 있습니다. 그러나 --delete 매개변수 때문에 주의해서 사용해야 합니다. 실수로 소스에서 삭제된 파일이 대상에서도 삭제될 수 있습니다. 따라서 중요한 백업 전략에서는 스냅샷, 일일 폴더 또는 버전 관리 지원 솔루션을 선호해야 합니다.

호스팅 작업에서는 3-2-1 백업 규칙이 좋은 기준입니다: 데이터의 최소 3개 복사본을 2개의 서로 다른 매체에서, 1개 복사본은 다른 위치에 보관해야 합니다. rsync는 이 전략의 서버 간 복사 부분을 실용적으로 만들어 줍니다. 보다 포괄적인 인프라를 위해 백업 솔루션 및 기업 호스팅 서비스 콘텐츠로 계획을 강화할 수 있습니다.

최종 점검 리스트

대용량 파일 전송 작업을 시작하기 전에 아래의 간단한 리스트를 적용하면 오류 위험을 줄일 수 있습니다. 이 리스트는 특히 운영 환경에서 표준 절차로 삼아야 합니다.

소스 및 대상 서버에 rsync가 설치되어 있나요?
SSH 연결이 올바른 사용자와 포트로 테스트되었나요?
대상 서버에 충분한 디스크 공간이 있나요?
첫 번째 작업이 --dry-run으로 확인되었나요?
라이브 사이트에 대한 유지 보수 모드와 최종 동기화가 계획되었나요?
--delete를 사용할 경우 대상 경로가 확실히 검증되었나요?
전송 후 파일 크기, 권한 및 애플리케이션 테스트가 수행될 것인가요?
임시 백업 및 덤프 파일이 안전하게 정리될 것인가요?

이 점검 사항들은 간단해 보이지만 실제로 가장 많이 발생하는 문제들은 일반적으로 잘못된 대상 디렉토리, 누락된 권한, 부족한 디스크 공간 및 계획되지 않은 DNS 전환에서 발생합니다. 계획된 rsync 프로세스는 전송 시간을 단축할 뿐만 아니라 복구 가능성을 높입니다.

자주 묻는 질문

SSH를 통한 rsync 명령어로 연결이 끊기면 전송이 처음부터 다시 시작되나요?

아니요, 올바른 매개변수를 사용하면 처음부터 다시 시작되지 않습니다. --partial 및 --append-verify 옵션은 중단된 대용량 파일을 보호하고 명령어가 다시 실행될 때 전송이 중단된 지점에서 계속 진행될 수 있도록 도와줍니다. 그럼에도 불구하고 중요한 전송에서는 명령어를 다시 실행하기 전에 대상 디스크 공간과 중단된 파일 상태를 확인하는 것이 좋습니다.

rsync로 데이터베이스를 직접 전송할 수 있나요?

rsync는 파일을 전송하지만, 활성 데이터베이스 파일을 직접 복사하는 것은 건강하지 않습니다. MySQL이나 MariaDB의 경우 mysqldump 또는 물리적 백업 도구를 사용하고, 생성된 백업 파일을 rsync로 대상 서버로 전송해야 합니다. 라이브 시스템에서 데이터 일관성을 위해 유지 보수 모드 또는 복제 전략을 계획해야 합니다.

rsync를 사용하려면 두 서버 모두 root 접근이 필요합니까?

Root 접근은 필수가 아닙니다. 대상 디렉토리에 쓰기 권한이 있는 사용자면 충분합니다. 그러나 파일 소유권, 시스템 디렉토리, ACL 또는 특정 권한을 보호해야 할 경우 더 높은 권한이 필요할 수 있습니다. 보안 측면에서 가능한 한 제한된 권한 사용자를 통해 작업을 수행하는 것이 더 올바릅니다.

--delete 매개변수는 안전한가요?

--delete가 올바르게 사용되면 대상 디렉토리를 소스와 완벽하게 동기화하는 데 매우 유용하지만, 잘못된 대상 디렉토리에서 사용하면 파일 손실을 초래할 수 있습니다. 따라서 --delete가 포함된 명령어는 반드시 먼저 --dry-run으로 테스트되고, 소스 및 대상 경로가 주의 깊게 검증되어야 합니다.

대용량 파일 전송에서 rsync가 scp보다 더 나은가요?

단일 소규모 복사에서는 scp가 충분할 수 있지만, 대용량 파일, 많은 파일 및 반복적인 동기화에서는 rsync가 일반적으로 더 나은 성능을 보여줍니다. 변경된 데이터를 감지하고, 중단된 전송을 계속할 수 있으며, 대역폭을 제한하고, 테스트 모드를 제공합니다.

요약 및 다음 단계

SSH를 통한 rsync 명령어로 두 서버 간에 대용량 파일을 전송하는 것은 빠르고 안전하며 관리할 수 있는 방법입니다. 올바른 매개변수를 사용하면 연결이 끊어져도 견딜 수 있으며, 변경된 파일만 전송하여 시간을 절약하고 라이브 사이트 전송 과정에서 중단을 줄일 수 있습니다. 최상의 결과를 얻기 위해 먼저 SSH 및 디스크 점검을 수행하고, --dry-run으로 테스트한 후, 주요 전송을 계획적으로 실행하세요.

새로운 서버로의 전환, 고용량 저장소 또는 더 성능 좋은 호스팅 인프라를 계획하고 있다면 Hostragons 솔루션을 검토하여 VPS, 호스팅, 도메인 및 SSL 옵션으로 이동 과정을 더 안전하게 만들 수 있습니다. 문제 없는 전환을 위해 작은 테스트로 시작하여 측정하고 최종 동기화를 계획적으로 진행하세요.