요약

  • Debian은 2010년 4월 날짜와 버전으로 옛 패키지를 찾는 snapshot 서비스를 발표했다. 회귀 버그를 추적하고 미리 시험한 업그레이드를 다시 수행하는 데 쓸 수 있었다.
  • 그해 하드웨어 장애는 저장된 자료를 계속 제공하는 일과 새로운 저장소 상태를 수집하는 일에 각각 대비가 필요하다는 사실을 드러냈다.

Debian의 타임머신에는 디스크 컨트롤러 교체가 필요했다. 시간 여행치고는 꽤 소박한 고장이다. 과거로 돌아가는 서비스를 만들던 사람들은 당장 오늘의 부품 문제부터 해결해야 했다.

2010년 4월 12일 발표는 snapshot.debian.org의 쓰임을 구체적으로 설명했다. 날짜와 버전으로 옛 패키지와 소스 코드를 찾고, 일반 apt 저장소처럼 이용할 수 있었다. 관리자는 특정 날짜의 패키지 묶음으로 업그레이드를 시험한 뒤 실제 작업에서도 같은 묶음을 다시 가져올 수 있었다. 개발자는 버그가 어느 변화에서 시작됐는지 거슬러 올라갈 자료를 얻었다. 발표 당시 규모는 약 6.5테라바이트였고, 2005년 3월 이후 기본 및 보안 아카이브의 거의 모든 패키지를 담고 있었다.

정식 발표 전부터 수리 일지는 쌓이고 있었다. 2월 20일 기록에는 두 번째 사이트가 등장한다. 주 서버 stabile이 새 스냅샷을 수집하고 sibelius로 데이터를 복제했으며, 양쪽 모두 웹 요청에 응답했다. 나흘 뒤 주 서버의 컨트롤러 고장으로 디스크 절반에 접근할 수 없게 됐다. 남은 서버는 기존 자료를 계속 내줬다. 새 데이터 반입은 멈췄다.

별도 데이터베이스를 쓰는 보조 수집기를 둘 계획은 이미 있었다. 고장 난 컨트롤러가 그 계획을 대기 목록 맨 앞으로 끌어올렸다. 회의보다 효과는 빨랐고, 방식은 훨씬 거칠었다.

창구는 열려 있는데 새 물건이 안 들어온다

3월 9일에는 주 서버가 돌아왔고, 보조 시스템이 모아 둔 스냅샷을 합치는 중이었다. 빠진 것도 있었다. backports.org의 갱신이 보조 시스템으로 제대로 전달되지 않았다. 15일 기록은 주 서버의 수집 재개와 보조 데이터 통합 완료를 알렸다.

복구에는 재고 조사도 필요했다. 파일은 내용의 해시값을 이름으로 삼았고, 데이터베이스는 그 이름을 패키지와 아카이브 경로에 연결했다. 점검은 파일 이름과 실제 내용이 맞는지, 데이터베이스가 가리키는 파일이 존재하는지 확인했다. 내용은 맞지만 이름 계산이 틀린 파일, 손상된 패키지 색인 등이 발견됐다. 이름과 참조를 고치고 망가진 파일은 제거했다. 전원 불이 들어온 뒤에도 할 일이 남았다.

12월 14일 보고는 11월 20일 무렵의 또 다른 하드웨어 문제를 다뤘다. 주 서버가 새 데이터를 받아들이지 못하는 동안 남은 미러는 20일 시점의 자료를 제공했다. 비공개 예비 시스템은 수집을 계속했고, 모은 자료는 나중에 합쳐졌다. 다만 그 시스템의 수집 대상에 debian-ports가 없었다. 해당 아카이브에는 장애 기간의 빈칸이 남았다.

옛 소프트웨어 묶음을 실제로 다시 받아 쓸 수 있다는 것이 이 서비스의 매력이었다. 앞으로 더 많은 날짜를 꺼내 보려면 오늘의 변화를 받아 두는 일이 계속돼야 했다. 어제의 선반이 멀쩡해도 오늘의 입고장은 멈출 수 있다. 디지털 기억에도 입고 담당자가 필요했다.