스튜디오 엘

아이피타임 나스에서 나스로 안전하게 데이터 이전: rclone 백그라운드 실행

Authors

고객사가 나스를 교체할 때 기존 나스(NAS)에서 신규 나스로 사용 환경을 이전할 때 가장 신경써야 할 것이 많습니다. 특히 이기종 간 이전이라면 생각보다 여러가지 안전 장치를 마련해야 합니다.

대용량 데이터를 몇 시간 또는 며칠 동안 전송해야 하는데, 경우에 따라 그동안 SSH 창을 계속 열어두어야 할 수도 있고, 네트워크가 끊기더라도 다시 이어지는지 여부, 원본 NAS의 변경사항 반영 등 신경쓸 것이 여러 가지가 있습니다.

이번 글에서는 실제로 아이피타임(ipTIME) 나스에서 다른 아이피타임 나스로 데이터를 이전하면서 겪었던 문제점들과 해결 방법을 정리해 보겠습니다.

특히 시놀로지(Synology) DSM이나 큐냅(QNAP) QTS에 익숙한 분들이 아이피타임 나스에서 가장 당황하기 쉬운 부분인 영구 저장 경로, 짧은 PATH, 계정별 설정 파일, SSH 로그아웃 처리, 백그라운드 실행을 중심으로 설명하겠습니다.

목차

이번 데이터 이전의 구성

이번 작업은 새 아이피타임 나스를 고객사의 현장에 설치 후 기존 아이피타임 나스의 자료를 복사하는 형태였습니다.

구성은 다음과 같았습니다.

  • 원본: 기존 아이피타임 나스의 SMB 공유 폴더
  • 목적지: 새 아이피타임 나스의 로컬 공유 폴더
  • 이전 작업 실행 주체: 목적지 아이피타임 나스
  • 전송 도구: rclone
  • 접속 방식: SSH
  • 운영 방식: 목적지 나스에서 원본 나스를 rclone remote로 등록한 뒤 복사

IMPORTANT

rclone을 사용한 데이터 이전 시 sync와 copy는 비슷해 보이지만 다릅니다. 원본에 없는 파일을 목적지에서 삭제하면 안 되는 초기 이관 작업이라면 원본을 유지하고 목적지에만 추가·갱신하는 copy 방식이 더 안전합니다.

시놀로지나 큐냅보다 아이피타임 나스가 어려운 이유

시놀로지 DSM이나 큐냅 QTS는 패키지와 컨테이너, 예약 작업, 서비스 자동 시작을 어느 정도 일관된 방식으로 다룰 수 있습니다.

반면 아이피타임 나스는 모델과 펌웨어가 제공하는 기능에 따라 SSH에서 직접 확인해야 하는 부분이 많습니다.

예를 들어 아이피타임 - 시놀로지 간 데이터 이전일 경우 출발지와 목적지가 어디이든 시놀로지 나스 쪽에서 이전 작업을 실행하면 성능도 좋고 편리하게 작업이 가능합니다만, 이번 건은 출발지와 목적지 모두 아이피타임 나스였기 때문에 다소 복잡한 구성이 필요했습니다. 물론 중개해줄 Windows PC가 이전 내내 켜져있을 수 있다면 그걸 사용하는 방법도 있지만, 중개보다는 보내거나 받는 쪽에서 직접 실행해주는 쪽이 리소스 사용량도 적고 불필요한 네트워크 전송도 없습니다.

이번 장비에서 특히 문제가 되었던 부분은 다음과 같습니다.

  • 시스템 영역 중 일부가 재부팅 후 초기화되는 구조
  • 패키지 관리자가 제공하는 전역 실행 경로가 없음
  • SSH 비대화형 세션의 PATH가 매우 짧음
  • rclone 설정 파일이 실행 계정별로 분리됨
  • 대용량 작업을 등록·감시할 예약 작업 기능이 부족함
  • 일반적으로 백그라운드 실행을 위해 쓰는 nohup만으로는 완전한 SSH 로그아웃을 견디지 못함
  • 파일 복사 작업을 실행한 계정과 SSH로 접속한 계정이 달라질 수 있음

따라서 아이피타임 나스에서는 "명령어 하나를 실행하면 끝난다"라는 방식보다, 어디에 설치할 것인지, 어떤 계정으로 실행할 것인지, SSH가 끊긴 뒤에도 어떤 프로세스가 작업을 소유할 것인지를 먼저 정해야 합니다.

1. 먼저 재부팅 후에도 남는 경로를 찾기

작업 초기부터 /etc나 /root 아래에 설정을 저장하면 재부팅 후 사라질 수 있습니다.(이는 시놀로지 등 타사 나스도 마찬가지로, 관리형 운영체제 사용 시 공유 폴더 외의 데이터는 언제든 사라질 수 있습니다)

이번 장비에서는 애플리케이션과 설정을 다음과 같이 데이터 볼륨 아래에 배치했습니다. 참고로 system 폴더는 미리 아이피타임 나스 관리자 GUI 페이지에서 만들어둔 공유 폴더입니다.

/mnt/VOL1/system/nas-sync/
├── bin/rclone
├── rclone
├── private/rclone.conf
├── logs/
├── runtime/
└── syncctl

설정 파일은 일반 공유 파일처럼 두지 않고 실행 계정만 읽을 수 있도록 보호하는 게 좋습니다. 반대로 복사되는 일반 파일은 사용자가 SMB에서 사용할 수 있는 권한으로 생성되도록 별도 처리합니다. 단 아이피타임 나스의 경우 권한을 그대로 가져오면 상위 공유 폴더 권한을 상속받지 못할 수 있습니다. 이를 해결하기 위해 아이피타임 나스 관리 UI에서 각 공유 폴더 별 권한 상속 기능을 사용해야 합니다.

WARNING

이전 실행 나스에서는 재부팅 전후에 프로그램 파일, 설정 파일, 로그가 실제로 남아 있는지 확인해야 합니다. 설치 당시 실행됐더라도 재부팅 후 사라질 수 있습니다.

2. rclone을 설치했는데도 command not found가 나온 이유

rclone 설치 후 다음처럼 실행하면 오류가 날 수 있습니다.

rclone config

일반적으로 위와 같이 그냥 명령어를 입력하면 아래와 같은 오류를 보게 됩니다.

-bash: rclone: command not found

전역 PATH에 등록하지 않고 전용 경로에 설치했기 때문인데, 실행 파일의 전체 위치를 입력해야 합니다.

저희의 경우 실제 실행 파일은 다음 경로에 저장하였습니다.

/mnt/VOL1/system/nas-sync/bin/rclone

이 경우 설정 작업도 다음과 같이 실행하면 됩니다.

/mnt/VOL1/system/nas-sync/rclone config

이때 반드시 실제 작업을 실행할 계정으로 설정해야 합니다. root로 rclone 설정을 만들고 다른 계정으로 복사 작업을 실행하면 두 계정은 서로 다른 설정 파일을 바라볼 수 있습니다.

id
/mnt/VOL1/system/nas-sync/rclone version
/mnt/VOL1/system/nas-sync/rclone listremotes

많은 분들이 실행 주체를 확인하지 않고 기존에 만들어둔 remote가 없어지는 상황을 경험하시는데, 실행용 계정이 분리된 경우에는 계정만 맞추어 주어도 이런 문제는 피할 수 있습니다.

3. nohup만으로는 충분하지 않은 이유

아래는 일반적인 백그라운드 실행 방식인 nohup과 setsid를 사용하는 방식입니다.

nohup /bin/sh \
  /mnt/VOL1/system/nas-sync/nas_sync.sh \
  </dev/null >>/mnt/VOL1/system/nas-sync/logs/launcher.log 2>&1 &

이렇게 하면 일반적인 SSH 창 닫기를 할 경우에도 작업이 계속됩니다. 처음엔 그래서 성공한 것처럼 보일 수 있습니다.

그러나 SSH ControlMaster의 TCP 연결까지 완전히 종료한 뒤 다시 접속해 보면 나스가 로그아웃된 세션에 속한 프로세스를 정리하면서 rclone도 종료됐습니다.

아이피타임 나스에서 대용량 복사를 할 때 nohup만 믿으면 안 되는 이유입니다.

4. SSH와 독립된 systemd 작업으로 바꾸기

이번 장비에서는 syncctl이 내부적으로 systemd-run을 사용해 SSH 세션과 독립된 system service를 등록하도록 하였습니다.

실행 구조는 다음과 같습니다.

SSH 셸
  ↓
syncctl
  ↓  sudo로 작업 등록
systemd system service
  ↓  실제 실행 계정 권한으로 실행
동기화 앱
  ↓
rclone

실제 ssh에 접속 시 다음처럼 제어할 수 있습니다.

/mnt/VOL1/system/nas-sync/syncctl start
/mnt/VOL1/system/nas-sync/syncctl status
/mnt/VOL1/system/nas-sync/syncctl log

이렇게 하면 TCP 연결을 완전히 끊고 재접속한 뒤에도 후속 폴더 전송이 이어지고, 테스트 파일의 해시도 일치하는 것을 확인할 수 있습니다.

5. 실제 복사 전에 확인할 체크리스트

원본 나스

  • 원본 공유 폴더를 다른 사용자가 수정하고 있지 않은가(중간에 수정된 내용도 복사되지만, 일부 상황에서 문제가 될 수 있습니다)
  • SMB 계정이 실제로 읽기 가능한가
  • 대용량 파일과 한글 파일명이 정상적으로 조회되는가
  • 원본 나스의 저장 공간과 네트워크가 안정적인가

목적지 나스

  • 목적지 경로가 실제 데이터 볼륨 아래에 있는가
  • 설치 파일과 로그가 재부팅 후에도 남는 경로에 있는가
  • 실제 실행 계정이 목적지에 파일을 만들 수 있는가
  • 충분한 저장 공간이 남아 있는가

자주 하는 실수

&만 붙이면 백그라운드 실행이 되나요?

아닙니다. &는 셸을 기다리지 않게 할 뿐입니다. 터미널 입력, 출력, hangup 신호, 나스의 세션 정리 정책까지 분리해야 합니다.

이번 사례처럼 nohup과 setsid도 나스의 로그아웃 처리 방식에 따라 충분하지 않을 수 있습니다.

원본과 목적지 중 어디에 rclone을 설치하는 게 좋나요?

rclone은 출발지에 설치하는 것을 권장합니다만, 큰 성능 차이는 없으므로 목적지가 더 실행하기에 편리하다면 목적지에 설치해도 괜찮습니다.

root로 실행하면 권한 문제가 모두 해결되어서 편리하지 않나요?

root로 실행 시 모든 파일에 대한 접근이 기본적으로 주어지는 것은 장점이지만, 파일 소유권과 ACL이 업무용 계정의 예상과 달라질 수 있습니다. 전송은 실제 파일을 사용할 계정으로 실행하고, 서비스 등록처럼 꼭 필요한 작업에만 sudo를 사용하는 편이 관리하기 쉽습니다.

마무리

아이피타임 나스 간 데이터 이전에서 까다로운 부분은 rclone 명령어 자체보다는 다음 세 가지입니다.

  1. 설치 파일과 설정 파일을 재부팅 후에도 남는 경로에 둘 것
  2. PATH와 계정별 rclone 설정 파일을 정확히 맞출 것
  3. SSH 창이 아니라 SSH와 독립된 서비스가 전송 작업을 소유하게 할 것

특히 시놀로지나 큐냅에서는 GUI와 패키지 시스템이 대신 처리해 주던 부분을 아이피타임 나스에서는 직접 설계해야 합니다. 그렇다고 아이피타임 나스에서 대용량 이전이 불가능한 것은 아닙니다.

실제 경로와 실행 계정을 먼저 고정하고, 작은 테스트와 dry-run을 거친 뒤, SSH와 분리된 systemd 작업으로 실행하면 일주일 넘게 걸리는 이전 작업도 안정적으로 운영할 수 있습니다.

다만 데이터 이전에서 가장 중요한 원칙은 속도보다 복구 가능성입니다. 원본을 건드리지 않고 중단 후 다시 시작할 수 있는 구조를 먼저 만든 뒤 전송 속도를 최적화하는 것이 안전합니다.

데이터 이전을 준비하고 계시다면 다음 정보를 함께 알려주시면 환경에 맞는 이전 방식을 검토하는 데 도움이 됩니다.

  • 원본과 목적지 나스의 제조사·모델
  • 전체 데이터 용량과 파일 개수
  • 두 나스의 네트워크 연결 방식
  • 원본 공유 폴더의 SMB 접근 방식
  • 목적지에 기존 파일이 있는지 여부