ZFS 덕분에 데이터 손실은 단 10분 분량에 불과

 (mastodon.social)
3P by GN⁺ | ★ favorite | 댓글 1개
  • 2년 된 SSD가 갑자기 사망했지만, ZFS 증분 복제로 새 드라이브에 시스템을 되살려 실제 손실은 약 10분 분량에 그침
  • 전체 파일시스템을 10분마다 스냅샷으로 찍어 NAS로 보내는 구조였고, 자동화에는 zrepl을 사용함
  • 스냅샷은 실행 중인 시스템의 특정 시점 상태를 저장하고 변경분만 전송해, 홈 네트워크에서도 백그라운드 복제가 가능했음
  • 복원 과정은 625GiB ZFS receive를 밤새 돌리고 암호화 wrapper key까지 복원해야 해 자동 복구와는 거리가 있었음
  • ZFS는 초기 도입과 유지보수 부담이 크지만, 실제 드라이브 고장에서 작업 상태까지 되살리는 재해 복구 효과를 보여줌

SSD 고장 뒤 남은 손실은 10분

  • 노트북을 열어 이메일을 보내려던 순간 화면이 검은색으로 멈춰 있었고, 재부팅 후 2년 된 SSD가 사망한 상태로 확인됨
  • 새 드라이브에 시스템을 복원한 뒤 다시 사용할 수 있었고, 전체 데이터 손실은 약 10분 분량에 그침
  • 복구된 노트북은 중단했던 지점으로 부팅됐으며, 브라우저 탭도 전날 밤의 미완성 작업을 되살림
  • 12년 전 Chromebook 광고처럼 새 기기에서 이전 상태를 이어가는 구상이 이번 고장 상황에서 실제로 작동함

백업보다 복제에 가까운 구조

  • 단순히 드라이브를 백업하는 대신 전체 파일시스템 복제 방식을 사용함
  • 지난겨울 창작 작업용 컴퓨터들의 주기적 백업을 위해 홈 네트워크 스토리지를 구축했고, 여러 선택지 중 ZFS 증분 복제를 선택함
  • ZFS는 실행 중인 시스템에서도 특정 시점 스냅샷을 효율적으로 만들 수 있음
  • 이후 다른 머신으로 보낼 때는 전체 데이터를 반복 전송하지 않고 변경된 데이터만 전송함

zrepl로 10분마다 NAS에 전송

  • 스냅샷 생성과 NAS 전송 자동화에는 zrepl을 사용함
  • 설정은 전체 파일시스템을 10분마다 스냅샷으로 찍고 전송하는 방식임
  • 증분 스냅샷 덕분에 홈 네트워크에서 백그라운드로 실행해도 복제본을 최신 상태로 유지할 수 있었음
  • 마지막 실행은 전송에 14초가 걸렸고, 약 64MiB를 보냄

복원 과정에서 드러난 수작업 부담

  • 시스템 복원은 학습이 필요한 과정이었고, 상당 부분 수동 작업에 의존함
  • 625GiB ZFS receive 작업은 밤새 실행해야 했음
  • 스냅샷은 원본 컴퓨터가 암호화한 상태라 NAS가 내용을 읽을 수 없었음
  • 백업을 실제로 사용하려면 암호화 wrapper key도 복원해야 했음
  • 데이터를 복호화할 수 있다는 첫 확인 전까지 복원 과정은 매우 불안했음

도입 비용과 하드웨어 교체

  • ZFS 초기 설정은 전체 파일시스템 교체가 필요해 시작 비용이 높았음
  • 유지에는 관련 지식이 많이 필요하고, 수작업이 포함되는 운영 절차가 따름
  • 그래도 SSD가 처음 고장 나기 전에 복제를 설정해 둔 것은 운이 좋았고, 이번 사례에서 ZFS의 장점이 드러남
  • 사망한 드라이브는 원래 Framework 주문에 포함된 WD_BLACK SN850이었음
    • Framework 포럼에서 이 드라이브가 갑자기 죽거나 부팅 불능이 된다는 불안한 사례를 본 적이 있었음
  • 같은 날 Amazon에서 SK Hynix P41 SSD와 Sabrent NVMe enclosure를 약 3시간 만에 배송받음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • ZFS를 쓰고 있으니 다른 WD나 SanDisk SSD 사용자들보다는 대비가 잘 된 셈임
    https://petapixel.com/2023/08/08/sandisk-portable-ssds-are-failing-so-frequently-we-can-no-longer-recommend-them/
    https://www.theverge.com/22291828/sandisk-extreme-pro-portable-my-passport-failure-continued
    https://news.ycombinator.com/item?id=37042587
    https://www.theverge.com/23837513/western-digital-sandisk-ssd-corrupted-deleted-questions
    https://news.ycombinator.com/item?id=37188736

  • Linux 세계를 완전히 떠나기 직전에 btrfs라는 빙산을 조금씩 파보기 시작했는데 꽤 흥미로웠음
    백업 혁신, 디스크 구성 등 여러 기능에서 가능성이 커 보였음. btrfs는 ZFS는 아니지만 기능상 겹치는 부분이 있고 “가난한 사람의 ZFS”에 가깝기도 함. 또 ZFS는 라이선스, 패키징, 커널 내 포함 상태가 좀 애매해서, 특정 운영체제에서는 btrfs가 훨씬 합리적으로 굴러감
    Linux User Group에서 컴퓨터를 재부팅하려고 전원 코드를 뽑아야 했다고 말했더니, 그 어리석은 행동 때문에 엄청 혼났고 ZFS를 쓰라는 권유를 받은 적이 있음. 다만 그 시스템이 Raspberry Pi였다는 점을 생각하면, 둘 중 어느 행동이 현명한지 생각이 달라질 수도 있음

    • Pi는 파일시스템 손상이 생길 수 있다고는 하지만, 이미지를 설치할 때마다 tmpfs를 여기저기 걸고 대부분 쓸모없는 로그를 끄는 스크립트를 돌려서 직접 본 적은 없음
      SD 카드를 혹사하지 않는 한 이런 장비들은 매우 안정적으로 계속 돌아감. ZFS는 정말 멋져 보이지만, 언젠가 NAS를 사더라도 ZFS를 돌릴 수 있는 장비에 돈을 쓰고 싶지는 않을 것 같아서 그냥 RAID와 ext4를 쓰게 될 듯함
      btrfs는 몇 달마다 “BTRFS가 내 데이터를 날렸다”는 글을 보고, 그게 btrfs 잘못인지 논쟁이 이어지는 걸 봐서 계속 피했음. 요즘은 그런 글을 덜 보는 것 같으니 다시 볼 때가 된 건지도 모르겠음
    • 궁금해서 묻는데, Linux 세계를 완전히 떠나게 된 계기가 무엇이었음? “커뮤니티”가 다른 사람들에게 더 나아지려면 그 경험에서 무엇을 배울 수 있을까?
    • btrfs에서 정말 마음에 안 드는 유일한 점은 단편화가 생기기 쉽다는 것임
      특히 희소 VM 이미지에서 그렇고, 그 용도에는 zvol이 훨씬 낫다고 봄

  • 몇 년 전에는 커패시터 대란이 있었는데, 이제는 저장장치 대란을 겪는 건가 싶음
    모든 저장장치가 점점 나빠지는 게 터무니없어지고 있음. WD는 SMR로 HDD를 망치고 있고, 제조사들은 SSD와 HDD의 3년 가동 시간이 이미 너무 길다고 말하는데 농담이 아님. 올해만 해도 Kingston SSD 하나는 죽었고, 그건 8년쯤 된 거라 그렇다 쳐도 휴대용 WD HDD도 약 2년 만에 죽었음
    요즘 인터넷에는 데이터 손실과 수명 문제가 가득함. 20년 전 HDD도 영원히 쓰는 물건은 아니었지만, 적어도 같이 산 컴퓨터의 유용 수명보다는 확실히 오래 버텼던 기억이 있음

    • 요즘 하드디스크가 20년 전보다 훨씬 운이 좋았음
      20년 전은 자기 코팅이 플래터에서 말 그대로 떨어져 나가던 악명 높은 IBM Deathstar 드라이브의 시대였음. 1~2년 만에 죽는 끔찍한 Maxtor 드라이브도 있었고, Seagate가 Maxtor를 인수한 뒤 한동안 Seagate 드라이브도 불안정해졌음. 디스크 8개쯤 달린 서버를 운영하면서 1년에 하나 꼴로 계속 교체해야 했음
      반면 지금은 20개 넘는 드라이브가 있는 ZFS 서버 관리를 돕고 있는데, 드라이브 수명은 대략 4~5년 정도임. 또 당시 컴퓨터는 훨씬 빨리 구식이 됐음. 지금은 6년 된 컴퓨터도 충분히 쓸 만하지만, 그때는 3년 된 컴퓨터만 되어도 체감이 컸음
    • 걱정하지 않아도 됨. 곧 칩들도 몇 년 지나면 오작동하기 시작할 것임
      확장 한계에 부딪히고 있고, 지수적 성장이 둔화되고 있음
    • 개인적으로는 예전에도 나와 주변 사람들의 HDD가 가끔 고장 났던 기억이 있음
      지금은 SSD에서 그런 일이 거의 없음. 심지어 문제가 많다고 알려진 2000년대 후반의 오래된 Intel SSD도, 내가 몇 년 쓰다가 어머니께 드린 같은 구형 MacBook 안에서 아직 멀쩡히 작동함. 실제 데이터가 어떨지 궁금함
    • 지난 10년 동안 산 WD 드라이브들은 모두 기대대로 동작했음. SMR 도입 뒤에 산 NAS용도 포함되는데, 그냥 Red가 아니라 Plus나 Pro인지 확인했기 때문임
      SSD도 운이 좋았지만, 데스크톱에서는 여전히 /home 디렉터리와 RAID 배열을 오래된 회전식 드라이브에 두는 편이라 작은 SSD만 씀
      예외는 두 개 있었음. SMR 이전 WD Red 두 개를 더 큰 디스크로 교체하려고 오래된 NAS에서 빼서, 완전히 정상인 상태로 정전기 방지 봉투에 넣어 서랍에 보관했음. 약 2.5년 뒤 예비 디스크가 필요해서 꺼내 확인했더니 둘 다 작동하지 않았고, 하나는 완전히 죽었으며 다른 하나는 겨우 인식만 되고 읽을 수 없었음. 첫 번째는 연결해도 전혀 나타나지 않았고, 컨트롤러 PCB 핀을 포함해 모든 접점을 닦아봤지만 소용없어서 결국 버렸음. 두 번째는 전체 재포맷 후에야 재사용 가능했지만, testdisk를 써도 예전 데이터는 복구할 방법이 없었음. 이런 일은 겪어본 적도 예상한 적도 없어서 솔직히 꽤 걱정됨
    • 약 20년 전에도 HGST “Deathstar” 가 있었고, 집단소송까지 걸릴 만큼 나쁜 드라이브였음
      디스크는 늘 무작위로 죽었고, Sun이 ZFS를 만든 이유 중 하나도 그 때문임

  • 아주 짧게 요약하면, Mastodon 스레드는 https://zrepl.github.io를 가리키고 있음
    “zrepl은 ZFS 복제를 위한 통합 원스톱 솔루션”임

    • zrepl이 Go로 작성됐고 sanoid/syncoid가 Perl 스크립트라는 점 말고, zrepl과 sanoid/syncoid가 어떻게 다른지 아는 사람이 있을까?
    • 저장 서버에서 돌아가는 데몬과 통신해야 하는 것처럼 보임
      예를 들어 S3를 저장소로 바로 쓸 수 있으면 멋질 듯함

  • Zrepl은 내가 디지털 노마드 생활을 안심하고 하는 큰 이유임
    밤마다 대략 한 번 실행되는 스크립트가 별도 헤더를 가진 LUKS 보호 ZFS 풀을 열고 모든 스냅샷을 복사함. 그 NVME 인클로저는 항상 몸에서 떨어지지 않는 “가방” 안에 있음
    이 구성과 NixOS 덕분에 동일한 새 노트북을 약 10분 안에 프로비저닝할 수 있음. 최근에는 오프사이트 복제도 추가해서, 완전히 심하게 강도를 당하더라도 심각한 데이터 손실 가능성은 거의 0에 가까움
    Zrepl은 정말 훌륭한 소프트웨어임. 시작하기 쉽지만, 필요하면 모든 조절점을 다 만질 수 있을 정도로 정교하고 강력함. 칭찬이 부족할 정도임

    • 도난, 화재, 홍수나 다른 재난 한 번이면 끝나는 대부분의 사람들보다 훨씬 안전할 것 같음
    • sanoid/syncoid를 써본 적이 있음? 그것들에 비해 Zrepl이 더 주는 게 뭐임?
    • 이 구성이 어떻게 작동하는지 글로 써주면 좋겠음. 꽤 흥미롭게 들림

  • 파일시스템을 10분마다 스냅샷 찍은 것이 SSD 사망에 영향을 줬을 수 있을까?

    • ZFS는 특수하고, 쓰기 시 복사를 쓰기 때문에 스냅샷 생성 비용이 낮음
      직관적으로는 아주 자주 스냅샷을 찍어도 추가 쓰기량은 꽤 적을 것 같음. 그래도 과학적인 측정이 있으면 좋겠음
      예전에 관리하던 일부 서버에서 ZFS로 매분, 매시간, 매일 스냅샷을 찍었음. 분 단위 스냅샷은 60분 뒤 삭제했고, 다른 머신의 cron 작업으로 시간별·일별 스냅샷을 백업했음. 시간별 스냅샷은 대략 72시간 보관하고, 일별 스냅샷은 영구 보관하도록 했음. 분 단위 스냅샷은 SQL 마이그레이션 중 수동 실수를 되돌리기 위한 목적이었고, 잘 작동했음
      지금도 FreeBSD 서버에서 ZFS를 쓰지만, 현재 프로젝트들은 트래픽이 낮고 중요한 데이터 변경도 드물어서 개인 서버에서는 대략 주 1회 수동으로 스냅샷을 찍고 다른 서버에서 백업을 수동으로 트리거함. 또 이제는 PostgreSQL 데이터베이스와 애플리케이션 데이터가 있는 파일시스템 부분만 스냅샷함. 운영체제 데이터는 더 이상 크게 신경 쓰지 않음. 심각한 하드웨어 고장이 나면 OS를 새로 설치하고, 중요한 설정값은 기록해두며 백업 스크립트가 실행될 때 다른 잡다한 것 대신 그 값을 복사하게 해둠
    • 그럴 가능성은 낮음
      스냅샷은 많이 쓰지 않고, SSD와 ZFS 모두 쓰기 시 복사 방식임. 즉 스냅샷 이후 쓰기 비용은 스냅샷 전과 같음
      다만 맥락이 빠져 있음. SSD와 ZFS 모두 가득 찬 상태나 거의 가득 찬 상태를 좋아하지 않음. 작업 데이터가 약 650GB이고 드라이브가 1TB였다면, 스냅샷 때문에 드라이브 사용량이 쉽게 90%를 넘었을 수 있음. 그 자체만으로도 ZFS가 불편해졌을 가능성이 있음
    • 내가 이해한 바로는 ZFS에서 스냅샷을 찍는 일은 메타데이터 객체와 일부 데이터 참조를 쓰는 것임
      데이터 100GB, 128K 블록 크기, 64비트 포인터라고 가정하면, 스냅샷 중 새로 쓰이는 데이터는 대략 5MB 수준일 것 같음. 이걸 시간당 6번, 연간 52,560번 하는 것이 드라이브 조기 마모를 일으킬 만큼인지 따지면 연간 약 256GB임. 이는 SSD 쓰기 내구도의 1% 미만일 가능성이 큼. 그래서 10분 단위 스냅샷이 중요한 원인이라면 놀랄 것 같음
      틀렸을 수도 있고, 그다지 신뢰할 수 없는 출처에 도움을 구해 추산한 것임. 정정은 환영함. 그래도 내 추산이 실제보다 높고, 그럼에도 수명에 영향을 줄 가능성이 낮다면 논점 자체가 별 의미 없을 수 있음
    • 가능성은 낮음. 스냅샷은 대략 가장 최근에 기록된 블록을 표시하고 이전 블록이 변경되지 않게 막는 것임
      ZFS는 쓰기 시 복사라서 파일 변경에는 동일한 쓰기가 발생하고, 일부 기존 데이터가 삭제되지 않을 뿐임
    • 어떤 무작위 주황색 웹사이트의 댓글[1]에 따르면 최신 플래시 칩의 최소 쓰기 크기는 약 100MB일 수 있음
      그러면 10분마다 5MB 쓰기가 실제로는 시간당 600MB, 8시간 근무일 기준 4.8TB, 주 40시간 기준 24TB가 되고, 1TB 드라이브에서는 실시간 3.43 DWPD, 2년 실시간으로는 2500TBW가 됨[2]
      SN850의 공식 쓰기 내구도는 600TBW인데, 보증 문제 때문에 당연히 보수적으로 낮춘 값일 가능성이 큼. 공교롭게도 2500TB는 이 시장의 많은 SSD에서 흔한 내구도 수치이기도 함. 전체적으로 보면 완전히 불가능한 일은 아닌 것처럼 들림
      아직 살아 있다면 컨트롤러가 SMART 데이터에서 뭐라고 말하는지 궁금함. Linux에서는 apt install smartmontools; smartctl -s on /dev/sda; smartctl -A /dev/sda를 실행하면 표가 출력될 것임[4]. Windows에서는 CrystalDiskInfo[3]를 설치하면 됨
      1: https://news.ycombinator.com/item?id=29165202
      2: DWPD: drive writes per day, TBW: Total Bytes Written - in terabytes
      3: https://crystalmark.info/en/software/crystaldiskinfo/
      4: “Pre-fail”은 고장 직전에 값이 바뀌어야 한다는 뜻이고, “Old_age”는 나이를 나타내는 값이라는 뜻이지, “이건 나쁘고 곧 고장남”이나 “이 드라이브는 오래됨”이라는 뜻이 아님. 항상 모든 항목에 Pre-fail과 Old_age가 표시됨. 오래전에 누군가 “somewhat_boolean”과 “life_remain”으로 바꿨어야 했다고 생각함

  • 나는 보통 Apple Time Machine 증분 백업을 Synology 회전식 디스크 서버로 함
    위험한 작업을 하거나 머신을 업그레이드할 때는 외장 SSD에 내부 드라이브를 미러링하기도 함. 이 방식은 잘 동작함. Time Machine 복원은 꽤 느릴 수 있지만, 중요한 데이터 대부분은 Git과 호스팅 저장소에 있어서 큰 문제는 아니었음. 단일 파일을 되돌리고 싶을 때 가끔 Time Machine을 씀
    악명 높은[0] SanDisk 드라이브도 하나 갖고 있지만, 중요한 용도로 쓰지는 않음. 게임 저장소 정도만 들어 있음. Mac 사용자라 게임은 큰 요소가 아니고, 그것들이 죽어도 울지는 않을 것임
    [0] https://arstechnica.com/gadgets/2023/08/sandisk-extreme-ssds-are-worthless-multiple-lawsuits-against-wd-say/

    • 나도 Time Machine을 씀. https://tclementdev.com/timemachineeditor/ 앱을 받아서 머신이 유휴 상태일 때마다 수동으로 TM 백업을 트리거하게 했음
      Apple의 자동 백업이나 시간 기반 백업보다 훨씬 잘 작동하는 것 같음
    • 나는 Time Machine을 포기했음. Synology에서 atalk 등을 써도 한두 달 이상 제대로 동작한 적이 거의 없음

  • 내 스냅샷은 원본 컴퓨터에서 암호화됨. NAS가 읽을 수 없다는 점이 멋짐
    그래서 백업을 쓰려면 암호화 wrapper key도 복원해야 했음. 거짓말 안 하고, 데이터를 복호화할 수 있다는 첫 확인을 받기 전까지는 꽤 무서웠음
    맞춤형 백업 방식은 실제로 주기적으로 데이터를 복원할 수 있는지 확인하기 전까지는 작동한다고 가정하면 안 됨

    • 맞춤형이 아닌 백업도 마찬가지임
    • 만일을 대비해 LUKS 헤더 사본을 별도 디스크에 보관해야겠다고 늘 생각만 했음

  • 여기서 Linux의 가까운 미래는 bcachefs임
    https://bcachefs.org/

    • bcachefs가 BTRFS나 ZFS보다 더 잘하는 게 뭐임?
    • 가까운 미래라고 하기엔 이미 7년째 개발 중이고 아직 업스트림에 받아들여지지 않았음
      업스트림 반영 작업은 진행 중이긴 함
    • 왜 기대해야 하는지 짧은 요약이 있음? 멋진 기능이라도 있나?

  • “데이터를 복호화할 수 있다는 첫 확인을 받기 전까지 꽤 무서웠다”는 건, 절차가 최적보다 덜 테스트되고 덜 문서화돼 있었다는 뜻처럼 들림
    가정용 시스템이나 개인 데스크톱에서는 아주 드문 일은 아님. 그래도 프로덕션 서버에서는 복원 절차를 그 자리에서 즉흥적으로 알아내고 싶지는 않을 것임

    • 맞음. 복원에 필요한 재료는 다 있다고 알고 있었고, 6개월 전에 한 번 시험도 해봤지만 처음에는 잘못된 키를 복사했음
      로드에 실패했을 때 잠깐 암담했지만 곧 실수를 깨달았음. 이런 실패 순간에는 모든 프로세스의 빈틈이 눈부시게 분명해지는 식의 선명함이 찾아옴
답변달기