atmigtnca.dev
지식

[NetApp] 폐기 예정 스토리지, 밀기 전에 시리얼 콘솔로 열어봤더니

"안 쓰는 장비니까 디스크 밀고 재활용하면 된다" — 폐기 예정이라는 오래된 NetApp 스토리지 어레이를 넘겨받으면서 들은 말이다. 그런데 초기화 작업 전에 혹시나 하고 시리얼 콘솔로 안을 들여다봤더니, 학내 LMS(무들)의 운영 실데이터 19TB와 학생·교수 개인정보 CSV가 그대로 살아 있었다. 이 글은 그 점검의 전 과정이다 — 시리얼 콘솔 접속에서 겪는 자잘한 함정들, 오래 꺼져 있던 NetApp을 깨울 때 만나는 경고들, 그리고 "폐기 장비"를 밀기 전에 반드시 확인해야 할 것들.

장비: NetApp FAS2240-4, 2017년에 멈춘 시간

대상은 NetApp FAS2240-4. 4U 섀시 하나에 컨트롤러 2개, 전원/팬 4개, 디스크 24개가 들어가는 통합형 HA 구성이다. 겉만 보면 위·아래 두 대의 독립 어레이처럼 생겼지만, 실제로는 한 섀시의 컨트롤러 2개가 백플레인으로 내부 연결되어 디스크 24개를 공유한다. 외부 케이블이 없다고 "연결 안 된 별개 장비"로 판단하면 안 된다는 뜻이고, 뒤에서 중요해지는 사실이지만 — 데이터는 한 벌이다.

┌──────────────────────────────────────────┐
│  FAS2240-4 (4U 단일 섀시)                │
│  ┌────────────────────────────────────┐  │
│  │  디스크 24개 (1TB HDD 14 + 4TB HDD 10) │  ← 두 컨트롤러가 공유
│  ├──────────────────┬─────────────────┤  │
│  │  컨트롤러 A      │  컨트롤러 B     │  │  ← 백플레인 내부 연결
│  │  (전원 꺼짐)     │  (가동 중)      │  │     (외부 케이블 없음)
│  └──────────────────┴─────────────────┘  │
└──────────────────────────────────────────┘

OS는 Data ONTAP 8.2.5P1 7-Mode, 2017년 빌드. 관리 IP는 물론 root 비밀번호도 전해진 게 없어서, 진입 경로는 시리얼 콘솔뿐이었다.

1. 시리얼 콘솔 접속 — NetApp은 9600이다

macOS에 USB-시리얼 어댑터를 꽂고 장치를 확인한다. 접속할 때는 tty.*가 아니라 cu.* 장치를 쓴다.

ls -1 /dev/tty.* /dev/cu.*
# /dev/cu.usbserial-XXXXXXXX 형태로 보이면 인식된 것

screen /dev/cu.usbserial-XXXXXXXX 9600

여기서 첫 번째 함정: NetApp의 콘솔 보드레이트는 9600이다. 요즘 네트워크 장비는 115200이 많아서 습관적으로 115200을 넣으면 깨진 문자만 나온다. 접속 후 화면이 비어 있으면 Enter를 두세 번 눌러야 프롬프트가 나온다.

두 번째 함정: 접속하자마자 [screen is terminating]이 뜨며 튕기는 경우. 이건 장비 문제가 아니라 이전 screen 세션이 detach 상태로 시리얼 포트를 점유 중인 경우가 대부분이다. 터미널 창을 그냥 닫으면 screen 세션이 살아남아 포트를 계속 잡고 있는다.

screen -ls                          # 남아있는 세션 확인
lsof /dev/cu.usbserial-XXXXXXXX     # 포트를 잡은 프로세스 확인
screen -S <PID> -X quit             # 해당 세션 종료

교훈: screen에서 나올 때는 창을 닫지 말고 반드시 Ctrl+A → k → y로 종료할 것. (잠깐 자리를 뜰 땐 Ctrl+A → d로 detach.)

2. 부팅 — NVRAM 배터리 경고와 마주치다

오래 꺼져 있던 NetApp을 켜면 높은 확률로 이 경고 앞에서 부팅이 멈춘다.

WARNING:  The battery is unfit to retain data during a power
          outage.  This is likely because the battery is
          discharged but could be due to other temporary
          conditions.
          When the battery is ready, the boot process will
          complete and services will be engaged.
          To override this delay, press 'c' followed by 'Enter'

NetApp은 쓰기 데이터를 NVRAM에 캐싱하고, 정전 시 그 데이터를 지키는 게 NVRAM 배터리의 역할이다. 배터리가 방전돼 있으면 "충전될 때까지 부팅을 기다리는 것"이 기본 동작이다. 장비가 몇 달씩 꺼져 있었다면 방전은 자연스러운 현상.

선택지는 둘이다. 대기(전원 인가 상태로 두면 보통 수십 분 내 충전 후 자동으로 부팅 재개 — 운영 데이터가 있는 장비라면 이쪽) 또는 강제 부팅(c + Enter → 확인 프롬프트에서 y). 강제 부팅을 고르면 이런 경고를 한 번 더 받는다.

CAUTION: Using this appliance without NVRAM
         battery backup coupled with a power
         failure condition CAN CAUSE DATA LOSS.
Are you sure you want to continue (y or n)?

배터리 충전 전까지는 정전 시 미기록 데이터가 날아갈 수 있다는 뜻이다. 참고로 부팅 후 몇 시간이 지나도 경고가 계속되면 충전 문제가 아니라 배터리 수명 종료이므로 교체 대상이다 (7-Mode는 environment status, clustered ONTAP은 system node environment sensors show로 확인).

이날은 부팅 과정에서 자잘한 이벤트가 더 있었다. 디스크 쉘프가 AC Fail(전원 차단) 상태여서 쉘프 PSU에 전원을 넣어 복구했고, root 비밀번호가 미상이라 부팅 메뉴의 비밀번호 변경 옵션(option 3, Change password)으로 임시 비밀번호를 설정해 들어갔다. 오래 방치된 장비를 깨울 때는 이런 것들이 겹겹이 쌓여 있다고 보면 된다.

3. 점검 — HA는 이미 반쪽이었다

들어가서 제일 먼저 확인한 것은 HA 상태다. cf status와 sysconfig로 확인한 결과가 이랬다.

항목 상태 의미
Controller Failover disabled 페일오버 꺼짐 — HA 보호 없음
HA Interconnect down (link down) 두 컨트롤러 간 HA 연결 끊김
Storage Config Single-Path HA 디스크 경로 이중화 안 됨
SAS Adapter 0b OFFLINE (hard) SAS 포트 하나 죽음 (단일 경로의 원인)
ACP Connectivity Partial 쉘프 관리 경로 부분 연결
Service Processor Online (Ethernet down) 원격관리 네트워크 미연결

한쪽 컨트롤러는 꺼져 있고, 살아있는 쪽도 SAS 포트 하나가 죽어 단일 경로로만 디스크에 붙어 있는 상태. 디스크도 24개 중 1개가 Failed였다. HA 이중화가 전반적으로 무너진 반쪽 상태로 돌아가고 있었고, 추가 장애 하나면 데이터 접근이 위험해지는 구성이었다.

실제로 점검 중에 커널 패닉도 한 번 맞았다.

PANIC: Failover Monitor: unable to transit - takeover process is hung (httpd)

상대 컨트롤러가 꺼진 채 한쪽이 단독으로 takeover를 지속하다 페일오버 모니터가 hang에 빠진 것 — 사용자 명령과 무관하게, 불완전한 HA 페어를 오래 방치하면 이런 불안정성이 생긴다. 코어 덤프 후 자동 재부팅됐다.

디스크와 용량 — 원시 50TB가 실사용 22TB가 되는 이유

디스크는 1TB HDD × 14개 + 4TB HDD × 10개, 원시 용량 약 50TB. (ONTAP 화면에는 847.5GB / 3.8TB로 찍히는데, 이건 실물 용량이 아니라 ONTAP이 교체 호환성을 위해 용량을 정형화해 표기하는 right-size 값이다. 처음엔 "847GB짜리 14개"를 SSD로 오인했었다 — 파트 카탈로그를 확인하니 1TB 7.2K SATA HDD였다. right-size 표기만 보고 디스크 종류·실물 용량을 단정하지 말 것.) 그런데 볼륨 합계는 약 22.4TB였다. 절반 이하로 줄어드는 건 고장이 아니라 RAID-DP 구성의 정상적인 결과다:

  1. RAID-DP 패리티 — RAID 그룹당 디스크 2개가 패리티로 소모. aggregate가 5개로 잘게 나뉘어 있어 그룹 수가 많고, 그만큼 패리티 손실도 크다
  2. 핫 스페어 — 장애 대비 예비 디스크는 데이터 저장에 안 쓰인다
  3. WAFL 예약 — 파일시스템 오버헤드로 약 10%
  4. snapshot 예약 — 스냅샷용 공간 추가 예약

"원시 용량의 45%밖에 안 보이는데 뭔가 잘못된 건가?"라는 의심은 접어도 된다. NetApp RAID-DP에서는 이게 정상이다.

4. 발견 — "폐기 대상"에 살아있던 것들

볼륨 구성을 열어보면서 분위기가 달라졌다.

볼륨 크기 사용량 용도
vol0 237GB 5GB (2%) 시스템 볼륨
vmware1 10GB 514MB (5%) VMware 데이터스토어
voddata 3TB 936GB (31%) 강의 영상(VOD) 데이터
web 19TB 19TB (99%) 무들(Moodle) LMS 데이터
sw 200GB 74GB (37%) 소프트웨어/설치 파일

web 볼륨이 19TB로 99% 꽉 차 있고, 점검 내내 monitor.globalStatus.critical 경고가 떴다(남은 공간 231GB). 그리고 모든 볼륨이 NFS export 상태였다 — 리눅스 서버들이 마운트해서 실제 서비스에 쓰던 정황이다.

/vol/web 안에는 전형적인 Moodle 데이터 디렉토리(moodledata)가 있었다. 무들을 운영해 본 사람이라면 아는 구조다: 업로드 파일 실체가 들어가는 filedir(강의자료·학생 과제 제출물·첨부파일 — 19TB의 대부분이 이것으로 추정), sessions, localcache, temp, trashdir 같은 표준 폴더들. 그리고 그 옆에 학사시스템 연동 로그·캐시 폴더가 있었고, 그 안에 학생·교수·전체 회원·강의 정보 CSV 4종이 있었다. 파일명만으로 성격이 명확해서 내용은 열지 않았다 — 열 필요도 없고, 열지 않는 게 맞다.

정리하면: "안 쓰는 폐기 대상"이라던 장비에 ① LMS 운영 실데이터 19TB(이관/백업 여부 미확인, 유일본 가능성) ② 학생·교수 개인정보 ③ 여전히 NFS로 export 중인 볼륨들이 살아 있었다.

5. 판정 — 초기화 즉시 보류

이 시점에서 초기화 작업은 중단했다. 이유는 세 가지다.

  1. 데이터 유실 위험 — 강의자료·학생 과제 제출물의 원본이 유일본일 수 있다. 신규 시스템으로 이관이 끝났는지 문서로 확인되기 전까지 디스크에 손대면 안 된다.
  2. 개인정보 — 개인정보가 담긴 저장매체는 "그냥 포맷"이 아니라 완전삭제(sanitize)와 폐기 기록 등 공식 절차의 대상이다. 개인정보보호 담당자 보고가 먼저다.
  3. 보관 의무 가능성 — 성적·과제 등 교육 관련 자료는 법적 보관 기간이 걸려 있을 수 있다.

후속 조치는 담백하게: 초기화 보류, 책임자·개인정보보호 담당자 보고("폐기 예정 스토리지에 LMS 실데이터와 개인정보가 살아있음, 이관 여부·폐기 절차 확인 필요"), 이관 완료 여부 문서 확인, 폐기 확정 시 공식 절차 준수. 그리고 점검 과정에서 root 비밀번호를 임시로 재설정했다는 사실도 기록으로 남겼다 — 장비를 유지하게 되면 정식으로 재설정해야 한다.

교훈

  • "폐기 대상"이라는 말을 믿지 말고 확인하라. 장비의 운명을 결정하는 정보(안 씀, 이관 완료, 백업 있음)는 구두 전승으로 오는 경우가 많고, 그 전승은 자주 틀린다. 디스크를 밀기 전 콘솔 점검 한 시간이 복구 불가능한 사고를 막는다.
  • 겉모습으로 토폴로지를 판단하지 마라. 케이블 없이 쌓여 있는 두 "장비"가 실은 디스크를 공유하는 한 섀시의 컨트롤러 2개였다. 한쪽만 "안 쓰는 장비"로 밀 수 있는 구조가 아니었다.
  • 오래 방치된 HA 장비는 이미 반쪽일 수 있다. failover disabled, interconnect down, 단일 경로, Failed 디스크 — 이 상태에서 장애 하나가 더 오면 그때는 점검이 아니라 복구가 된다. 데이터가 필요하다면 반쪽 상태를 발견한 시점이 곧 이관을 서둘러야 할 시점이다.
  • 시리얼 콘솔 기본기는 벤더별 디테일이 전부다. NetApp = 9600bps, cu.* 장치, screen 포트 점유 정리, NVRAM 배터리 경고의 의미 — 알고 가면 10분, 모르고 가면 반나절이다.

후기 — 그 뒤로 (2026-07-30)

이 점검 보고 이후 보류는 해제됐고, 어레이는 초기화를 거쳐 살아있는 컨트롤러 단독 구성의 보관용 스토리지로 재구축됐다. 그 재구축에서 또 하나의 함정을 만났다 — NetApp은 디스크 소유권을 컨트롤러가 아니라 디스크 자체에 기록하는 software disk ownership 구조라, 부트 메뉴의 "initialize all disks"가 실은 자기 소유 디스크만 지운다는 것. 상대 컨트롤러 소유였던 디스크 14개는 데이터가 그대로 남아 있었고, 인수에는 maintenance mode의 정식 절차가 따로 필요했다. 이 이야기는 분량이 되어 별도 글로 다룰 예정이다.

조회 0댓글 0

댓글

아직 댓글이 없습니다. 첫 댓글을 남겨보세요.