Rocky Linux 9.x에서 Docker Compose v2로 구성하는 기준입니다. MinIO는 RELEASE.xxxx 계열을 전제로 하며, 실제 운영에서는 공식 이미지의 특정 릴리스 태그를 고정해두는 편이 좋습니다.
MinIO는 S3 API와 호환되는 오브젝트 스토리지입니다. AWS S3처럼 버킷을 만들고 접근 키로 파일을 올리고 내려받는 저장소를 홈서버 안에 직접 구성하는 방식입니다.
홈서버에서 MinIO를 쓰는 이유
홈서버에 MinIO를 올리면 일반 파일 공유와는 쓰임새가 조금 다릅니다. 네트워크 드라이브처럼 사람이 직접 폴더를 여는 목적보다는, 앱이나 백업 도구가 S3 저장소처럼 접근할 수 있는 공간을 만드는 데 가깝습니다.
사진 원본을 장기 보관하거나, 서버 설정 백업을 쌓아두거나, 개인 앱의 첨부파일 저장소로 붙이기 좋습니다. S3 호환 저장소를 지원하는 백업 도구와 셀프호스팅 앱이 많기 때문에, 경우에 따라 NAS 공유 폴더보다 연결하기 편합니다.
| 방식 | 주요 용도 | 강점 | 적합한 상황 |
|---|---|---|---|
| MinIO | S3 호환 오브젝트 스토리지 | 앱·백업 도구와 연결하기 쉬움 | 백업 파일, 사진 원본, 앱 데이터 저장 |
| Samba 공유 | 일반 파일 공유 | 윈도우 탐색기 접근이 쉬움 | 사람이 직접 파일을 옮기는 용도 |
| NFS | 리눅스 서버 간 파일 공유 | 서버 간 마운트에 익숙함 | 내부 리눅스 서버용 공유 저장소 |
데이터 디렉터리 먼저 정하기
MinIO는 컨테이너를 지워도 데이터가 남아야 하므로, 먼저 호스트에 데이터 디렉터리를 만들어둡니다. 여기서는 /srv/minio/data를 사용합니다.
권한은 운영 방식에 따라 달라질 수 있습니다. 다만 홈서버에서는 처음부터 데이터 위치를 분명히 잡아두는 편이 좋습니다. 나중에 디스크를 추가하거나 백업 경로를 정리할 때 MinIO 데이터가 어디에 있는지 바로 확인할 수 있습니다.
Docker Compose 파일 구성
작업 디렉터리를 만들고 compose.yml을 작성합니다.
아래는 기본 구성입니다. 관리자 계정과 비밀번호는 예시 그대로 쓰지 말고 반드시 변경해야 합니다.
9000은 S3 API 포트이고, 9001은 웹 콘솔 포트입니다. 내부망에서 먼저 테스트한다면 이 구성으로 시작할 수 있습니다.
브라우저에서 http://서버IP:9001로 접속하면 MinIO 콘솔이 열립니다. MINIO_ROOT_USER, MINIO_ROOT_PASSWORD에 넣은 값으로 로그인합니다.
버킷 생성과 접근 키 발급
콘솔에 접속하면 먼저 버킷을 만듭니다. 사진 원본용이면 photos, 백업 파일용이면 backup, 앱 첨부파일용이면 app-data처럼 목적이 드러나는 이름을 쓰는 편이 관리하기 쉽습니다.
버킷을 만든 뒤에는 루트 계정을 계속 쓰지 말고 별도 접근 키를 발급하는 흐름이 좋습니다. 콘솔의 Access Keys 메뉴에서 새 키를 만들고, 발급된 Access Key와 Secret Key를 백업 도구나 앱 설정에 넣으면 됩니다.
권한은 처음부터 넓게 주기보다 용도별로 나누는 편이 낫습니다. 백업 도구는 backup 버킷만 읽고 쓰게 하고, 사진 업로드 앱은 photos 버킷만 쓰게 하는 식입니다. 홈서버라도 루트 계정 상시 사용은 피하는 편이 운영하기 좋습니다.
외부 공개 전 내부망 테스트
MinIO를 외부에 바로 여는 것은 신중해야 합니다. 특히 9001 콘솔 포트를 인터넷에 그대로 노출하면 관리자 화면이 외부에 보이는 구조가 됩니다.
처음에는 공유기 내부망이나 VPN 안에서만 접속해보는 것을 권합니다. 외부 접속이 꼭 필요하다면 리버스 프록시, TLS 인증서, 접근 제한, 터널 구성을 먼저 정리해야 합니다. Cloudflare Tunnel이나 Nginx Proxy Manager를 붙일 수는 있지만, 그 전에 콘솔 포트와 API 포트를 어떻게 분리할지부터 정하는 게 좋습니다.
방화벽을 쓰고 있다면 내부망 테스트 기준으로 필요한 포트만 열어둡니다.
공개 서버라면 이 명령을 그대로 적용하기 전에 접근 범위를 먼저 확인해야 합니다.
백업 저장소로 쓸 때의 메모
MinIO는 백업 대상이라기보다 백업 파일을 받아주는 저장소로 볼 때 장점이 분명합니다. 여러 앱이 S3 방식으로 연결할 수 있고, 버킷 단위로 데이터를 나누기 쉬우며, 나중에 다른 S3 호환 도구로 옮기기도 비교적 수월합니다.
다만 디스크 하나에 MinIO만 올려두면 그 디스크가 고장 났을 때 백업 저장소도 같이 사라집니다. 중요한 자료라면 별도 디스크, 다른 서버, 외장 저장장치, 클라우드 중 하나로 한 번 더 복제하는 구조가 필요합니다.
홈서버에서 MinIO는 파일을 직접 열어보는 공유 폴더라기보다, 백업 도구와 개인 앱이 안정적으로 데이터를 밀어 넣는 개인 S3 저장소로 보는 편이 맞습니다. 이렇게 생각하면 구성 방향도 훨씬 분명해집니다.
답글 남기기