7. 복구

파일 시스템에 있어서 지켜야 할 안전 수칙이 있다.

파일과 디렉터리는 메인 메모리 & 저장장치 볼륨 두 곳에 존재.

일관성을 가질 수 있도록 해야 함
데이터 변경 중 자료의 오염이나 소실이 생길 수 있음.

따라서 자료가 날라가거나 사라지지 않도록 해야 함.

이러한 안전성을 지켜주는 것들을 알아보자.

일관성 검사

파일 시스템은 파일 시스템 메타 데이터 안에 자신의 상태를 기록할 수 있다.

운영체제는 디렉토리 속 데이터(파일)과 해당 파일의 메타 데이터를 비교한다.

이를 일관성 검사라고 한다.

왜 하는가?

파일 시스템은 문제를 검출하고 교정할 수 있어야 한다.
근데, 모든 메타 데이터를 점검하기에는 시간과 노력이 너무 많이 든다.
그래서 메타 데이터 안에 자신의 상태를 기록해 놓는 상태 비트를 만든다.
- 메타 데이터가 변경 중이라면 상태 비트가 표기된다.
- 변경이 다 끝나면, 상태 비트는 제거된다.
- 그래도 상태 비트가 1로 남아있으면 일관성 검사를 시행한다.
이상한 상태 비트만 검사하므로, 시간과 노력을 절감한다.

어떻게 하는가?

일관성 검사를 통해 불일치 발견 시 그것을 복구하도록 시도한다.

이때 할당 및 가용 공간 알고리즘이 이 검사기가 발견할 수 있는 문제 유형과 회복 여부를 결정.

ex. 연결 할당 사용시 데이터 블록으로부터 전체 파일 재구축 가능
ex. 색인 할당 시스템에서는 데이터 블록끼리 관련성이 없으므로 불가능

(그래서 유닉스는 읽기용 디렉토리 항목들만 캐시하고, 쓰기는 동기식으로 수행)

물론, 동기식 쓰기 중에도 크래시로 인한 정보 손실은 발생할 수 있다.

정전으로 인한 크래시면 슈퍼커패시터를 쓰면 되지만, 완벽하지는 않다.

로그 구조 파일 시스템

💡 변경되기 전의 데이터와 변경 내용을 함께 로그에 기록하는 방식. database에서 주로 사용되던 걸 가져온 것

왜 하는가?

일관성 검사 기법의 단점

시스템이 깨질 수 있다
비일관성이 회복할 수 없을 수도 있다
구조를 복구할 수 없어 파일이나 전체 디렉토리가 날라간다
갈등 중재를 위해 사람의 개입이 필요할 수 있다
시간을 많이 소모한다.

이러한 문제를 극복하기 위해 도입

어떻게 하는가?

모든 메타데이터 변경은 로그에 순차적으로 기록

변경 = 특정한 연산 = 트랜잭션
일단 변경이 로그에 기록되면 그것들을 확실히 약속된 것(commit)으로 간주

이후 시스템 콜은 사용자 프로세스로 복귀 후 실행을 계속 함

그 동안 이 로그 엔트리는 실제 파일 시스템 구조에 대해 재실행됨.
변경이 반영되는 동안, 어느 동작이 마무리되었는지 나타내기 위해 포인터가 갱신된다.

commit된 전체 트랜잭션이 완료되면, 해당 사실을 나타내는 항목이 로그에 만들어짐

이 로그 파일은 실제로 원형 버퍼의 모양으로, 이전 데이터 위에 겹쳐서 기록될 수 있다.
따라서 이러한 겹침이 발생하지 않도록 해야 한다.

로그는 파일 시스템의 별도 영역 또는 별도 저장장치에 있을 수 있다.

시스템에서 충돌이 나면, 로그 파일에 0개 이상의 트랜잭션이 있을 것.

트랜잭션 = 운영체제에 의해 commit 되었을 지어도 완료된 것이 아님.
반드시 완료될 때까지 실행될 수 있어야 하고, 파일 시스템 구조는 일관성을 유지

트랜잭션이 중단되었을 때 문제가 발생

시스템에서 충돌이 나기 전 commit 되지 않은 것
변경된 파일 시스템의 내용이 원상복구 되어야 파일 시스템의 일관성을 유지
크래시가 발생한 이후 이러한 상황에서 복구가 꼭 필요함.

기타 이득

디스크 메타데이터 갱신에 대한 로그를 사용했을 때의 이득

이들을 직접 디스크 데이터 구조에 적용하는 것보다 갱신이 더 빠르다.
임의 입출력에 비해 순차 입출력이 빠르기 때문
비용이 많이 드는 동기식 임의 메타데이터 쓰기가 비용이 훨씬 적게 드는 로그 구조 파일 시스템의 로깅 지역에 대한 동기식 순차 쓰기로 변경됨
이러한 변환은 다시 해당 구조의 임의 쓰기를 통해 비동기로 재실행됨

결과적으로 메타데이터 지향 연산에 막대한 이득을 가져옴.

다른 해결 방안

WAFL 파일 시스템 & ZFS 파일 시스템

옛 데이터를 새 데이터로 절대 덮어쓰지 않음
트랜잭션은 모든 데이터와 메타데이터 변경을 새 블록에 기록
트랜잭션 완료 시 이 블록들의 구 버전 기록을 가리키는 메타데이터 구조가 새 블록을 가리키게 갱신됨.
이후 파일 시스템은 구 포인터와 옛 블록들을 제거해 재사용할 수 있게 만듬

이전 포인터와 블록이 유지되면 스냅샷이 생성됨

💡 스냅샷 = 특정 시점의 파일 시스템의 상태

단, WAFL은 일관성 검사기를 가지고 있어서 몇몇 고장 시나리오는 메타데이터 오염을 초래.

ZFS 파일 시스템 (추가)

절대로 블록을 덮어 쓰지 않음.
메타데이터와 데이터 블록의 검사 총합을 제공
RAID와 결합할 때 데이터가 항상 올바르다는 것을 보장
그래서 일관성 검사기가 ZFS에는 없다.

백업과 복구

저장장치 고장으로 인한 자료 손실을 보완하기 위해 백업이 핑료하다.

이때 복사의 양을 최소화하기 위해 각 디렉터리 항목 정보를 이용할 수 있다.

백업 과정은 보통 다음과 같다.

1일차. 디스크로부터 모든 파일을 백업한다.
2일차. 1일차에 변경된 모든 파일을 백업한다.
3일차. 2일차에 변경된 모든 파일을 백업한다.

n일차. n-1일차에 변경된 모든 파일을 백업한다.

새 사이클은 자신의 백업을 이전 백업 집합에 쓸 수도, 새 백업 미디어에 쓸 수도 있다.

이 방법을 사용해 전체 백업에서 점진적 백업을 적용해 전체 파일 시스템을 복원 가능.

물론, 사고로 삭제한 파일도 복구할 수 있음.

단, n값이 클수록 보다 많은 저장장치를 읽어야 함.

사이클의 길이 = 필요한 백업의 양 & 되돌아갈 수 있는 날짜에 좌우

복원을 위해 읽어야 할 디스크 수를 줄이기 위해 전체 백업을 적절히 중간 시점에서 수행할 수 있음.

이 경우 처음부터 디스크를 읽어야 할 필요가 없음
단 전체 백업을 수행하면 더 많은 공간이 필요.

영구 백업 매체는 컴퓨터 시스템에서 떨어진 곳에 두는 것이 현명

여러 백업 시스템을 두는 것도 추천하는 방법 중 하나.