홈 서버 백업을 준비하며 네트워크 장비 정리하기

이 포스팅은 네이버 쇼핑 커넥트 활동의 일환으로, 판매 발생 시 수수료를 제공받습니다.

라즈베리파이를 홈 서버로 운영하며 Docker에 Gitea 같은 서비스를 올려 두고 있었습니다. 어느 날 서버가 반응하지 않아 모니터를 연결해 보니, microSD의 데이터가 손상돼 부팅에 실패하고 있었습니다.

microSD를 교체하고 OS를 다시 설치하면서, Git 저장소처럼 중요한 데이터가 들어 있는 컨테이너를 백업할 시스템이 필요하다고 느꼈습니다. 서비스 데이터를 NAS에 저장해 두면 다음에 microSD에 문제가 생겨도 복구할 때 가져올 수 있기 때문입니다. 백업을 준비하면서 NAS에 하드디스크를 하나 더 추가했고, 장비 위치와 케이블도 함께 정리했습니다.

NAS를 옮기며 장비를 다시 배치했습니다

예전에는 컴퓨터에 USB로 직접 연결하는 DAS를 사용했습니다. USB로 연결하는 방식이 불편해져, 네트워크를 통해 여러 단말에서 접근할 수 있는 NAS로 바꿨습니다. 파일 공유 기능을 지원하는 공유기에 하드디스크를 연결하거나, 미니 PC에 하드디스크를 연결하고 NAS용 OS를 설치해 자작 NAS를 구성하는 방법도 있습니다.

NAS는 책상 아래 선반 위에 두고 사용했습니다. 밤에는 작동 소음이 거슬려 사용하지 않을 때는 꺼 두었는데, 이번에 하드디스크를 추가하면서 살펴보니 선반 가운데도 약간 휘어 있었습니다. NAS를 옮기는 김에 작동 소음이 덜 들리는 곳에 자리를 잡고, 그 위치에 맞춰 스위치도 옮겼습니다. 다른 네트워크 장비에 연결된 케이블도 함께 정리했습니다.

예전에는 허브랙도 찾아봤지만, 생각보다 커서 배치가 제한되고 무게도 부담스러울 것 같아 구매하지 않았습니다.

장비를 배치할 때는 통풍도 함께 고려해야 합니다. NAS나 스위치처럼 켜 두는 장비는 계속 열을 내므로, 좁은 곳에 모아 두고 공기가 잘 흐르지 않으면 주변에 열이 쌓일 수 있습니다. 기기 사이에 간격을 두고 통풍구를 가리지 않아 더운 공기가 빠져나갈 공간을 확보하는 것이 좋습니다.

장비 위치에 맞춰 랜선 길이를 바꿨습니다

네트워크 연결 품질을 고려해 Wi-Fi를 지원하는 장비도 가능하면 유선으로 연결하고 있습니다. 장비를 옮기면 랜선 길이도 함께 살펴보게 되는데, 이번에는 NAS와 스위치 사이가 멀어져 기존 선이 닿지 않았습니다. 다른 곳에 쓰기에도 너무 짧아 버리고 새로 만들었습니다.

랜선은 필요한 길이로 구매할 수도 있습니다. 다만 표기된 길이만으로 실제 길이를 가늠하기 어려웠고, 당장 필요 없는 선까지 보관하다 보니 서랍에 여러 길이의 케이블이 쌓였습니다. 그래서 지금은 필요할 때마다 직접 만들고, 기존 선은 필요한 길이로 잘라 다시 쓰거나 쓸 곳이 없으면 버립니다.

직접 만들 때는 구입해 둔 Cat6 UTP 케이블 롤과 RJ45 커넥터, 압착기, 랜테스터를 사용합니다. 현재 스위치가 포트당 1Gbps를 지원하는 환경이라 NAS용 랜선은 가지고 있던 Cat6면 충분하다고 봤습니다.

커넥터 안에 들어가는 8가닥의 색상 순서를 정한 규격에는 T568A와 T568B가 있습니다. 다이렉트 케이블을 만들 때는 보통 양쪽 커넥터를 T568B 배열로 맞춥니다.

T568A

흰색·초록 줄 → 초록색 → 흰색·주황 줄 → 파란색 → 흰색·파랑 줄 → 주황색 → 흰색·갈색 줄 → 갈색

T568B

흰색·주황 줄 → 주황색 → 흰색·초록 줄 → 파란색 → 흰색·파랑 줄 → 초록색 → 흰색·갈색 줄 → 갈색

IP 주소는 공유기에서 관리합니다

장비의 IP 주소는 공유기에서 한곳에 모아 관리하고 있습니다. 주요 장비가 고정 IP를 받도록 MAC 주소별로 DHCP 주소를 예약하고, 단말은 주소를 자동으로 받도록 설정했습니다. 예약한 주소와 새 단말에 자동으로 할당할 주소도 구분해 두었습니다.

단말마다 직접 고정 IP를 설정하는 방법도 있지만, 제 환경에서는 네트워크 단말이 많지 않고 공유기도 자주 바꾸지 않습니다. 그래서 각 단말을 따로 설정하기보다 공유기에서 주소를 예약하는 쪽이 편했습니다.

백업 파일을 전달할 구조도 준비하고 있습니다

장비 정리와 함께 준비하는 것은 서비스 데이터를 NAS로 보내는 백업 구조입니다. 하드디스크도 오래 사용하다 보면 갑자기 인식되지 않거나 저장된 데이터를 읽지 못할 수 있어 하나를 더 추가했습니다. 두 하드는 RAID로 묶지 않고 각각 사용하며, 데이터의 중요도에 따라 저장 대상을 나누려고 합니다.

중요한 백업 파일은 양쪽 하드에 같은 사본을 남기고, 상대적으로 덜 중요한 데이터는 백업할 때마다 두 하드를 번갈아 선택해 시점별 백업 파일을 저장할 계획입니다. 양쪽 하드에 저장하는 요청은 두 곳 모두 저장돼야 성공으로 처리하고, 한쪽만 실패하면 이미 저장된 사본은 유지한 채 실패한 하드에만 같은 파일을 다시 보내도록 하려고 합니다.

이 파일들을 전달하는 역할은 스토리지 게이트웨이 backupd가 맡도록 구성할 생각입니다. 각 서비스가 저장장치 연결을 따로 구현하는 대신, 백업 파일을 같은 HTTP API로 보내면 backupd가 요청에서 지정한 저장 대상과 프로젝트별 경로로 전달하는 방식입니다. 백업 주기와 파일 생성은 각 서비스나 별도 백업 작업에서 맡고, backupd를 실행하는 중계 컨테이너는 파일 전달과 프로젝트별 접근 권한을 관리하도록 역할을 나누려고 합니다.

이렇게 하면 실제 저장 대상이 NAS나 DAS, 외장하드뿐 아니라 Google Drive나 S3 같은 클라우드 저장소가 될 수도 있습니다. 각 컨테이너는 파일이 어디에 어떤 방식으로 저장되는지 몰라도 같은 방식으로 요청하고, 저장 대상에 맞는 연결과 처리는 backupd가 맡도록 할 계획입니다.

NAS 계정은 서비스마다 따로 만들지 않고 backupd에서 하나만 사용하려고 합니다. 대신 각 서비스의 요청을 프로젝트별로 발급한 토큰으로 인증하고, 저장 경로도 그 토큰에 연결된 프로젝트의 허용 범위로 제한할 생각입니다. 범위 밖의 경로를 지정한 요청은 거부하도록 구성하려고 합니다.