KR101994491B1 - 데이터 중복제거를 위한 백업 및 복원 전략 - Google Patents

Abstract

최적화된 데이터 스트림의 백업 및 복원을 위한 기법이 기재된다. 청크 저장소는 각각의 최적화된 데이터 스트림을 적어도 하나의 데이터 청크 및 대응하는 최적화된 스트림 메타데이터를 포함하는 복수의 청크로서 포함한다. 상기 청크 저장소는 데이터 청크를 중복제거된 방식으로 포함한다. 청크 저장소에 저장된 최적화된 데이터 스트림이 백업을 위해 식별된다. 최적화된 백업 기법, 역-최적화된 백업 기법, 아이템 레벨 백업 기법, 또는 데이터 청크 식별자 백업 기법에 따라 청크 저장소의 적어도 일부분이 백업 저장장치에 저장된다. 백업 저장장치에 저장된 최적화된 데이터 스트림은 복원될 수 있다. 파일 재구성기가 최적화된 스트림 메타데이터 및 임의의 참조된 데이터 청크를 백업 저장장치로부터 요청하기 위한 콜을 복원 애플리케이션으로 생성하는 콜백 모듈을 포함한다. 상기 파일 재구성기는 참조된 데이터 청크로부터 데이터 스트림을 재구성한다.

Description

데이터 중복제거를 위한 백업 및 복원 전략{BACKUP AND RESTORE STRATEGIES FOR DATA DEDUPLICATION}

데이터 최적화(data optimization)라고도 알려진 데이터 중복제거(data deduplication)는 원본 데이터의 충실도(fidelity)나 무결성(integrity)을 희생시키지 않으면서 디스크 상에 저장되거나 네트워크를 통해 전송될 필요가 있는 데이터의 물리적 바이트 양을 감소시키는 동작이다. 데이터 중복제거는 데이터를 저장하는 데 필요한 저장 용량을 감소시켜, 저장 하드웨어 비용 및 데이터 관리 비용에 대한 절약을 야기할 수 있다. 데이터 중복제거는 디지털 저장되는 데이터의 빠른 증가를 다루는 데 솔루션을 제공한다.

데이터 중복제거는 영속적으로(persistently) 저장된 파일들 내, 그리고 상기 파일들 사이의 중복(redundancy)을 제거하기 위한 하나 이상의 기법에 따라 수행될 수 있다. 예를 들어, 하나의 기법에 따르면, 하나 이상의 파일에서 복수 번 등장하는 데이터의 고유 영역이 식별되고, 데이터의 이러한 식별된 고유 영역의 단일 카피가 물리적으로 저장될 수 있다. 데이터의 이러한 식별된 고유 영역(데이터 "청크"라고도 일컬어짐)으로의 참조자가 저장될 수 있으며, 상기 참조자는 이들을 포함하는 파일 및 상기 파일 내 위치를 가리킨다. 이 기법은 흔히 단일 인스턴싱(single instancing)이라고 지칭된다. 상기 단일 인스턴싱에 추가로 데이터의 압축이 수행될 수 있다. 그 밖의 다른 데이터 감소 기법이 데이터 중복제거 해결책의 일부로서 더 구현될 수 있다.

데이터 중복제거 기법에 따라 저장된 데이터를 관리하는 데 어려움이 존재한다. 예를 들면, 데이터 중복제거에 의해 야기되는 데이터 단편화(data fragmentation) 때문에, 중복제거에 따라 저장된 파일을 액세스하는 데 대기시간(latency)이 존재할 수 있다. 이 대기시간은, 특히 사용자가 파일에 대한 끊김 없고 빠른 액세스를 기대하는 주 저장장치 데이터에 대한 데이터 중복제거 해결책의 채택을 제한한다. 더욱이, 데이터 중복제거 알고리즘이 데이터를 저장하고 서비스하는 전용 기기 또는 장치(가령, 파일 서버) 상에서 실행될 수 있다. 파일 서버의 경우, 데이터 중복제거는 장치의 주 기능이 아닐 수 있고, 따라서 데이터 중복제거 기법은 장치 자원(가령, 메모리, 입/출력(I/O) 메커니즘, 중앙 처리 장치(CPU) 용량, 등등)을 과도하게 소비하지 않도록 효율적일 필요가 있다. 또한, 디지털 데이터 양이 매우 빠른 속도로 커지고 있기 때문에, 저장 장치(가령, 저장 디스크)의 크기 및 컴퓨팅 장치와 연관된 총 저장 용량도 커지며, 증가하는 저장량에 맞춰 잘 확장(scale)되지 않는 데이터 중복제거 기법으로 인한 어려움이 존재하게 된다. 데이터 중복제거는 데이터의 압축으로 인해 더 작은 데이터 백업 및 더 빠른 데이터 백업이 수행될 수 있게 하고, 결과적으로 백업된 데이터의 더 빠른 복원도 가능하게 한다. 그러나, 중복제거된 데이터를 백업하고, 백업 저장장치로부터 상기 중복제거된 데이터를 복원하는 데 해결과제가 존재한다.

개요

이 개요는 이하의 구체적인 내용에서 추가로 기재될 개념들의 모음을 단순화된 형태로 소개하기 위해 제공된다. 이 개요는 본 발명의 핵심 특징이나 본질적 특징을 식별하려는 것이 아니며 본 발명의 범위를 제한하려 사용되지도 않는다.

최적화된 데이터 스트림을 백업 저장장치에 백업하고 데이터 스트림을 백업 저장장치로부터 복원하기 위한 방법, 시스템, 및 컴퓨터 프로그램 프로덕트가 제공된다. 본 명세서에서 최적화된 데이터(optimized data)는 데이터 중복제거 기법들, 가령, 청크의 단일 인스턴싱(single-instancing) 및 압축 중 하나 이상에 의해 최적화, 또는 중복제거가 수행된 데이터를 지칭한다. 최적화된 스트림은 중복제거된, 즉, 데이터 중복제거 기법을 이용해 최적화된 데이터를 갖는 스트림을 지칭한다.

예를 들어, 최적화된 데이터 스트림의 백업을 위한 구현예가 기재된다. 청크 저장소가 복수의 최적화된 데이터 스트림을 포함하며, 각각의 최적화된 데이터 스트림은 적어도 하나의 데이터 청크 및 데이터 청크에 대한 식별자를 청크 저장소 내 데이터 청크의 위치로 매핑하는 최적화된 스트림 메타데이터(가령, 청크 저장소의 청크 컨테이너, 전역 테이블, 데이터베이스, 등등에 스트림 맵 청크로서 저장된 스트림 맵)를 포함하는 복수의 청크를 가진다. 상기 청크 저장소는 데이터 청크를 중복제거된 방식으로 포함한다. 청크 저장소에 저장된 최적화된 데이터 스트림 중 하나 이상이 백업을 위해 식별될 수 있다. 식별된 최적화된 데이터 스트림을 백업하기 위해, 청크 저장소의 적어도 일부분이 백업 저장장치에 저장된다. 선택된 백업 기법에 따라 상기 청크 저장소(이의 일부분 또는 전체)가 백업 저장장치에 저장된다.

예를 들어, 최적화된 백업 기법에 따라, 청크 저장소의 하나 이상의 청크 컨테이너의 전체가 백업 저장장치에 저장된다. 복수의 최적화된 스트림 구조가 백업 저장장치에 저장된다. 최적화된 스트림 구조는 백업을 위해 식별된 최적화된 데이터 스트림에 대한 재분석 포인트(reparse point)이다.

역-최적화된 백업 기법에 따라, 백업을 위해 식별된 각각의 최적화된 데이터 스트림이 최적화된 데이터 스트림의 메타데이터에 의해 참조되는 임의의 데이터 청크를 포함하는 대응하는 역-최적화된 데이터 스트림으로 원상회복된다. 각각의 역-최적화된 데이터 스트림은 백업 저장장치에 저장된다.

아이템 레벨 백업 기법에 따라, 제 1 최적화된 데이터 스트림이 백업을 위해 식별된다. 제 1 최적화된 데이터 스트림의 메타데이터에 의해 참조되고 백업 저장장치에 이미 저장된 것이 아닌 하나 이상의 데이터 청크가 결정된다. 제 1 최적화된 데이터 스트림의 상기 최적화된 스트림 메타데이터가 백업 저장장치에 저장된다. 이미 백업된 것이 아니라고 결정된 데이터 청크도 백업 저장장치에 저장된다. 백업을 위해 식별된 각각의 최적화된 데이터 스트림이 유사한 방식으로 백업 저장장치에 저장될 수 있다.

데이터 청크 식별자 백업 기법에 따라, 각각의 최적화된 데이터 스트림의 최적화된 스트림 메타데이터가 분석되어 최적화된 스트림 메타데이터에 의해 참조되는 데이터 청크에 대한 데이터 청크 식별자를 결정한다. 각각의 최적화된 데이터 스트림에 대한 최적화된 스트림 구조가 대응하는 적어도 하나의 데이터 청크 식별자와 함께 백업 저장장치에 저장된다. 참조된 데이터 청크를 저장하는 청크 저장소의 하나 이상의 청크 컨테이너도 또한 백업 저장장치에 저장된다.

휴리스틱스를 기초로 백업 기법이 선택될 수 있다. 선택된 백업 기법이 수행되어 복수의 최적화된 데이터 스트림을 백업 저장장치에 백업할 수 있다.

최적화된 데이터 스트림을 백업 저장장치로부터 복원하기 위한 구현예도 또한 기재된다. 백업 저장장치 내 청크 저장소로부터 최적화된 데이터 스트림을 불러오기 위한 요청이 수신된다. 상기 요청은 데이터 스트림에 대응하는 최적화된 스트림 메타데이터에 대한 식별자를 포함한다. 최적화된 스트림 메타데이터 식별자를 기초로 제 1 콜이 복원 애플리케이션으로 생성된다. 상기 제 1 콜은 최적화된 스트림 메타데이터 식별자에 의해 식별되는 최적화된 스트림 메타데이터를 저장하는 백업 저장장치 내 스트림 컨테이너에 대한 파일 명칭을 특정하고, 상기 스트림 컨테이너 내 최적화된 스트림 메타데이터에 대한 오프셋을 특정한다. 최적화된 스트림 메타데이터는 제 1 콜에 응답하여 수신된다. 최적화된 스트림 메타데이터에서 참조된 적어도 하나의 데이터 청크 식별자가 식별된다. 최적화된 스트림 메타데이터에 의해 참조되는 데이터 청크 식별자(들)에 대응하는 적어도 하나의 추가 콜이 복원 애플리케이션으로 생성되어 백업 저장장치 내 적어도 하나의 청크 컨테이너로부터 적어도 하나의 데이터 청크를 획득할 수 있다. 상기 데이터 청크(들)는 추가 콜(들)에 응답하여 수신된다. 데이터 청크(들)는 데이터 스트림을 복원하기 위해 조합될 수 있다.

하나의 구현예에서, 최적화된 스트림 메타데이터에 의해 참조되는 데이터 청크 식별자는, 제 1 정렬 키로서 청크 컨테이너를, 그리고 제 2 키로서 청크 오프셋을 기초로 하여, 정렬될 수 있다. 데이터 청크를 불러오기 위한 복원 애플리케이션으로의 콜은 정렬에 의해 정의된 순서로 생성될 수 있다.

하나의 구현예에서, 복원 엔진이 복원 플랜을 이용해 복원 애플리케이션을 호출할 수 있으며, 이는, 캐싱 및 미리-읽기 동작을 수행함으로써 복원 애플리케이션이 최적화를 수행할 수 있도록, 데이터 청크를 포함하는 백업 파일을 정렬함으로써 복원의 순서를 결정하거나, 복원 애플리케이션에게 어느 파일 익스텐트가 복원되려고 하는지에 대해 알리는 요청을 포함할 수 있다.

최적화된 데이터 스트림의 백업 및/또는 복원에 대한 시스템의 구현이 기재된다. 하나의 구현예에서, 데이터 백업 모듈은 청크 저장소에 백업되도록 저장된 복수의 최적화된 데이터 스트림의 식별을 수신한다. 상기 데이터 백업 모듈은 백업 저장장치에 청크 저장소의 적어도 일부분을 저장하여 복수의 최적화된 데이터 스트림을 백업하도록 구성된다.

구현예에서, 데이터 백업 모듈은, 최적화된 파일 백업 모듈, 원상회복 백업 모듈, 아이템 레벨 백업 모듈, 및/또는 데이터 청크 식별자 백업 모듈을 포함할 수 있다. 상기 최적화된 파일 백업 모듈은 청크 저장소의 전체를 백업 저장장치에 저장하고, 또한 최적화된 데이터 구조를 최적화된 데이터 스트림에 대한 재분석 포인트(reparse point)로서 저장하도록 구성된다. 원상회복 백업 모듈은 각각의 최적화된 데이터 스트림을 최적화된 스트림 메타데이터에 의해 참조되는 임의의 데이터 청크를 포함하는 대응하는 역-최적화된 데이터 스트림으로 원상회복하도록 구성된다. 원상회복 백업 모듈은 각각의 역-최적화된 데이터 스트림을 백업 저장장치에 저장한다. 아이템 레벨 백업 모듈은 각각의 최적화된 데이터 스트림에 대해, 백업 저장장치에 이미 저장된 것이 아닌 최적화된 데이터 스트림의 최적화된 스트림 메타데이터의 메타데이터에 의해 참조되는 하나 이상의 데이터 청크를 결정하도록 구성된다. 상기 아이템 레벨 백업 모듈은 최적화된 데이터 스트림의 최적화된 스트림 메타데이터를 백업 저장장치에 저장하고, 백업 저장장치 내 복사본(duplicate)이 없다고 결정된 하나 이상의 데이터 청크를 저장한다. 데이터 청크 식별자 백업 모듈은 각각의 최적화된 데이터 스트림의 최적화된 스트림 메타데이터를 분석하여 최적화된 스트림 메타데이터에 의해 참조되는 데이터 청크(들)에 대한 적어도 하나의 데이터 청크 식별자를 결정한다. 상기 데이터 청크 식별자 백업 모듈은 각각의 최적화된 데이터 스트림을 대응하는 데이터 청크 식별자(들)과 함께 백업 저장장치에 저장하고, 청크 저장소의 하나 이상의 청크 컨테이너를 백업 저장장치에 저장한다.

하나의 구현예에서, 데이터 백업 모듈은 휴리스틱스 모듈을 포함할 수 있다. 상기 휴리스틱스 모듈은, 가령, 백업될 데이터 스트림의 크기, (중복되는 데이터 청크를 제거하기 위한) 중복제거 후 데이터 스트림의 크기, 청크 저장소의 전체 크기와 같은 휴리스틱스 및 추가적인 휴리스틱스, 가령, 이들 크기를 기초로 생성될 수 있는 휴리스틱스를 포함하는 휴리스틱스를 기초로 백업 기법을 선택하도록 구성된다. 상기 휴리스틱스 모듈은 백업 기법이 수행되게 하여 백업 저장장치에 복수의 최적화된 데이터 스트림을 백업하게 한다.

또 다른 구현예에서, 데이터 복원 모듈은 백업 저장장치로부터 최적화된 데이터 스트림을 복원하도록 구성된다. 상기 데이터 복원 모듈은 백업 저장장치 내 청크 저장소로부터 데이터 스트림을 불러오기 위한 요청을 수신한다. 상기 요청은 데이터 스트림에 대응하는 최적화된 스트림 메타데이터에 대한 식별자를 포함한다. 상기 파일 재구성기는 콜백 모듈(가령, 백업/복원 시스템에 의해 제공되는 것)을 포함한다. 상기 콜백 모듈은 최적화된 스트림 메타데이터 식별자를 기초로 복원 애플리케이션으로 제 1 콜을 생성한다. 상기 제 1 콜은 최적화된 스트림 메타데이터 식별자에 의해 식별되는 최적화된 스트림 메타데이터를 저장하는 백업 저장장치 내 제 1 청크 컨테이너에 대한 파일 명칭을 특정하고, 제 1 청크 컨테이너 내 최적화된 스트림 메타데이터에 대한 오프셋을 특정한다. 파일 재구성기는 제 1 콜에 응답하여 최적화된 스트림 메타데이터를 수신하고 최적화된 스트림 메타데이터에서 참조되는 적어도 하나의 데이터 청크 식별자를 결정한다. 상기 콜백 모듈은 데이터 청크 식별자(들)에 대응하는 적어도 하나의 추가 콜을 복원 애플리케이션으로 생성하여 백업 저장장치 내 하나 이상의 청크 컨테이너로부터 하나 이상의 데이터 청크를 획득할 수 있다. 상기 파일 재구성기는 추가 콜(들)에 응답하여 데이터 청크(들)를 수신하고, 데이터 청크(들)을 조합하여 데이터 스트림을 복원할 수 있다. 또는, 파일 재구성기가 최적화된 스트림 메타데이터 및 데이터 청크(들)를 청크 저장소에 저장하고, 상기 청크 저장소에 저장된 청크를 참조하는 데이터 스트림에 대한 최적화된 스트림 구조가 저장장치에 저장될 수 있다.

상기 콜백 모듈은 또한 복원 플랜을 이용해 복원 애플리케이션을 호출할 수 있으며, 이는, 캐싱 및 미리-읽기 동작을 수행함으로써 복원 애플리케이션이 최적화를 수행할 수 있도록, 데이터 청크를 포함하는 백업 파일을 정렬함으로써 복원의 순서를 결정하거나, 복원 애플리케이션에게 어느 파일 익스텐트가 복원되려고 하는지에 대해 알리는 요청을 포함할 수 있다.

최적화된 데이터 스트림을 백업 저장장치로 백업하고, 최적화된 데이터 스트림을 백업 저장장치로부터 복원하며, 본원에 기재된 추가 실시예를 위한 컴퓨터 프로그램 프로덕트도 또한 본원에서 기재된다.

본 발명의 추가 특징 및 이점과 본 발명의 다양한 실시예의 구조 및 동작이 도면을 참조하여 이하에서 구체적으로 기재된다. 본 발명은 본원에 기재된 특정 실시예에 한정되지 않음을 알아야 한다. 이러한 실시예는 단지 설명 목적으로 제공되는 것에 불과하다. 본원의 설명을 기초로 해당 분야의 통상의 기술자라면 추가 실시예가 자명하게 알 것이다.

여기에 포함되며 본 명세서의 일부를 형성하는 첨부된 도면은 본 발명의 예시를 제공하며, 상세한 설명과 함께, 본 발명의 원리를 설명하고 해당 업계의 종사자가 본 발명을 제작하고 사용하도록 하는 역할을 가진다.
도 1은 하나의 예시적 실시예에 따르는 데이터 중복제거 시스템의 블록도를 도시한다.
도 2는 하나의 예시적 실시예에 따르는 청크 저장소의 블록도를 도시한다.
도 3은 하나의 예시적 실시예에 따르는 청크 저장소의 블록도를 도시한다.
도 4는 하나의 예시적 실시예에 따르는 데이터 스트림 저장 시스템의 블록도를 도시한다.
도 5는 하나의 예시적 실시예에 따라 데이터 스트림을 저장하기 위한 흐름도를 도시한다.
도 6은 하나의 실시예에 따라 데이터 스트림을 데이터 저장소에 저장하기 위한 일례를 도시하는 블록도이다.
도 7은 하나의 예시적 실시예에 따르는 원상회복 모듈을 포함하는 청크 저장소 인터페이스의 블록도를 도시한다.
도 8은 하나의 예시적 실시예에 따르는 청크 컨테이너의 블록도를 도시한다.
도 9는 하나의 예시적 실시예에 따르는 리디렉션 테이블의 블록도를 도시한다.
도 10은 하나의 예시적 실시P에 따라 데이터 스트림을 저장하기 위한 흐름도를 도시한다.
도 11은 하나의 예시적 실시예에 따라, 데이터 스트림을 원상회복하기 위해 청크 저장소를 액세스하는 원상회복 모듈의 블록도를 도시한다.
도 12는 하나의 예시적 실시예에 따라, 데이터 최적화 시스템에서 데이터의 백업을 수행하기 위한 흐름도를 도시한다.
도 13은 하나의 예시적 실시예에 따라 데이터 백업 시스템의 블록도를 도시한다.
도 14-17은 예시적 실시예에 따라, 최적화된 데이터 스트림에 대한 다양한 백업 기법을 수행하기 위한 흐름도를 도시한다.
도 18은 하나의 예시적 실시예에 따라 휴리스틱스를 기초로 백업 기법을 선택하고 실행하기 위한 프로세스를 제공하는 흐름도를 도시한다.
도 19는 하나의 예시적 실시예에 따라 데이터 최적화 시스템에서 백업 데이터의 복원을 수행하기 위한 흐름도를 도시한다.
도 20은 하나의 예시적 실시예에 따르는 데이터 복원 시스템의 블록도를 도시한다.
도 21은 하나의 실시예에 따라 재분배 테이블을 액세스하는 콜백 모듈의 블록도를 도시한다.
도 22는 하나의 예시적 실시예에 따라, 청크에 대한 업데이트된 오프셋을 획득하기 위해 재분배 테이블을 액세스하기 위한 프로세스를 제공하는 흐름도를 도시한다.
도 23은 하나의 예시적 실시예에 따르는 파일 재구성기의 블록도를 도시한다.
도 24는 하나의 예시적 실시예에 따라 데이터 청크 복원 순서를 저장하기 위한 프로세스를 제공하는 흐름도를 도시한다.
도 25는 본 발명의 실시예를 구현하기 위해 사용될 수 있는 예시적 컴퓨터의 블록도를 도시한다.
본 발명의 특징 및 이점은 도면을 함께 참조할 때 이하에서 제공되는 발명을 실시하기 위한 구체적인 내용으로부터 더 명백해질 것이며, 여기서 유사한 참조 기호는 대응하는 요소를 식별한다. 도면에서, 일반적으로 유사한 도면 부호는 동일한, 기능적으로 유사한, 및/또는 구조적으로 유사한 요소들을 가리킨다. 요소가 처음 나타나는 도면의 번호가 대응하는 부면 부호 내 최좌측 숫자로 나타내어 진다.

Ⅰ. 서문

본 명세서는 본 발명의 특징들을 포함하는 하나 이상의 실시예를 개시한다. 개시되는 실시예(들)은 본 발명의 예시에 불과하다. 본 발명의 범위는 개시된 실시예(들)에 국한되지 않는다. 본 발명은 특허청구범위에 의해 정의된다.

본 명세서에서 "하나의 실시예", "일 실시예", "하나의 예시적 실시예, 등등의 언급은 기재된 실시예가 특정 특징, 구조물, 또는 특성을 포함할 수 있지만, 모든 실시예가 상기 특정 특징, 구조물, 또는 특성을 반드시 포함하는 것은 아닐 수 있음을 의미한다. 덧붙여, 이러한 구문들이 반드시 동일한 실시예를 지칭하는 것도 아니다. 덧붙여, 특정 특징, 구조물, 또는 특성이 하나의 실시예와 관련하여 기재될 때, 명시적 기재의 존재 여부와 무관하게, 해당 분야의 통상의 기술자의 지식 내에서 이러한 특징, 구조물, 또는 특성은 또 다른 실시예와 관련하여 사용될 수 있다.

본 명세서에서 최적화된 데이터는 데이터 중복제거 기법, 가령, 청크(chunk)의 단일 인스턴싱 및 압축 중 하나 이상에 의해 최적화 또는 중복제거된 데이터를 일컫는다. 최적화된 스트림은 중복제거된 스트림, 즉, 데이터 중복제거 기법을 이용해 최적화된 데이터를 갖는 스트림을 일컫는다.

Ⅱ. 예시적 실시예

실시예들은 데이터 중복제거를 위한 기법을 제공한다. 이러한 실시예는 데이터의 충실도나 무결성을 희생시키지 않고 저장되거나 전송될 데이터의 양(가령, 바이트 수)이 감소될 수 있도록 한다. 예를 들어, 실시예는 최적화된 데이터를 액세스하는 데 걸리는 대기시간의 단축을 가능하게 한다. 덧붙여, 실시예는 자원 소비량을 감소시켜, 자원, 가령, 컴퓨팅 기계/장치가 더 효율적으로 사용될 수 있게 한다. 또한, 실시예는 중복제거된 데이터를 백업하기 위한, 그리고 저장되는 디지털 데이터의 양의 성장에 맞춰 확장 가능한(scalable) 저장장치로부터 백업된 데이터를 복원하기 위한, 데이터 중복제거용 기법을 제공한다.

예를 들어, 하나의 실시예에서, 확장 가능한 청크 저장소(scalable chunk store)가 데이터 중복제거를 위해 제공된다. 상기 청크 저장소는 최적화된 데이터를 액세스할 시의 대기시간을 최소화하고, 기계 자원 소비량(가령, 메모리 및 디스크 I/O)을 감소시키고, 데이터 중복제거, 데이터의 백업, 및 데이터의 복원 동안 신뢰성을 강화하기 위한 다양한 기법을 가능하게 한다. 예시적 실시예가 다음의 서브섹션에서 더 상세히 기재된다.

A. 예시적 데이터 중복제거 실시예

실시예에서, 데이터에 대해 요구되는 저장소의 크기를 감소시키기 위해 저장될 데이터가 최적화될 수 있다. 예를 들어, 데이터 스트림이 고유 데이터 청크의 형태로 저장될 수 있다. 상기 데이터 청크는 데이터 스트림을 정의하는 최적화된 스트림 메타데이터에 의해 참조될 수 있다. 이러한 방식으로, 복수의 데이터 스트림에 대한 메타데이터가 동일한 데이터 청크가 복수 회 저장되는 대신 하나의 저장된 데이터 청크를 참조할 수 있기 때문에 데이터 스트림이 더 효율적으로 저장된다. 덧붙여, (가령, 애플리케이션에 의해) 필요할 때 저장소로부터 최적화된 데이터가 요청될 수 있다. 이 경우, 데이터 스트림은 대응하는 메타데이터에 따라 저장된 데이터 청크로부터 재-어셈블(reassemble)될 수 있다.

예를 들어, 도 1은 예시적 실시예에 따라, 데이터 중복제거 시스템(100)의 블록도를 도시한다. 도 1에 도시된 바와 같이, 시스템(100)은 저장 시스템(102), 데이터 중복제거 모듈(104), 유지관리 모듈(106), 및 저장장치(108)를 포함한다. 덧붙여, 저장 시스템(102)은 데이터 스트림 API(application programming interface)(110), 청크 유지관리 API(112), 및 데이터 액세스 API(114)를 포함한다. 시스템(100)은 최적화된 데이터의 저장, 및 저장장치로부터의 최적화된 데이터의 복원을 설명하기 위해 다음과 같이 기재되나, 이에 한정되지 않는다.

시스템(100)은 데이터가 효율적인 방식으로 저장장치(108)에 저장되게 하고, 데이터를 상기 저장장치(108)로부터 불러오도록 구성된다. 예를 들어, 하나의 실시예에서, 데이터 중복제거 모듈(104)이 제공될 수 있다. 상기 데이터 중복제거 모듈(104)은 수신된 데이터를 저장에 최적화하도록 구성된다. 예를 들어, 데이터 중복제거 모듈(104)은 데이터 스트림(132)으로서 수신된 데이터를 압축할 수 있다. 데이터 스트림(132)은 데이터 파일의 일부분, 단일 데이터 파일, 복수의 데이터 파일, 및/또는 파일 및/또는 파일 일부분의 임의의 조합을 포함할 수 있다. 도 1에 도시된 바와 같이, 데이터 중복제거 모듈(104)은, 데이터 스트림(132)의 압축 및 세그먼트화된 버전일 수 있는 데이터 청크(124)를 생성한다.

데이터 스트림 API(110)는 저장 시스템(102)이 데이터 청크(124)를 수신하기 위한 인터페이스를 제공한다. 데이터 청크(124)는 데이터 스트림(132)을 형성하는 복수의 데이터 청크를 포함할 수 있으며, 상시 데이터 스트림(132)으로부터 데이터 청크(124)가 생성된다. 데이터 스트림 API(110)는 해당 분야의 통상의 기술자에게 자명할 임의의 적합한 방식으로 구성될 수 있다. 데이터 스트림 API(110)는 청크 저장 인터페이스(116)에 의해 수신될 데이터 청크(124)를 출력할 수 있다.

도 1에 도시된 것처럼, 저장장치(108)는 저장 시스템(102)과 연결된다. 청크 저장 인터페이스(116)는 API(110, 112, 및 114)와 저장장치(108) 간의 인터페이스이다. 예를 들어, 청크 저장 인터페이스(116)는 데이터 청크(124)를 수신하고 데이터 청크(124) 중 데이터 청크를 저장장치(108)에 저장할 수 있다. 예를 들어, 도 1에 도시된 바와 같이, 저장장치(108)는 청크 저장소(118)를 포함한다. 청크 저장 인터페이스(116)는 데이터 청크(124)의 수신된 데이터 청크를 청크 저장소(118)에 데이터 청크(128)로서 저장할 수 있다.

데이터 액세스 API(114)는 애플리케이션이 저장 시스템(102)의 데이터를 요청하기 위한 인터페이스를 제공한다. 예를 들어, 도 1에 도시된 바와 같이, 데이터 액세스 API(114)는 데이터 스트림 요청(120)을 수신할 수 있다. 데이터 액세스 API(114)는 해당 분야의 통상의 기술자에게 알려져 있을 임의의 적합한 방식으로 구성될 수 있다. 데이터 액세스 API(114)는 청크 저장 인터페이스(116)에 의해 수신될 데이터 스트림 요청(120)을 출력할 수 있다. 청크 저장 인터페이스(116)는 저장장치(108)(가령, 청크 저장소(118))로부터, 데이터 스트림 요청(120) 중 요청된 데이터 스트림에 대응하는 데이터 청크를 요청할 수 있다. 청크 저장 인터페이스(116)는 저장장치(108)로부터 요청된 데이터 청크를 데이터 청크(130)로서 수신하고, 데이터 청크(130)를 포함하는 데이터 스트림을 데이터 액세스 API(114)로 제공할 수 있다. 데이터 액세스 API(114)는 데이터 스트림을 데이터 스트림 응답(122)으로서 요청하는 애플리케이션으로 제공할 수 있다.

덧붙여, 청크 저장소(118)에 저장된 데이터 청크와 관련해 하나 이상의 유형의 유지관리 일을 수행하기 위해 유지관리 모듈(106)이 제공될 수 있다. 예를 들어, 유지관리 모듈(106)은 저장장치(108)에 저장되는 데이터 청크의 단편화제거(defragmentation)를 수행하기 위해 단편화제거 모듈(defragmentation module)을 포함할 수 있다. 예를 들어, 단편화제거 모듈은 저장장치(108) 내 빈 공간을 제거(가령, 압축을 수행)하도록, 관련 데이터 청크들을 이동시켜 하나의 시퀀스를 만들도록, 및/또는 그 밖의 다른 관련 작업을 수행하도록 구성될 수 있다. 또 다른 예에서, 유지관리 모듈(106)은 저장장치(108)에 저장된 데이터 청크의 가비지 콜렉션(garbage collection)을 수행하기 위한 가비지 콜렉션 모듈을 포함할 수 있다. 예를 들어, 가비지 콜렉션 모듈은 저장장치(108) 내 미사용 데이터 청크를 삭제하도록 구성될 수 있다. 추가 실시예에서, 유지관리 모듈(106)은 저장장치(108)와 관련하여 추가적인 또는 대안적인 유지관리 작업을 수행할 수 있다.

도 1에 도시된 것처럼, 청크 유지관리 API(112)는 유지관리 모듈(106)이 저장 시스템(102)과 상호대화하기 위한 인터페이스를 제공한다. 상기 유지관리 모듈(106)은 청크 유지관리 API(112)에 의해 수신되는 유지관리 작업(126)(가령, 단편화제거 명령, 압축 명령, 데이터 청크 삭제 명령, 등등)을 생성할 수 있다. 청크 유지관리 API(112)는 해당 분야의 통상의 기술자에게 자명할 임의의 적합한 방식으로 구성될 수 있다. 청크 유지관리 API(112)는 청크 저장 인터페이스(116)로 유지관리 작업(126)을 제공할 수 있다. 청크 저장 인터페이스(116)는 유지관리 작업(126)이 저장장치(108)에 저장된 데이터 청크에 대해 수행되는 것을 가능하게 할 수 있다.

저장 시스템(102)은 임의의 적합한 형태로, 가령, 하나 이상의 컴퓨터/컴퓨팅 장치, 등등의 형태로 구현될 수 있다. 저장장치(108)는 임의의 유형의 저장장치 메커니즘, 가령, 자기 디스크(가령, 하드 디스크 드라이브 내의 것), 광학 디스크(가령, 광학 디스크 드라이브 내의 것), 자기 테이프(가령, 테이프 드라이브 내의 것), 및/또는 그 밖의 다른 임의의 적합한 유형의 저장장치 매체 중 하나 이상을 포함할 수 있다.

데이터 중복제거 시스템(100)은 본 발명의 실시예가 구현될 수 있는 환경의 일례이다. 상기 데이터 중복제거 시스템(100)은 설명을 목적으로 제공되며, 이에 한정되는 것은 아니다. 실시예들은 다른 유형 및 구성의 데이터 중복제거 시스템에 포함될 수 있다.

B. 데이터 청크 로컬리티를 가능하게 하는 예시적 청크 저장소 실시예

도 1의 청크 저장소(118)는 임의의 방식으로 데이터 스트림을 데이터 청크의 형태로 저장할 수 있다. 예를 들어, 청크 저장소(118)는 최적화된 스트림 메타데이터를 데이터 스트림 내 포함된 데이터 청크를 가리키는 맵, 데이터베이스, 또는 그 밖의 다른 형태로 저장할 수 있다. 청크 저장소(118)는 참조된 데이터 청크를 추가로 저장할 수 있다. 실시예에서, 청크 저장소(118)는 데이터 중복제거 기법에 따라 데이터 청크의 복사본(duplicate)을 저장하지 않는다.

예를 들어, 도 2는 예시적 실시예에 따르는 청크 저장소(118)의 블록도를 도시한다. 도 2에 도시된 것과 같이, 청크 저장소(118)는 스트림 컨테이너(stream container)(202)와 청크 컨테이너(chunk container)(204)를 포함한다. 스트림 컨테이너(202)는 하나 이상의 데이터 스트림에 대한 최적화된 스트림 메타데이터(206)를 포함하고, 청크 컨테이너(204)는 복수의 데이터 청크(208)를 포함한다. 데이터 청크(208)는 하나 이상의 데이터 스트림(가령, 도 1의 데이터 스트림(132))에 의해 참조되는 데이터의 세그먼트(segment)이다. 최적화된 스트림 메타데이터(206)는 원본 데이터 스트림 구조와 최적화된 데이터 청크 구조 간의 매핑(mapping)을 기술하는 데이터 구조이다. 참조된 데이터 청크를 찾고 하나의 파일 스트림 뷰(file stream view)로 어셈블하기 위해, 최적화된 스트림 메타데이터(206)는 직접 또는 간접 레이어(indirection layer)을 통해 데이터 청크 위치 정보를 포함한다. 실시예에서, 최적화된 스트림 메타데이터(206)는 다양한 형태를 가질 수 있으며, 예를 들어, 스트림 맵(각각의 스트림 맵이 대응하는 데이터 스트림에 대한 데이터 청크 위치를 가리킴), 데이터베이스 또는 전역 테이블(global table), 또는 그 밖의 다른 형태를 가질 수 있다. 도 2의 예에서, 데이터 청크(208) 및 최적화된 스트림 메타데이터(206)가 각각, 파일 시스템 내 파일일 수 있는 스트림 컨테이너(202) 및 청크 컨테이너(204)에 저장된다. 하나의 실시예에서, 최적화된 스트림 메타데이터(206)가 파일 스트림-데이터 청크(208) 매핑, 데이터 청크 주소, 및 해시(hash)를 기술하기 위한 내부 메타데이터(데이터 스트림 메타데이터)를 포함하는 데이터 청크로서 저장(가령, 각각의 스트림 맵이 하나의 데이터 청크로서 저장)되도록, 청크 저장소(118)는 모든 데이터를 청크의 형태로 저장할 수 있다. 대안적으로, 최적화된 스트림 메타데이터(206)가 다른 형태(가령, 중앙 데이터베이스 또는 테이블, 등등)로 저장될 수 있다.

실시예에서, 스트림 컨테이너(202) 및 청크 컨테이너(204)는 다양한 방식으로 구성될 수 있다. 예를 들어, 도 3은 하나의 예시적 실시예에 따르는 청크 저장소(300)의 블록도를 도시한다. 청크 저장소(300)는 도 2의 청크 저장소(118)의 하나의 예이다. 도 3에 도시된 것처럼, 청크 저장소(300)는 저장장치 컨테이너(302)와 청크 컨테이너(304)를 포함한다. 저장장치 컨테이너(302)는 도 2의 저장장치 컨테이너(202)의 일례이고, 청크 컨테이너(304)는 도 2의 청크 컨테이너(204)의 일례이다. 도 3의 실시예에서, 저장장치 컨테이너(302)는 파일 헤더(306), 리디렉션 테이블(redirection table)(308), 및 복수의 스트림 맵(310)을 포함한다. 스트림 맵(310)은 설명의 편의를 위해 제공된 최적화된 스트림 메타데이터(206)의 일례이다. 설명을 위해, 최적화된 스트림 메타데이터(206)는 종종 본원에서 스트림 맵에 대해 기재될 수 있지만, 그 밖의 다른 실시예에서, 대안적으로, 최적화된 스트림 메타데이터(206)는 데이터베이스, 전역 테이블(global table), 등등으로서 저장될 수 있음을 이해해야 한다.

제 1 및 제 2 스트림 맵(310a 및 310b)이 도 3에서 설명을 목적으로 도시되어 있지만, 임의의 개수의, 가령, 수 백, 수 천, 및 이보다 훨씬 더 많은 개수의 스트림 맵(310)이 스트림 컨테이너(302)에 포함될 수 있다. 청크 컨테이너(304)는 파일 헤더(318), 리디렉션 테이블(320), 및 복수의 데이터 청크(322)를 포함한다. 제 1 및 제 2 데이터 청크(322a 및 322b)가 설명을 목적으로 도 3에 도시되지만, 실시예에서, 임의의 개수, 가령, 수 백, 수 천, 및 이보다 훨씬 더 많은 개수의 데이터 청크(322)가 청크 컨테이너(304)에 포함될 수 있다. 도 3의 이들 특징이 이하에서 기재된다.

스트림 컨테이너(302)가 파일로서 저장되는 실시예에서 파일 헤더(306)는 스트림 컨테이너(302)를 위한 파일 헤더이다. 파일 헤더(306)는 스트림 컨테이너(302)와 연관된 정보, 가령, 스트림 컨테이너 식별자(가령, 스트림 컨테이너 식별 번호) 등을 포함할 수 있다.

리디렉션 테이블(308)은 스트림 컨테이너(302)에서 선택적으로 제공된다. 제공될 때, 리디렉션 테이블(308)은 임의의 스트림 맵(310)의 스트림 컨테이너(302) 내 위치의 변화와 관련된 정보를 저장할 수 있다. 예를 들어, 제 1 스트림 맵(310a)은 스트림 컨테이너(302)로부터 삭제될 수 있고, (가령, 단편화제거 또는 압축 루틴으로 인해) 제 2 스트림 맵(310b)은 제 1 스트림 맵(310a)의 위치로 이동될 수 있다. 이동 후, 제 2 스트림 맵(310b)을 불러오기 위해 애플리케이션에 의해 스트림 컨테이너(302)가 액세스될 수 있다. 그러나 애플리케이션은 제 2 스트림 맵(310b)의 이전 위치를 여전히 이동하는 중일 수 있다. 리디렉션 테이블(308)은 제 2 스트림 맵(310b)의 현재 위치를 가리키는 제 2 스트림 맵(310b)에 대한 매핑을 포함할 수 있다. 따라서 애플리케이션은 제 2 스트림 맵(310b)의 현재 위치를 결정하기 위해 리디렉션 테이블(308)을 액세스할 수 있고, 따라서 제 2 스트림 맵(310b)을 이의 새로운 위치로부터 불러오는 것이 가능할 수 있다.

스트림 맵(310)은 도 2의 최적화된 스트림 메타데이터(206)의 예이다. 스트림 맵(310) 각각이 특정 데이터 스트림을 구성하는 데이터 청크(322)의 시퀀스를 결정하도록 사용된다. 도 3에 도시된 바와 같이, 스트림 맵(310) 각각은 스트림 헤더(312), 메타데이터(314), 및 해시 값(316)을 포함할 수 있다. 예를 들어, 제 1 스트림 맵(310a)은 스트림 헤더(312a), 메타데이터(314a), 및 해시 값(316a)을 포함하고, 제 2 스트림 맵(310b)은 스트림 헤더(312b), 메타데이터(314b), 및 해시 값(316b)을 포함하는 것으로 나타난다. 각각의 스트림 헤더(312)는 대응하는 스트림 맵(310)과 연관된 정보, 가령, 스트림 맵 식별자(가령, 스트림 맵 식별 번호), 등등을 포함한다. 메타데이터(314) 각각은 대응하는 스트림 맵(310)에 의해 정의되는 데이터 스트림을 구성하는 데이터 청크(322)를 기술하는 정보를 포함한다. 해시 값(316)은 선택적으로 제공된다. 해시 값(316)은 대응하는 스트림 맵(310)에 의해 정의되는 데이터 스트림을 구성하는 데이터 청크(322)에 대한 해시 값이다. 해시 값(316)은 스트림 맵(310)에 저장되어, 대응하는 데이터 스트림을 구성하는 데이터 청크의 해시 벡터로의 효율적인 액세스를 제공할 수 있다. 예를 들어, 이는 데이터 스트림 해시(최적화된 파일 청크 모두에 대한 해시)의 전체 리스트로의 고속 액세스가 바람직한 유선 데이터 전송 시나리오의 경우 유용할 수 있다.

메타데이터(314)는 데이터 청크별 메타데이터(per-data chunk metadata), 또는 데이터 청크 특정 메타데이터이며, 참조되는 데이터 청크(322) 각각에 대해 스트림 맵(310)에 포함될 수 있다. 다양한 유형의 정보가 메타데이터(314)에 포함될 수 있다. 예를 들어, 하나의 실시예에서, 데이터 청크(322)에 대한 메타데이터(314)는 데이터 스트림 오프셋, 데이터 청크 식별자, 및 로컬리티 지시자(locality indicator) 중 하나 이상을 포함할 수 있다. 데이터 스트림 오프셋은 특정 스트림 맵(310)에 의해 정의된 데이터 스트림 내 연관된 데이터 청크(322)의 위치(가령, 데이터 스트림의 시작 부분에서부터의 복수의 바이트 또는 연관된 데이터 청크(322)가 시작하는 데이터 스트림 내 그 밖의 다른 참조 포인트(reference point))를 가리킨다. 청크 아이디(id) 또는 "신뢰할만한 청크 로케이터"라고도 알려져 있는 데이터 청크 식별자는 청크 컨테이너(304) 내 대응하는 데이터 청크(322)로의 참조자 또는 포인터이다. 로컬리티 지시자는 청크 컨테이너(304) 내 청크 삽입 순서를 나타내는 정보이며, 공통 스트림 맵(310)에 의해 어느 데이터 청크(322)가 참조될 수 있는지를 결정할 수 있게 한다. 또 다른 실시예에서, 메타데이터(314)는 각각의 참조된 데이터 청크(322)에 대한 추가 및/또는 대안적 정보를 포함할 수 있다.

도 3의 청크 컨테이너(304)를 참조하면, 파일 헤더(318)는 청크 컨테이너(304)가 파일로서 저장되는 실시예에서 청크 컨테이너(302)에 대한 파일 헤더이다. 파일 헤더(318)는 청크 컨테이너(304)와 연관된 정보, 가령, 청크 컨테이너 식별자(가령, 청크 컨테이너 식별 번호), 청크 컨테이너(304)의 개정 번호를 가리키는 청크 컨테이너 세대 지시자(chunk container generation indicator), 등등을 포함할 수 있다.

리디렉션 테이블(320)은 청크 컨테이너(304)에 선택적으로 제공된다. 제공될 때, 리디렉션 테이블(320)은 데이터 청크(322)들 중 임의의 것의 청크 컨테이너(304) 내 위치의 변화와 관련된 정보를, 스트림 컨테이너(302)의 리디렉션 테이블(308)이 스트림 맵(310)의 위치의 변화를 다루는 방식과 유사하게, 저장할 수 있다.

데이터 청크(322)는 도 2의 데이터 청크(208)의 예시이다. 도 3에 도시될 때, 데이터 청크(322) 각각은 청크 헤더(324) 및 청크 데이터(326)를 포함한다. 예를 들어, 제 1 데이터 청크(322a)는 청크 헤더(324a) 및 청크 데이터(326a)를 포함하고, 제 2 데이터 청크(322b)는 청크 헤더(324b) 및 청크 데이터(326b)를 포함한다. 청크 헤더(312) 각각은 대응하는 데이터 청크(322)와 연관된 정보, 가령, 데이터 청크 식별자, 등을 포함한다. 각각의 청크 데이터(326)는 압축된 또는 비-압축된 형태일 수 있는 대응하는 데이터를 포함한다.

스트림 맵(310) 및 데이터 청크(322)는 각각 스트림 컨테이너(302) 및 청크 컨테이너(304)에 저장되어, 데이터 중복제거를 가능하게 한다. 예를 들어, 도 1의 청크 저장 인터페이스(116)는 데이터 스트림(132)과 연관된 데이터 청크(124)를 수신할 수 있고, 데이터 청크를 도 3의 청크 저장소(300)에 저장할 수 있다. 예를 들어, 특정 데이터 스트림(132)에 대해, 청크 저장 인터페이스(116)는 스트림 컨테이너(302)에 저장된 스트림 맵을, 청크 저장 인터페이스(116)에 의해 청크 컨테이너(304)에 저장된 하나 이상의 데이터 청크를 참조하는 스트림 맵(310)으로서 생성할 수 있다.

예를 들어, 도 3은 하나의 예시적 실시예에 따라 스트림 맵(310)에 의해 참조되는 일부 데이터 청크(322)를 나타낸다. 도 3에 나타난 바와 같이, 제 1 스트림 맵(310a)은 청크 컨테이너(304) 내에 제 1 및 제 2 데이터 청크(322a 및 322b)로의 참조자를 포함하는 메타데이터(314a)를 포함한다. 따라서 제 1 및 제 2 데이터 청크(322a 및 322b)는 제 1 스트림 맵(310a)과 연관된 소스 데이터 스트림에 포함된다. 예를 들어, 메타데이터(314a)는 제 1 스트림 맵(310a)에 의해 정의되는 소스 데이터 스트림 내 제 1 데이터 청크(322a)의 위치를 가리키는 제 1 데이터 청크(322a)에 대한 데이터 스트림 오프셋(402) 값, 청크 컨테이너(304) 내 제 1 데이터 청크(322a)에 대한 데이터 청크 식별자(404)(가령, 청크 헤더(324a)에 저장된 제 1 데이터 청크(322a)에 대한 데이터 청크 식별자), 및 제 1 데이터 청크(322a)에 대한 로컬리티 지시자를 포함할 수 있다. 덧붙여, 메타데이터(314a)는 소스 데이터 스트림 내 제 2 데이터 청크(322b)의 위치를 가리키는 제 2 데이터 청크(322b)에 대한 데이터 스트림 오프셋(402) 값, 청크 컨테이너(304) 내 제 2 데이터 청크(322b)에 대한 데이터 청크 식별자(404)(가령, 청크 헤더(324b)에 저장된 제 2 데이터 청크(322b)에 대한 데이터 청크 식별자), 및 제 2 데이터 청크(322b)에 대한 로컬리티 지시자(406)을 포함할 수 있다. 하나의 실시예에서, 제 1 및 제 2 데이터 청크(322a 및 322b)는 이들의 로컬리티 지시자에 대해 동일한 값을 가질 수 있으며, 상기 동일한 값은 제 1 스트림 맵(310a)에 의해 정의된 소스 데이터 스트림에 대응하도록 생성되고, 제 1 및 제 2 데이터 청크(322a 및 322b)가 청크 컨테이너(304)에 연속적으로(contiguously)(인접하게) 저장됨을 가리킨다.

덧붙여, 제 2 스트림 맵(310b)이 청크 컨테이너(304) 내 제 2 데이터 청크(322b)로의 참조자를 포함하는 메타데이터(314b)를 포함한다. 예를 들어, 메타데이터(314b)는 제 2 스트림 맵(310b)에 의해 정의된 소스 데이터 스트림 내 제 2 데이터 청크(322b)의 위치를 가리키는 제 2 데이터 청크(322b)에 대한 데이터 스트림 오프셋(402) 값, 청크 컨테이너(304) 내 제 2 데이터 청크(322b)에 대한 데이터 청크 식별자(404)(가령, 청크 헤더(324b)에 저장된 제 2 데이터 청크(322b)에 대한 데이터 청크 식별자), 및 제 2 데이터 청크(322b)를 위한 로컬리티 지시자(406)를 포함할 수 있다. 본래 제 2 데이터 청크(322b)가 제 1 스트림 맵(310a)에 대해 청크 컨테이너(304)에 저장되었기 때문에, 제 2 데이터 청크(322b)를 위한 메타데이터(314b) 내 상기 로컬리티 지시자(406)는 제 1 및 제 2 데이터 청크(322a 및 322b)에 대해 생성된 로컬리티 지시자와 동일한 값을 가진다. 제 2 스트림 맵(310b)에 의해 정의된 소스 데이터 스트림이 청크 저장소(300)에 저장될 때 청크 컨테이너(304)에 새로 저장된 임의의 추가 데이터 청크(322)(도 3에 도시되지 않음)가 로컬리티 지시자(406)에 대해 새로운 값을 할당받는다.

도 1의 청크 저장 인터페이스(116)는 도 3의 청크 저장소(300)에 데이터 스트림을 저장하기 위한 다양한 방식으로 구성될 수 있다. 예를 들어, 도 4는 예시적 실시예에 따라, 데이터 스트림 저장 시스템(400)의 블록도를 도시한다. 도 4에 도시된 바와 같이, 데이터 스트림 시스템(400)은 데이터 스트림 파서(data stream parser)(402), 청크 저장 인터페이스(116), 스트림 컨테이너(302), 및 청크 컨테이너(304)를 포함한다. 하나의 실시예에서, 데이터 스트림 파서(402)는 도 1의 데이터 중복제거 모듈(104)에 포함될 수 있다. 도 4의 실시예에서, 청크 저장 인터페이스(116)는 데이터 청크 저장 관리자(404), 메타데이터 생성기(406), 및 스트림 맵 생성기(408)를 포함한다. 도 4의 이들 특징부는 도 5를 참조하여 이하에서 기재된다. 도 5는 예시적 실시예에 따라 데이터 스트림을 저장하기 위한 흐름도(500)를 도시한다. 하나의 실시예에서, 도 4의 시스템(400)은 흐름도(500)에 따라 동작할 수 있다. 추가적인 구조 및 동작 실시예가 흐름도(500)와 관련된 설명을 기초로 하면 해당 분야의 통상의 기술자에게 자명할 것이다. 흐름도(500) 및 시스템(400)은 다음과 같이 설명된다.

흐름도(500)는 단계(502)로 시작한다. 단계(502)에서, 데이터 스트림이 데이터 청크들로 파싱(parsing)된다. 예를 들어, 도 4에 도시된 바와 같이, 데이터 스트림 파서(402)는 데이터 스트림(410)을 수신할 수 있다. 데이터 스트림(410)은 도 1의 데이터 스트림(132)과 유사하게, 하나 이상의 파일 및/또는 파일 일부분을 포함할 수 있다. 데이터 스트림 파서(402)는 데이터 스트림(410)을, 데이터 청크 시퀀스(412)로 나타나는 데이터 청크들의 시퀀스로 파싱하도록 구성된다. 예를 들어, 하나의 실시예에서, 데이터 청크 시퀀스(412)는 데이터 청크들이 데이터 스트림(410) 내에 위치하는 순서로 데이터 청크들의 시퀀스를 포함할 수 있다. 데이터 청크 시퀀스(412)의 데이터 청크들은 동일한 크기를 갖거나 서로 다른 크기를 가질 수 있다.

단계(504)에서, 데이터 청크들 중 임의의 것이 청크 컨테이너 내에 저장된 데이터 청크의 복사본인지 여부가 결정된다. 예를 들어, 도 4에 나타난 바와 같이, 데이터 청크 저장 관리자(404)는 데이터 청크 시퀀스(412)를 수신한다. 데이터 청크 저장 관리자(404)는 데이터 청크 시퀀스(412) 중 임의의 데이터 청크가 청크 컨테이너(304)에 이미 저장되어 있는지 여부와, 따라서 복사본인지의 여부를 결정하도록 구성된다. 예를 들어, 하나의 실시예에서, 도 4에서 도시된 바와 같이, 데이터 청크 저장 관리자(404)는 청크 컨테이너(304)로부터, 청크 컨테이너(304)에 저장된 데이터 청크(322) 각각에 대한 해시 값을 포함할 수 있는 데이터 청크 정보(426)를 수신할 수 있다. 또 다른 실시예에서, 데이터 청크 저장 관리자(404)는 스트림 컨테이너(302)로부터, 청크 컨테이너(304)에 저장된 데이터 청크(322)에 대한 해시 값인 해시 값(316)(도 3)을 수신할 수 있다. 데이터 청크 저장 관리자(404)는 데이터 청크 시퀀스(412)의 데이터 청크 각각에 대한 해시 값을 생성하고, 생성된 해시 값을 데이터 청크 정보(426) 내 수신된 해시 값(또는 스트림 컨테이너(302)로부터의 해시 값)에 비교하여, 데이터 청크 시퀀스(412) 중 어느 데이터 청크가 청크 컨테이너(304)에 이미 저장되어 있는지를 결정할 수 있다. 또 다른 실시예에서, 데이터 청크 저장 관리자(404)는 데이터 청크 시퀀스(412) 중 어느 데이터 청크가 청크 컨테이너(304)에 이미 저장되어 있는지를 해당 분야의 통상의 기술자에게 자명할 그 밖의 다른 방식으로 결정할 수 있다.

도 4에 도시된 바와 같이, 데이터 청크 저장 관리자(404)는 데이터 청크 시퀀스(412) 중 어느 데이터 청크가 청크 컨테이너(304) 내에 이미 저장되어 있는지를 가리키는 저장된 청크 표시(stored chunk indication)(416)를 생성한다.

도 5를 다시 참조하면, 단계(506)에서 복사본이 아니라고 결정된 데이터 청크가 청크 컨테이너에 연속 배열로 그리고 데이터 스트림에서와 동일한 시퀀스로 저장된다. 예를 들어, 하나의 실시예에서, 데이터 청크 저장 관리자(404)는 청크 컨테이너(304)에 저장됐다고 결정되지 않은 데이터 청크 시퀀스(412)의 데이터 청크를 저장하도록 구성될 수 있다. 예를 들어, 하나의 실시예에서, 데이터 청크 저장 관리자(404)는 각각의 새로운 데이터 청크에 대해 청크 헤더(324)(가령, 데이터 청크 식별자)를 생성하고 각각의 새로운 데이터 청크를 청크 헤더(324)와 청크 데이터(326)를 갖는 데이터 청크(322)로서 저장할 수 있다. 덧붙여, 하나의 실시예에서, 데이터 청크 저장 관리자(404)는 새로운 데이터 청크를 소스 데이터 스트림에서와 동일한 순서로(가령, 데이터 청크 시퀀스(412)에서 수신된 순서로) 연속 배열로 청크 컨테이너(304)에 저장하도록 구성된다.

단계(508)에서, 복사본이 아니라고 결정된 데이터 청크 각각에 대해 메타데이터가 생성되고, 데이터 청크에 대한 메타데이터는 데이터 스트림 오프셋, 청크 컨테이너 내 위치로의 포인터, 및 로컬리티 지시자를 포함한다. 예를 들어, 도 4에 도시된 바와 같이, 메타데이터 생성기(406)는 데이터 청크 시퀀스(412) 및 저장된 청크 표시(stored chunk indication)(416)를 수신할 수 있다. 하나의 실시예에서, 메타데이터 생성기(406)는 메타데이터(도 3의 메타데이터(314))를 생성하도록 구성될 수 있다. 메타데이터 생성기(406)는 데이터 스트림 오프셋(402), 데이터 청크 식별자(404), 및 로컬리티 지시자(406)를 포함하는, 데이터 청크 시퀀스(412)의 데이터 청크 각각에 대한 메타데이터를 생성할 수 있다. 청크 컨테이너(304)에 이미 저장된 것으로 결정된 데이터 청크에 대해(단계(504)), 데이터 청크 식별자(404)가 이미 저장된 데이터 청크를 가리키도록(point) 구성된다. 단계(508)에서 청크 컨테이너(304)에 새로 저장된 데이터 청크에 대해, 데이터 청크 식별자(404)가 새로 저장된 데이터 청크를 가리키도록 구성된다.

도 5를 다시 참조하면, 단계(510)에서, 생성된 메타데이터를 포함하는 데이터 스트림에 대한 스트림 맵이 생성된다. 예를 들어, 도 4에 도시된 바와 같이, 스트림 맵 생성기(408)는 특정 데이터 스트림에 대해 데이터 청크 시퀀스(412) 내 수신된 각각의 데이터 청크에 대해 데이터 청크 메타데이터(420)를 수신한다. 스트림 맵 생성기(408)는 수신된 데이터 청크 각각에 대한 데이터 청크 메타데이터(420)를 포함하는 데이터 스트림과 연관된 스트림 맵(424)을 생성한다. 덧붙여, 스트림 맵 생성기(408)는 스트림 맵(424)에 대한 스트림 헤더(312)를 생성할 수 있고, 스트림 맵(424) 내 각각의 수신된 데이터 청크에 대한 해시 값(316)을 포함할 수 있다.

단계(512)에서, 스트림 맵은 스트림 컨테이너에 저장된다. 예를 들어, 도 4에 도시된 바와 같이, 스트림 맵 생성기(408)는 스트림 맵(424)을 스트림 컨테이너(302)에 (가령, 스트림 맵(310)으로서) 저장할(또는 "영속"시킬) 수 있다. 대안적 실시예에서, 데이터 스트림에 대한 스트림 맵을 생성하고 저장하는 대신, 상기 데이터 스트림에 의해 참조되는 데이터 청크의 위치를 가리키거나 나타내는 메타데이터를 포함하는 데이터 스트림에 대한 항목(entry)이 데이터베이스 또는 전역 테이블에 만들어질 수 있다.

도 6은 하나의 실시예에 따라, 데이터 저장소에 데이터 스트림을 저장하는 하나의 예시를 나타내는 블록도를 도시한다. 도 6은 설명을 목적으로 제공되며, 제한하려는 것이 아니다. 도 6의 예시에서, 제 1 데이터 스트림(602a)이 데이터 저장소에 저장되고, 그 후, 제 2 데이터 스트림(602b)이 데이터 저장소에 저장된다. 스트림 링크(608a)("스트림 포인터(stream pointer)" 또는 "스트림 메타데이터 스터브(stream metadata stub)"라고도 알려짐)가 제 1 데이터 스트림(602a)에 대해 나타나며, 스트림 링크(608b)가 제 2 데이터 스트림(602b)에 대해 나타난다. 각각의 스트림 링크(608)는 데이터 스트림(602)을 데이터 스트림(602)이 재-어셈블(reassemble)되는 것을 가능하게 하는 청크 저장소 내 대응하는 데이터(가령, 스트림 맵(604) 또는 그 밖의 다른 최적화된 스트림 메타데이터)로 링크시킨다. 도 6에 도시된 바와 같이, 제 1 데이터 스트림(602a)은 4개의 데이터 청크(614a-614d)를 포함한다. 스트림 맵(604a)이 제 1 데이터 스트림(602a)에 대해 생성될 수 있고, 앞서 기술된 바와 같이, 4개의 데이터 청크(614a-614d)가 청크 컨테이너(606)에 저장될 수 있다. 스트림 맵(604a)은 데이터 청크(614a-614d) 각각으로의 포인터(도 6에서 화살표로 나타남)를 포함한다. 데이터 청크(614a-614d)는 청크 컨테이너(606)로의 모든 새로운 고유(unique) 데이터 청크들의 단일 세트로 카테고리화될 수 있다. 따라서 데이터 청크(614a-614d)가 연속 배열로 그리고 데이터 스트림(602a)에서와 동일한 순서로 청크 컨테이너(606)에 저장될 수 있다. 예를 들어, 데이터 청크(614a-614d)는 청크 컨테이너(606)에 저장된 첫 4개의 데이터 청크일 수 있거나, 하나 이상의 청크가 이미 청크 컨테이너(606)에 저장된 경우, 데이터 청크(614a-614d)는 청크 컨테이너(606)에서 이미 저장된 데이터 청크 바로 뒤에 저장될 수 있다. 스트림 맵(604a)에서 데이터 청크(614a-614d) 각각에 동일한 로컬리티 지시자 값이 할당되고, 상기 로컬리티 지시자 값은 첫 번째 데이터 스트림(602a)에 대해 선택된다.

제 2 데이터 스트림(602b)은 4개의 데이터 청크(614b, 614c, 614e, 및 614f)를 포함한다. 스트림 맵(604b)이 제 2 데이터 스트림(602b)에 대해 생성될 수 있다. 흐름도(500)의 단계(504)에 따라 데이터 청크(614b, 614c, 614e, 및 614f)는 다음의 데이터 청크의 2개의 세트로 카테고리화될 수 있다: (제 1 데이터 스트림(602a)의 청크 시퀀스로 인해) 청크 컨테이너(606)에 위치하는 복사본을 이미 갖는 청크(614b 및 614c)를 포함하는 제 1 세트, 및 (청크 컨테이너(606)에 이미 저장된 복사본을 갖지 않는) 새로운 고유 데이터 청크인 청크(614e 및 614f)를 포함하는 제 2 세트. 데이터 청크(614b 및 614c)가 청크 컨테이너(606)에 이미 저장되어 있기 때문에, 스트림 맵(604b)은 청크 컨테이너(606)에 이미 저장된 데이터 청크(614b 및 614c)로의 포인터(데이터 청크 식별자(404)에 대한 값)를 포함한다. 따라서, 데이터 청크(614b 및 614c)는, 데이터 청크(614b 및 614c)의 청크 데이터를 저장하지 않고, 청크 컨테이너(606) 내 기존 데이터 청크로의 포인터로서 저장될 수 있다. 데이터 청크(614e 및 614f)가 청크 컨테이너(606)에 이미 저장된 것이 아니기 때문에, 상기에서 기술된 바와 같이 데이터 청크(614e 및 614f)는 청크 컨테이너(606)에 저장될 수 있다. 예를 들어, 데이터 청크(614e 및 614f)가 청크 컨테이너(606)에게 새로운 고유 데이터 청크이기 때문에, 청크(614e 및 614f)는 청크 컨테이너(606)에 현재 마지막 저장된 데이터 청크(가령, 데이터 청크(614d)) 뒤에서, 연속 배열로, 데이터 스트림(602b)에서와 동일한 순서로 청크 컨테이너(606)에 저장될 수 있다. 스트림 맵(604b)은 청크 컨테이너(606)에 저장된 데이터 청크(614b, 614c, 614e, 및 614f)를 각각 가리키는(point) 제 1 내지 제 4 데이터 청크 식별자(612a-612d)를 포함한다. 스트림 맵(604b)에서, 데이터 청크(614b 및 614c)에 제 1 데이터 스트림(602a)과 연관된 로컬리티 지시자 값이 할당되고, 데이터 청크(614e 및 614f)에 제 2 데이터 스트림(602b)에 대해 선택된 로컬리티 지시자 값이 할당된다.

데이터 스트림(602a 및 602b)에 뒤 이어, 임의의 개수의 추가 데이터 스트림(602)이 유사한 방식으로 저장될 수 있다. 덧붙여, 도 6의 예시에서, 제 2 스트림 맵(604b)의 데이터 청크 각각에 2개의 로컬리티 지시자 값 중 하나(제 2 스트림 맵(604b)에 대해 선택된 새로운 로컬리티 지시자 값 또는 제 1 스트림 맵(604a)의 데이터 청크와 연관된 로컬리티 지시자 값)가 할당되었다. 실시예에서, 청크 컨테이너에 이미 존재하는 스트림 맵의 데이터 청크와 연관된 서로 다른 로컬리티 지시자의 수에 따라 달라지는 임의의 개수의 로컬리티 지시자 값 중 하나가 특정 스트림 맵의 데이터 청크에 할당될 수 있다. 예를 들면, 앞서 기술된 바와 같이, 청크 컨테이너에게 새로운 데이터 청크에, 스트림 맵과 연관된 특정 데이터 스트림에 대해 선택된 새로운 로컬리티 지시자 값이 할당될 수 있다. 덧붙여, 청크 컨테이너에 이미 존재하여 스트림 맵에 의해 참조되는 임의의 개수의 데이터 청크에, 청크 컨테이너에 이미 존재하는 데이터 청크의 대응하는 로컬리티 지시자 값이 할당된다. 이는, 데이터 스트림의 데이터 청크에 2개, 3개, 또는 더 많은 서로 다른 로컬리티 지시자 값 중에서 선택된 로컬리티 지시자가 할당될 수 있도록, 데이터 스트림의 데이터 청크의 하나 이상의 임의의 개수의 세트에 대응하는 로컬리티 지시자 값이 할당될 수 있음을 의미할 수 있다.

따라서, 스트림 맵 메타데이터의 로컬리티 지시자에 의해 데이터 스트림 내 데이터 청크의 로컬리티가 확인(ascertain)될 수 있다. 이는 복사된 데이터 청크가 그룹으로 나타나는 경향이 있기 때문이다. 새 데이터 스트림이 이미 알려진(청크 컨테이너에 이미 저장된) 데이터 청크를 포함할 때, 새 데이터 스트림 내 다음 데이터 청크도 역시 복사된 데이터 청크(청크 컨테이너에 이미 저장된 데이터 청크)일 합리적인 확률이 존재한다. 로컬리티 지시자에 따라 새로운 원본 데이터 청크가 청크 컨테이너에 서로 인접하여 저장되기 때문에, 새로운 데이터 스트림이 참조하는 이미 존재하는 데이터 청크도 청크 컨테이너에 연속으로(contiguously) 저장될 가능성이 더 높아진다. 이는 최적화된 데이터 스트림을 청크 저장소로부터 읽는 성능을 개선하는 데 도움이 된다. 예를 들어, 대응하는 스트림 맵 및 데이터 청크를 기초로 하여 데이터 스트림을 재-어셈블하도록 구성된 원상회복 모듈(rehydration module)이, 미리-읽힌 버퍼에서 다음 데이터 청크 수요를 찾기 위해 청크 컨테이너에 저장된 데이터 청크에 대해 미리-읽기(read-ahead)를 수행할 수 있다. 덧붙여, 기존의 인접한 청크들이 청크 컨테이너 안팎을 이동할 때 다함께로 유지함으로써 본래의 로컬리티를 유지하려 하면서, 청크 저장소 유지관리 작업, 가령, 단편화제거 및 압축이 수행될 수 있다.

예를 들어, 데이터 스트림이 최적화되고 청크 저장소(300)에 스트림 맵(310) 및 데이터 청크(322)의 형태로 저장된 후, 상기 데이터 스트림이 청크 저장소(300)로부터 읽힐 수 있다. 도 7은 하나의 예시적 실시예에 따르는, 원상회복 모듈(rehydration module)(702)을 포함하는 청크 저장 인터페이스(116)의 블록도를 나타낸다. 상기 원상회복 모듈(702)은 요청 받은(가령, 도 1에 도시된 데이터 스트림 요청(120)에 따라 요청 받은) 데이터 스트림을 재-어셈블하도록 구성된다. 예를 들어, 데이터 스트림 요청(120)(도 1)에 응답하여 데이터 스트림이 청크 저장소(300)로부터 읽히기 위해, 원상회복 모듈(702)은 청크 저장소(300)(가령, 재분석 위치(reparse location)에서)로부터 데이터 스트림 요청(120)의 최적화된 파일에 의해 참조되는 스트림 맵(310)을 결정 및 수신한다. 가령, 원상회복 모듈(702)은 요청(120)의 스트림 맵 식별자를 도 3의 청크 저장소(300)로 제공할 수 있다. 상기 청크 저장소(300)는 (가령, 스트림 맵 헤더(312)를 스캔함으로써) 스트림 맵 식별자를 기초로 하여 대응하는 스트림 맵(310)을 불러오고, 원상회복 모듈(rehydration module)(702)이 불러온 스트림 맵(310)에 따라 데이터 스트림을 재생성 또는 "원상회복"시킬 수 있다. 불러온 스트림 맵(310)은 데이터 스트림에 포함되는 청크 컨테이너(304) 내 데이터 청크 각각으로의 포인터(도 4의 데이터 청크 식별자(404))를 포함한다. 원상회복 모듈(702)은 포인터를 이용해 데이터 청크(322) 각각을 불러올 수 있다. 상기 원상회복 모듈(702)은 불러온 스트림 맵(310)(가령, 불러온 스트림 맵(310)에 포함될 수 있는 데이터 청크 길이 정보가 추가됨)에 포함된 데이터 스트림 오프셋(402)을 이용해 불러온 데이터 청크(322)를 적절한 순서로 배열해, 데이터 스트림을 재생성할 수 있고, 상기 데이터 스트림은 원상회복 모듈(702)에 의해 데이터 스트림(704)으로서 출력된다.

로컬리티 지시자(406)의 사용을 통해, 청크 컨테이너(304)로부터 데이터 청크(322)를 순차적으로 읽는 것이 수행될 수 있다. 예를 들어, 청크 저장소(300)에서 원상회복 모듈(702)에 의해 순차 I/O(입/출력) 요청, 또는 둘 이상의 데이터 청크 경계(data chunk boundary)를 아우르는 임의의 I/O 요청을 이용하여, 파일 스트림이 액세스되는 중일 때, 스트림 맵(310)은 데이터 청크로의 고속 액세스를 가능하게 한다. 이는 청크 저장소(300)가 스트림 맵(310)을 생성할 때, 새로운 데이터 청크가 청크 컨테이너(304)에 연속으로 스트림-맵 순서로 저장되기 때문이다. 따라서 원상회복 모듈(702)에 의한 순차 데이터 액세스 동안, 동일한 데이터 스트림에 속하는 데이터 청크들이 연속으로 저장될 가능성이 높고, 이러한 연속 데이터 청크들은 단일 데이터 액세스 "찾기(seek)"(가령, 읽힐 다음 저장된 데이터 청크를 찾기 위해 청크 컨테이너 안팎으로 이동)에 의해 액세스되고 읽힐 수 있고, 단편화(fragmentation)가 비-고유 데이터 청크(non-unique data chunk)(대응하는 데이터 스트림을 저장하기 전에 청크 컨테이너에 이미 존재하는 스트림 맵에 의해 참조되는 데이터 청크)로 감소된다. 순차 데이터 액세스 동안 데이터 액세스 찾기는 데이터 청크 또는 데이터 스트림의 일련의 청크가 청크 저장소에 이미 존재하는 것으로 발견된 경우로 제한된다. 스트림 맵(310)은 데이터 중복제거 시스템의 그 밖의 다른 모듈이 필요로 할 수 있는 최적화된 파일 메타데이터(가령, 메타데이터(314))(가령, 파일 복제 모듈(file replication module)에 의해 사용되는 해시 값들의 리스트)에 대한 효율적인 메타데이터 컨테이너를 제공한다. 고속 액세스를 위해 스트림 맵(310)은 간결하고 메모리에 캐싱될 수 있다. 청크 저장소(300)는 (원상회복 모듈(702)에 의해 빈번하게 요청되고 원상회복되는 최적화된 데이터 스트림에 대해) 최소 최근 사용(LRU: least recently used) 알고리즘 또는 그 밖의 다른 유형의 캐시 알고리즘을 기초로 하여 빈번하게 액세스되는 스트림 맵(310)을 캐싱할 수 있다.

C. 데이터 청크의 신뢰할만한 위치찾기를 가능하게 하는 예시적 청크 저장소 실시예

앞서 기술된 바와 같이, 데이터 청크는 다양한 이유로, 가령, 단편화제거 기법 때문에, 가비지 콜렉션을 수행하는 압축 기법 때문에, 그 밖의 다른 이유로, 청크 컨테이너 내에서 이동될 수 있다. 이 서브섹션에서 청크 컨테이너 내에서 데이터 청크의 이동을 계속 파악하기 위한 실시예가 기재된다.

도 8은 예시적 실시예에 따르는 청크 컨테이너(304)의 블록도를 도시한다. 도 8에 도시된 바와 같이, 청크 컨테이너(304)는 도 3의 청크 컨테이너(304)와 일반적으로 유사하며, 파일 헤더(318)에 포함되는 청크 컨테이너 식별자(802) 및 청크 컨테이너 세대 표시(chunk container generation indication)(804)를 추가로 가진다. 청크 컨테이너 식별자(802)는 청크 컨테이너(304)로 할당되어 상기 청크 컨테이너(304)를 청크 저장소(300)에 존재할 수 있는 그 밖의 다른 청크 컨테이너로부터 구별하도록 하는 고유 식별자(가령 식별 번호)이다. 청크 컨테이너 세대 표시(804)는 청크 컨테이너(304)에 대한 개정 또는 세대를 가리킨다. 예를 들어, 하나 이상의 데이터 청크(322)가 청크 컨테이너(304) 내에서 이동될 때마다, 세대 표시(804)는 수정될 수 있다(가령, 시작 세대 레벨, 가령, 0 또는 그 밖의 다른 시작 값에서부터 시작하여 다음 세대 레벨로 증분될 수 있다).

하나의 실시예에서, 청크 컨테이너(304)는 청크 컨테이너 식별자(802)와 청크 컨테이너 세대 표시(804)의 조합에 의해 식별될 수 있다(가령, 청크 컨테이너(304)의 파일 명을 형성할 수 있다). 하나의 실시예에서, 청크 컨테이너 식별자(802)와 청크 컨테이너 세대 표시(804) 모두 정수일 수 있다. 청크 컨테이너(304)는 고정된 크기(또는 고정 개수의 항목)을 갖거나, 가변 크기를 가질 수 있다. 예를 들어, 하나의 예시적 실시예에서, 청크 컨테이너(304)를 형성하는 청크 컨테이너 파일 각각이 약 16,000개의 청크를 저장하도록 크기가 정해질 수 있으며, 청크 컨테이너 파일의 크기가 1GB로 설정된 경우, 평균 데이터 청크 크기가 64KB이다. 또 다른 실시예에서, 청크 컨테이너 파일은 대안적 크기를 가질 수 있다.

메타데이터(400)의 데이터 청크 식별자(404)(도 4)에 따라 다양한 방식으로 청크 컨테이너(304)에 저장된 데이터 청크(322)가 참조될 수 있다. 실시예에서, 데이터 청크 식별자(404)는 이러한 참조를 가능하게 하기 위한 다양한 유형의 정보를 포함할 수 있다. 예를 들어, 하나의 실시예에서, 데이터 청크 식별자(404)는 데이터 청크 컨테이너 식별자, 로컬 식별자, 청크 컨테이너 세대 값, 및 청크 오프셋 값 중 하나 이상을 포함할 수 있다. 청크 컨테이너 식별자는 데이터 청크(322)가 저장되는 청크 컨테이너(304)에 대한 청크 컨테이너 식별자(802)의 값을 가진다. 로컬 식별자는 데이터 청크(322)로 할당되며, 상기 데이터 청크(322)가 저장되는 청크 컨테이너(304) 내에서 할당된 데이터 청크(322)에게 고유한 식별자(가령, 컨테이너별로 고유한 데이터 청크 식별자)(가령, 숫자 값)이다. 상기 청크 컨테이너 세대 값은, 데이터 청크(322)가 청크 컨테이너(304)에 저장될 때, 데이터 청크(322)가 저장되는 청크 컨테이너(304)에 대한 청크 컨테이너 세대 표시(804)의 값을 가진다. 청크 오프셋 값은, 데이터 청크(322)가 청크 컨테이너(304)에 추가될 때, 청크 컨테이너(304) 내 데이터 청크(322)의 오프셋이다.

하나의 실시예에서, 청크 저장소는 이동된 데이터 청크를 추적하기 위해 사용될 수 있는 신뢰할만한 청크 로케이터(chunk locator)를 구현할 수 있다. 종래의 기법과 달리, 신뢰할만한 청크 로케이터는 데이터 청크 식별자를 물리 청크 위치로 매핑하기 위한 인덱스(index)를 사용하지 않는다. 종래의 기법은 청크 식별자를 청크 데이터 물리 위치로 매핑하는 인덱스를 이용한다. 저장 시스템의 규모(가령, 수백 테라바이트 또는 그 이상) 및 평균 청크 크기(가령, 64KB)가 이러한 인덱스를 매우 크게 만든다. 이러한 인덱스가 메모리에 전체적으로 로딩되는 경우, 이용 가능한 메모리 및 프로세서 자원의 많은 부분을 소비할 것이다. 상기 인덱스가 메모리에 로딩되지 않은 경우, 인덱스가 메모리로 호출될 필요가 있기 때문에 데이터 액세스가 느려진다.

하나의 실시예에서, 신뢰할만한 청크 로케이터가 리디렉션 테이블(redirection table), 가령, 도 3의 청크 컨테이너(304)의 리디렉션 테이블(320)의 형태로 구현된다. 리디렉션 테이블은 청크 컨테이너(304)에서 이동된 적이 있는 데이터 청크(322)에 대한 하나 이상의 항목(entry)을 저장할 수 있다. 각각의 항목은 이동된 데이터 청크(322)를 식별하고, 새로운 위치에서 청크 컨테이너(304) 내 데이터 청크(322)의 위치를 가리키는 데이터 청크 오프셋 값을 가진다. 데이터 스트림의 원상회복(rehydration) 동안, 이동된 적 있는 데이터 스트림의 임의의 데이터 청크의 위치를 찾기 위해 리디렉션 테이블이 참조될 수 있다.

예를 들면, 도 9는 하나의 예시적 실시예에 따라 리디렉션 테이블(900)의 블록도를 나타낸다. 데이터 청크(322)가 청크 컨테이너(304) 내에서 이동되는 경우 리디렉션 테이블(900)은 (데이터 청크로서 저장된 스트림 맵을 포함하여) 데이터 청크(322)의 위치를 찾기 위해 사용된다. 예를 들어, 리디렉션 테이블(900)에 의해, 가비지 콜렉션 및 압축 프로세스의 일부로서 공간 회수(space reclamation)를 위해, 데이터 청크(322)가 청크 컨테이너(304) 내에서 이동될 수 있으며, 여전히 데이터 청크(322)의 원본 청크 식별자를 기초로 신뢰할만하게 위치가 찾아질 수 있다. 도 9에 도시된 바와 같이, 리디렉션 테이블(900)은 복수의 항목(902), 가령, 제 1 항목(902a) 및 제 2 항목(902b)을 포함한다. 임의의 개수의 항목(902), 가령, 수백 개, 수천 개, 및 이보다 훨씬 더 많은 개수의 항목(902)이 리디렉션 테이블(900)에 포함될 수 있다. 각각의 항목(902)은 로컬 식별자(904) 및 변경된 청크 오프셋 값(906)을 포함한다. 예를 들어, 제 1 항목(902a)은 제 1 로컬 식별자(904a) 및 제 1 변경된 청크 오프셋 값(906a)을 포함하고, 제 2 항목(902b)은 제 2 로컬 식별자(904b) 및 제 2 변경된 청크 오프셋 값(906b)을 포함한다.

로컬 식별자(904)는, 청크 컨테이너(304)에 본래 저장될 때 데이터 청크(322)로 할당되는 고유 로컬 식별자이다. 변경된 청크 오프셋 값(906)은 대응하는 로컬 식별자(904)를 갖는 이동된 데이터 청크(322)에 대한 새로운 청크 오프셋 값이다. 따라서 리디렉션 테이블(900)은 데이터 청크에 대한 로컬리티 지시자를 이용해 액세스되어, 상기 데이터 청크에 대한 변경된 청크 오프셋 값을 결정할 수 있다.

예를 들어, 도 9의 로컬 식별자(904a)는 데이터 청크(614b)로 할당된 로컬 식별자일 수 있다. 데이터 청크(614b)로 할당된 로컬 식별자를 이용해 리디렉션 테이블(900)의 항목(902a)이 액세스되어, 청크 컨테이너(304) 내 데이터 청크(614b)에 대한 새로운 위치를 가리키는 변경된 청크 오프셋 값(906a)을 결정할 수 있다.

리디렉션 테이블(900)은 임의의 크기를 가질 수 있다. 예를 들어, 하나의 실시예에서, 리디렉션 테이블(900)의 크기는 (지정된 최대 데이터 청크 개수 - 압축을 위해 삭제되는 지정된 최소 데이터 청크 개수) × (리디렉션 테이블 항목의 크기)이다. 일부 경우, 데이터 청크의 재배치가 드물 수 있다. 하나의 실시예에서, 데이터 청크에 대한 변경된 청크 오프셋 값을 결정한 후, 스트림 맵에서의 데이터 청크로의 임의의 포인터가 스트림 맵 내에서 변경된 청크 오프셋 값으로 변형될 수 있고, 항목(902)은 리디렉션 테이블(900)에서 삭제될 수 있다. 일부 상황에서, 이러한 방식으로 시간이 흐름에 따라 리디렉션 테이블(900)에서 항목(902)이 비워질 수 있다.

리디렉션 테이블의 항목이 다양한 방식으로 추가될 수 있다. 예를 들면, 도 10은 예시적 실시예에 따라 데이터 스트림을 저장하기 위한 흐름도(1000)를 도시한다. 흐름도(1000)와 관련된 설명을 바탕으로 추가 구조 및 동작 실시예가 해당 분야의 통상의 기술자에게 자명할 것이다. 흐름도(1000)에 대해 다음과 같이 기재된다.

흐름도(1000)는 단계(1002)로 시작한다. 단계(1002)에서, 청크 컨테이너의 내용(content)이 수정된다. 예를 들어, 하나의 실시예에서, 도 8의 청크 컨테이너(304) 내 하나 이상의 데이터 청크(322)가 이동될 수 있다. 이러한 데이터 청크(322)는 유지관리 작업(maintenance task)(가령, 도 1의 유지관리 모듈(106))에 의해, 가령, 단편화제거 프로세스, 가비지 콜렉션 후의 압축 프로세스, 또는 그 밖의 다른 프로세스에 의해, 이동될 수 있다.

단계(1004)에서, 단계(1002)로 인해 청크 컨테이너의 하나 이상의 데이터 청크에 대한 변경된 청크 오프셋 값을 나타내는 하나 이상의 항목이 리디렉션 테이블에 추가된다. 예를 들어, 하나 이상의 이동된 데이터 청크(322)에 대응하는 하나 이상의 항목(902)이 리디렉션 테이블(900)에 추가될 수 있다. 예를 들어, 각각의 이동된 데이터 청크(322)에 대해, 이동된 데이터 청크(322)의 로컬 식별자 값을 로컬 식별자(904)라고 나타내고, 이동된 데이터 청크(322)의 새로운 오프셋 값을 변경된 청크 오프셋 값(906)이라고 나타내는 항목(902)이 생성될 수 있다.

단계(1006)에서, 단계(1002)로 인해 청크 컨테이너 헤더 내 세대 표시(generation indication)가 증가한다. 예를 들어, 하나의 실시예에서, 청크 컨테이너 세대 표시(804)가 초기 값 0을 가질 수 있고, 데이터 청크(322)가 청크 컨테이너(304)에서 이동될 때마다 청크 컨테이너 세대 표시(804)가 증분되어, 더 높은 세대 값을 나타낼 수 있다. 또 다른 실시예에서, 청크 컨테이너 세대 표시(804)가 그 밖의 다른 방식으로 수정될 수 있다.

따라서, 참조 스트림 맵(310)에 저장된 데이터 청크 식별자를 이용해 도 8의 청크 컨테이너(304)의 데이터 청크(322)가 조사(look up)될 때, 청크 컨테이너(304)의 현재 세대가 데이터 청크 식별자의 청크 컨테이너 세대 값과 동일한지 여부를 알아보기 위해, 청크 컨테이너(304)의 청크 컨테이너 세대 표시(804)가 체크될 수 있다. 동일한 경우, 데이터 청크(322)는 데이터 청크 식별자 내 청크 오프셋 값이 나타내는 오프셋에 위치할 수 있다. 동일하지 않은 경우, 청크 컨테이너(304) 내 데이터 청크(322)의 변경된 오프셋 값을 결정하기 위해 리디렉션 테이블(900)이 읽힌다.

예를 들어, 하나의 예시적 실시예에 따라 도 11은 데이터 스트림 요청(1110)에 따라 데이터 스트림을 원상회복시키기 위해 스트림 컨테이너(302) 및 청크 컨테이너(304)와 통신하는 원상회복 모듈(rehydration module)(1130)의 블록도를 도시한다. 도 11에 도시된 바와 같이, 원상회복 모듈(1130)은 데이터 스트림 어셈블러(data stream assembler)(1102), 세대 체커(generation checker)(1106), 및 데이터 청크 리트리버(data chunk retriever)(1108)를 포함한다. 도 11은 이하와 같이 설명된다.

도 11에서, 데이터 스트림 어셈블러(1102)는 스트림 맵, 가령, 스트림 컨테이너(302)에 저장되고 원상회복될 데이터 스트림에 대응하는 스트림 맵(1104)을 나타내는 데이터 스트림 요청(1110)을 수신한다. 상기 데이터 스트림 어셈블러(1102)는 스트림 맵(1104)을 프로세싱하며, 상기 스트림 맵(1104)에 의해 참조되는 데이터 청크 각각에 대한 데이터 청크 요청(112)을 생성한다.

하나의 실시예에서, 데이터 스트림 어셈블러(1102)에 의해 생성된 데이터 청크 요청(1112)은 요청된 데이터 청크(322)를 식별하기 위해 데이터 청크 식별자를 포함할 수 있다. 요청된 데이터 청크를 불러오기 위해, 위치가 파악된 청크 컨테이너가 다음과 같이 액세스될 수 있다.

도 11에 도시된 것처럼, 세대 체커(1106)는 요청된 데이터 청크에 대한 데이터 청크 요청(1112)을 수신한다. 세대 체커(1106)는 (앞서 요청된 데이터 청크(322)의 청크 컨테이너 식별자와 일치하는 청크 컨테이너 식별자(802)를 갖는 것으로 식별된) 청크 컨테이너(304)를 액세스한다. 세대 체커(1106)는 청크 컨테이너(304)에 대한 청크 컨테이너 세대 표시(804)를 요청된 데이터 청크(322)에 대한 청크 컨테이너 세대 값에 비교하고, 세대 일치 표시(generation match indication)(1114)를 출력하도록 구성된다. 이들의 값이 일치하지 않은 경우(가령, 청크 컨테이너 세대 표시(804)가 요청된 데이터 청크(322)에 대한 청크 컨테이너 세대 값의 값보다 큰 경우), 세대 일치 표시(1114)는 일치가 발견되지 않았음을 나타내고, 단계(1806)로 진행된다. 이들의 값이 일치한 경우, 세대 일치 표시(1114)가 일치가 발견됐다고 나타내고, 요청된 데이터 청크를 불러오기 위한 표준 I/O 경로(또는 그 밖의 다른 경로)가 뒤 따를 수 있다.

도 11에 도시된 바와 같이, 데이터 청크 리트리버(1108)는 세대 일치 표시(1114) 및 데이터 청크 요청(1112)을 수신한다. 세대 일치 표시(1114)가 일치가 발견되지 않았다고 나타내는 경우, 데이터 청크 리트리버(1108)는 요청된 데이터 청크(322)의 로컬 식별자와 일치하는 로컬 식별자(904)를 갖는 항목(902) 내 변경된 청크 오프셋 값(906)(도 9)에 대해 리디렉션 테이블(900)을 액세스한다. 도 11에 도시된 바와 같이, 데이터 청크 리트리버(1108)는 제 1 청크 오프셋 값과 상이한 제 2 청크 오프셋 값(1116)을 수신한다.

도 11에 도시된 바와 같이, 데이터 청크 리트리버(1108)는 제 2 청크 오프셋 값(1116)에 위치하는 데이터 청크(322z)에 대해 청크 컨테이너(304)를 액세스한다. 데이터 청크(322z)는 청크 컨테이너(304) 내에서 제 2 청크 오프셋 값(1116)까지 이동된 적 있는 요청된 데이터 청크(322)이다.

도 11에 도시된 바와 같이, 데이터 청크 리트리버(1108)는 데이터 청크(1118), 본 예시의 경우, 데이터 청크(322z)를 출력한다. 데이터 청크(1118)는 데이터 스트림 어셈블러(1102)에 의해 수신된다. 이러한 방식으로, 데이터 스트림 어셈블러(1102)는 데이터 청크 리트리버(1108)로부터 스트림 맵(104)에 의해 참조되고, 대응하는 청크 오프셋 값에 따라 청크 컨테이너(304)로부터 직접 불러오거나, 리디렉션 테이블(900)에 의해 리디렉트될 때 청크 컨테이너(304)로부터 불러오는 모든 데이터 청크(322)를 수신한다. 도 11에 도시된 것처럼, 데이터 스트림 어셈블러(1102)는 데이터 스트림 요청(1110)에서 나타난 요청된 데이터 스트림의 원상회복된 형태인 데이터 스트림(1120)을 생성한다. 본원에 기재된 바와 같이, 데이터 스트림 어셈블러(1102)는 모든 수신된 데이터 청크(322)를 다 함께 어셈블하여, 데이터 스트림(1120)을 형성한다.

데이터 스트림의 재분석 포인트(reparse point)(가령, 도 6의 스트림 링크(608a 또는 608b))에 위치하는 스트림 맵 참조 식별자가 데이터 청크 식별자와 동일한 구조를 가질 수 있다. 앞서 기재된 바와 같이, 스트림 맵(310)은 최종 사용자 파일 데이터 대신 스트림 맵 메타데이터를 포함하는 데이터 청크(322)의 형태를 가질 수 있다. 따라서 스트림 맵(310)을 주소지정(addressing)하기 위한 절차는 데이터 청크(322)를 주소지정하는 것과 동일할 수 있다 - 두 기법 모두 데이터 청크 식별자 구조를 이용할 수 있다. 스트림 맵(310)의 데이터 청크 식별자를 (실제 데이터 스트림/파일 객체에 첨부된) 파일 재분석 포인트(file reparse point)에 위치시킴으로써, 최적화된 데이터 스트림은 스트림 맵(310)을 참조한다. 상기 스트림 맵 식별자는 스트림 컨테이너(302) 내부에서 스트림 맵(310) 데이터 청크의 위치를 (직접적으로, 또는 리디렉션 테이블을 통해) 찾기 위해 사용될 수 있는 [컨테이너 식별자, 로컬 식별자, 세대 값, 오프셋 값] 정보를 포함한다. 따라서 하나의 실시예에서, 스트림 컨테이너(302)의 포맷과 레이아웃이 청크 컨테이너(304)의 것과 본질적으로 동일할 수 있다.

D. 예시적 데이터 최적화 백업 실시예

청크 저장소에서 복수의 데이터 스트림들 간에 데이터가 공유되기 때문에 데이터 최적화 기법을 활용하는 데이터 시스템의 백업 및 복원이 어렵다. 따라서 데이터는 파일 명칭공간(file namespace)과 분리되어 있다. 그러나 데이터 백업 및 복원 능력은 유용하다. 일반적으로 실체(entity)는 효과적인 데이터 백업 통합 없이는 데이터 최적화 해결책을 활용하도록 변경 가능하지 않을 것이다.

실시예에서, 데이터 최적화 환경을 위한 다양한 백업 기법이 제공되는데, 가령, 최적화된 백업, 역-최적화된 백업(un-optimized backup), 아이템-레벨 최적화된 백업, 및 하이브리드 백업 기법이 있다. 덧붙여, 실시예들에서, 서로 다른 백업 기법들 중에서 선택하기 위해 휴리스틱스(heuristics)가 사용될 수 있다. 예를 들어, 휴리스틱스는 최적화된 백업과 역-최적화된 백업 중에서 선택하기 위해 사용될 수 있다. 실시예는 데이터가 자신의 최적화된 형태(가령, 중복제거된 형태)로 백업될 수 있도록 하는 최적화된 백업 기법에 의한 데이터 최적화 시스템을 제공한다. 실시예는 데이터 백업이 백업 매체 공간(backup media space)을 덜 사용할 수 있도록 하고, 해마다 성장하는 데이터를 고려할 때 상당한 백업 시간 윈도(backup time window)를 감소시키도록 사용될 수 있다. 덧붙여, 실시예는 백업으로부터의 더 빠른 데이터 복원(가령, 더 짧아진 복구 목표 시간(RT0: Recovery Time Objective)을 가능하게 할 수 있다.

실시예에서, 데이터 최적화 시스템에서의 백업은 다양한 방식으로 수행될 수 있다. 예를 들어, 도 12는 예시적 실시예에 따라, 데이터 최적화 시스템에서의 데이터의 백업을 수행하기 위한 흐름도(1200)를 도시한다. 하나의 실시예에서, 흐름도(1200)는 도 1의 청크 저장 인터페이스(116)에 의해 수행될 수 있다. 흐름도(1200)는 설명을 목적으로 도 13과 관련하여 기재된다. 도 13은 하나의 예시적 실시예에 따르는 데이터 백업 시스템(1300)의 블록도를 도시한다. 흐름도(1200)는 데이터 백업 시스템(1300)에 의해 수행될 수 있다. 도 13에 도시된 바와 같이, 데이터 백업 시스템(1300)은 데이터 백업 모듈(1302), 백업 저장장치(1304), 및 스트림 컨테이너(302)와 하나 이상의 청크 컨테이너(304)(가령, 청크 컨테이너(304a 및 304b))를 포함하는 청크 저장소(1334)를 포함한다. 흐름도(1200)와 관련된 설명을 토대로 추가적인 구조 및 동작 실시예가 해당 분야의 통상의 기술자에게 자명할 것이다. 흐름도(1200)가 이하에서 설명된다.

흐름도(1200)의 단계(1202)에서, 청크 저장소에 저장되는 복수의 최적화된 데이터 스트림이 백업을 위해 식별된다. 예를 들어, 도 13을 참조하면, 데이터 백업 모듈(1302)이 청크 저장소(1334)에 저장된 하나 이상의 최적화된 데이터 스트림을 백업 저장장치(1304)에 저장하기 위한 요청(1318)을 수신할 수 있다. 요청(1318)은 최적화된 데이터 스트림에 대응하는 최적화된 스트림 구조(가령, 파일)에 대한 대응하는 파일 명칭에 의해 하나 이상의 최적화된 데이터 스트림을 식별할 수 있다. 각각의 최적화된 스트림 구조는, 앞서 기재된 바와 같이, 최적화된 데이터 스트림을 청크 컨테이너(304)들 중 하나 이상에 저장된 데이터 청크(322)로 매핑하는 것을 기술하는 메타데이터를 포함하는 스트림 컨테이너(302) 내 스트림 맵 청크(1316)의 스트림 맵 청크를 참조한다.

단계(1204)에서,청크 저장소의 적어도 일부분이 백업 저장장치에 저장되어, 복수의 최적화된 데이터 스트림을 백업할 수 있다. 요청(1318)에 응답하여, 요청(1318)에서 식별된 최적화된 데이터 스트림이 백업 저장장치(1304)에 저장되도록, 데이터 백업 모듈(1302)은 청크 저장소(1334)의 적어도 일부분을 백업 저장장치(1304)에 저장할 수 있다. 데이터 백업 모듈(1302)은 다양한 방식으로 청크 저장소(1334)의 일부분을 백업 저장장치(1304)에 저장함으로써 최적화된 데이터 스트림을 저장할 수 있다. 예를 들어, 하나의 실시예에서, 각각의 최적화된 데이터 스트림에 대해, 데이터 백업 모듈(1302)은 스트림 맵 청크(1316) 중 대응하는 스트림 맵 청크와 상기 스트림 맵 청크에 의해 참조되는 데이터 청크(322)를 결정할 수 있고, 결정된 스트림 맵 청크 및 데이터 청크를 백업 저장장치(1304)에 저장할 수 있다. 또 다른 실시예에서, 데이터 백업 모듈(1302)은 최적화된 데이터 스트림을 백업하기 위해 최적화된 데이터 스트림의 결정된 청크를 포함하는 청크 저장소(1334)의 더 큰 일부분을 백업 저장장치(1304)에 저장할 수 있다.

따라서 데이터 백업 모듈(1302)은 단계(1204)에 따라 다양한 방식으로 최적화된 데이터 스트림을 저장하도록 구성될 수 있다. 예를 들어, 도 13에 도시된 바와 같이, 데이터 백업 모듈(1302)은 최적화된 파일 백업 모듈(optimized file backup module)(1306), 원상회복 백업 모듈(rehydrating backup module)(1308), 아이템 레벨 백업 모듈(item level backup module)(1310), 및 데이터 청크 식별자 백업 모듈(data chunk identifier backup module)(1312)을 포함할 수 있다. 실시예에서, 데이터 백업 모듈(1302)은 모듈(1306, 1308, 1310, 및 1312) 중 임의의 하나 이상을 포함할 수 있다. 모듈(1306, 1308, 1310, 및 1312)은 최적화된 데이터 스트림이 다양한 방식으로 백업 저장장치(1304)에 저장되는 것을 가능하게 한다. 모듈(1306, 1308, 1310, 및 1312)은 다음과 같이 기재된다.

하나의 실시예에서, 최적화된 백업("최적화된 데이터 스트림 백업"이라고도 일컬어짐)이 최적화된 데이터 스트림을 최적화된 형태로 백업하도록 수행될 수 있다. 예를 들어, 백업 저장장치(1304)에 최적화된 형태로 최적화된 데이터 스트림을 저장함으로써, 최적화된 파일 백업 모듈(1306)은 최적화된 백업을 수행하도록 구성될 수 있다. 최적화된 백업에 따라, 최적화된 데이터 스트림을 백업하기 위해 청크 저장소(1334)의 하나 이상의 전체 청크 컨테이너가 저장될 수 있다. 예를 들어, 하나의 실시예에서, 최적화된 파일 백업 모듈(1306)이 도 14에 나타난 흐름도를 수행할 수 있다. 흐름도(1400)와 최적화된 파일 백업 모듈(1306)이 이하에서 기재된다.

단계(1402)에서, 청크 저장소는 그 전체가 백업 저장장치에 저장된다. 하나의 실시예에서, 최적화된 파일 백업 모듈(1306)이 청크 저장소(1334) 전체를 백업 저장장치(1304)에 저장하여, 요청(1318)에서 나타난 최적화된 데이터 스트림이 백업되도록 할 수 있다. 대안적으로, 최적화된 파일 백업 모듈(1306)은 요청 받은 최적화된 데이터 스트림의 전체를 포함하는 청크 저장소의 하나 이상의 전체 청크 컨테이너(가령, 스트림 컨테이너(302)와, 청크 컨테이너(304) 중 하나 이상)를 저장하여, 최적화된 데이터 스트림이 백업되도록 할 수 있다. 백업될 청크 컨테이너는 최적화된 데이터 스트림의 최적화된 스트림 구조에 의해 참조되는 청크에 대한 청크 식별자의 청크 컨테이너 식별자에 의해 식별될 수 있다. 저장 동작(1320)에 따라, 상기 청크 컨테이너/전체 청크 저장소는 최적화된 파일 백업 모듈(1306)에 의해 백업 저장장치(1304)에 저장될 수 있다.

단계(1404)에서, 복수의 스트림 메타데이터 스터브(stream metadata stub)가 청크 저장소 내 대응하는 데이터로 링크된 복수의 최적화된 데이터 스트림에 대해 백업 저장장치에 저장된다. 상기 스트림 메타데이터 스터브는 최적화된 파일 백업 모듈(1306)에 의해 그 밖의 다른 저장장치(가령, 주 저장장치), 가령, 백업 저장장치(1304)가 아닌 저장장치로부터 불러와 질 수 있고, 최적화된 데이터 스트림에 대해 청크 저장소(1334) 내 데이터 저장소로 링크되는 파일이다. 예를 들어, 각각의 스트림 메타데이터 스터브는 스트림 맵 청크(1316)의 각자의 대응하는 스트림 맵 청크로의 참조자를 포함할 수 있고, 스트림 맵 청크에 의해 참조되는 임의의 데이터 청크(322)를 조합함으로써 원상회복 프로세스 동안 대응하는 데이터 스트림을 비-최적화된 형태로 재-빌드/재-어셈블(rebuild/reassemble)하도록 사용될 수 있다. 하나의 실시예에서, 요청(1318)에서 식별된 최적화된 데이터 스트림에 대응하는 스트림 메타데이터 스터브는 최적화된 파일 백업 모듈(1306)에 의해 저장 동작(1320)을 이용해 백업 저장장치(1304)에 저장된다. 스트림 메타데이터 스터브는 최적화된 파일 백업 모듈(1306)에 의해 이들의 "디스크 상(on-disk)" 포맷으로 백업 저장장치(1304)에 저장될 수 있다.

따라서, 백업 저장장치(!304) 상의 최적화된 데이터 스트림에 대한 파일 상태를 제공하는 "볼륨 이미지(volume image)"가 청크 저장소(1334)를 반영한다. 백업 저장장치(1304) 내 저장된 청크 컨테이너와 저장된 스트림 메타데이터 스터브의 조합이 최적화된(재-어셈블되지 않은) 형태로 된, 최적화된 데이터 스트림의 완전한 저장을 제공한다. 추가적인 메타데이터가 저장될 필요가 없다.

(가령, 흐름도(1400) 및 최적화된 파일 백업 모듈(1306)에 따른) 최적화된 백업이 최적화된 데이터 스트림을 백업하기 위해 임의의 상황에서 수행될 수 있다. 대부분의 백업된 볼륨(백업 저장장치 내 액세스 가능한 저장 영역)이 범위 내에 있는 경우 최적화된 백업이 수행되는 것이 바람직할 수 있다. 요청(1318)에서 식별된 최적화된 데이터 스트림에 의해 참조되지 않고 다른 최적화된 데이터 스트림에 의해 최적화된 데이터 청크가 청크 컨테이너에 포함될 수 있기 때문에 전체 청크 컨테이너가 저장될 때 일부 "낭비(waste)"가 가능하다. 따라서 결국 더 많은 데이터가 필요한 것보다 더 많이 백업될 수 있다. 백업된 볼륨 중 비교적 작은 부분이 범위 내에 있는 경우(가령, 백업된 청크 컨테이너에 포함되는 적은 수의 데이터 청크가 요청(1318)에서 식별된 최적화된 데이터 스트림과 연관된 경우), 전체 청크 컨테이너를 저장하지 않는 다른 백업 기법(가령, 이하에서 설명될 역-최적화된 백업 기법)이 바람직할 수 있다.

최적화된 백업에 따라 백업된 최적화된 데이터 스트림의 복원은, 복원이 최적화된 복원이도록 청크 저장소 컨테이너 파일 및 스트림 메타데이터 스터브를 복원하는 것을 포함한다. 이러한 최적화된 저장소(optimized store)는 크기가 비교적 더 작고, 따라서 비교적 더 빠르며, I/O 자원이 덜 소비된다. 최적화된 백업으로부터 최적화된 데이터 스트림을 선택적으로 복원하기 위한 기법은 다음의 서브섹션에서 추가로 기재된다.

따라서 최적화된 백업을 위한 실시예는 다양한 이점을 제공할 수 있다. 예를 들어, 최적화된 백업은 더 작은 저장장치 크기 백업을 도출할 수 있으며, 이는 (가령, 백업 저장장치(1304) 내) 백업 매체 공간을 절약한다. 이는 디스크-기반 백업 솔루션의 경우 유용할 수 있다. 일부 경우, 백업 저장장치 내 저장 공간 절약은 주 저장장치 내 절약보다 더 유의미하고 비용 효율적일 수 있다. 최적화된 백업에 의해 백업을 수행하기 위해 사용되는 시간이 더 빨라질 수 있다. 백업 실행 시간은 감소될 수 있고, 이는 해마다 증가하는 저장 데이터의 양을 고려할 때 유의미한 것이다. 데이터 양의 성장으로 인해, 백업 실행 시간이 데이터의 양에 맞춰 증가하기 때문에 저장장치 사용자는 빈번한(가령, 매일) 백업을 수행하는 것을 고심할 수 있다. 최적화된 백업 기법이 백업 실행 시간을 감소시키는 데 도움이 될 수 있다. 추가로, 최적화된 백업은 TO를 단축시킬 수 있어서, 더 빠른 복원을 야기할 수 있다. RTO는 백업/복원 솔루션의 중요한 척도이다.

또 다른 실시예에서, 비-최적화된 백업(non-optimized backup)("역-최적화된 데이터 스트림 백업(un-optimized data stream backup)"이라고도 지칭됨)이 수행되어 최적화된 데이터 스트림을 비-최적화된(non-optimized) 또는 역-최적화된(un-optimized) 형태로 저장하도록 수행될 수 있다. 비-최적화된 백업에 따르면, 백업 저장장치를 위해 설계된 최적화된 데이터 스트림은, 저장되기 전에 원상회복될 수 있다. 예를 들어, 하나의 실시예에서, 원상회복 백업 모듈(1308)은 최적화된 데이터 스트림을 원상회복하고, 원상회복된 데이터 스트림을 백업 저장장치(1304)에 저장함으로써, 비-최적화된 백업을 수행하도록 구성될 수 있다. 하나의 실시예에서 원상회복 백업 모듈(1308)은 도 15에 도시된 흐름도(1500)를 수행할 수 있다. 흐름도(1500) 및 원상회복 백업 모듈(1308)이 이해에서 설명된다.

흐름도(1500)의 단계(1502)에서, 각각의 최적화된 데이터 스트림이, 대응하는 최적화된 스트림 메타데이터에 의해 참조되는 임의의 데이터 청크를 포함하는 대응하는 역-최적화된 데이터 스트림으로 원상회복된다. 원상회복 백업 모듈(1308)은 최적화된 데이터 스트림을 어떠한 방식으로도, 가령, 앞서 원상회복 모듈(702)(도 7)에 대해 기재된 바와 같은 방식으로 원상회복할 수 있다. 예를 들어, 도 13을 참조하면, 원상회복 백업 모듈(1308)이 요청(1318)에서 식별된 최적화된 데이터 스트림에 대응하는 스트림 맵 청크의 형태로, 또는 그 밖의 다른 형태(가령, 전역 테이블, 데이터베이스, 등등)로, 최적화된 스트림 메타데이터에 대해 스트림 컨테이너(302)를 액세스할 수 있다. 도 13에 도시된 바와 같이, 원상회복 백업 모듈(1308)은 원하는 스트림 맵 청크에 대해 하나 이상의 스트림 컨테이너 액세스(1322)를 생성할 수 있다. 스트림 컨테이너 액세스(1322)는 대응하는 스트림 맵 식별자에 의한 원하는 스트림 맵 청크를 식별할 수 있다. 스트림 컨테이너 액세스(1322)에 응답하여, 원상회복 백업 모듈(1308)은 스트림 컨테이너(302)로부터 요청(1318)에서 식별된 최적화된 데이터 스트림에 대응하는 스트림 맵 청크(1324)를 수신한다. 대응하는 불러온 스트림 맵 청크의 스트림 맵에 따라, 원상회복 백업 모듈(1308)은 각각의 최적화된 데이터 스트림을 재생성 또는 "원상회복"시킬 수 있다. 도 13의 예에서, 스트림 맵 각각은 대응하는 최적화된 데이터 스트림에 포함된 데이터 청크 각각으로의 포인터(가령, 도 4의 데이터 청크 식별자(404))를 포함하고, 이는 청크 컨테이너(304a 및/또는 304b)에 포함될 수 있다. 원상회복 백업 모듈(1308)은 포인터를 이용하여 참조된 데이터 청크(322) 각각을 불러올 수 있다. 예를 들어, 원상회복 백업 모듈(1308)은 청크 컨테이너 액세스(1326 및/또는 1330) 중 하나 이상을 생성하여 각각 제 1 및/또는 제 2 청크 컨테이너(304a 및 304b)로부터 데이터 청크(322)를 획득할 수 있다. 청크 컨테이너 액세스(1326 및/또는 1330)에 응답하여, 원상회복 백업 모듈(1308)은 요청(1318)에서 식별된 최적화된 데이터 스트림에 대응하는 데이터 청크(1328 및/또는 1332)를 청크 컨테이너(302a 및 302b)로부터 수신한다.

원상회복 백업 모듈(1308)은 불러온 스트림 맵(가령, 도 3의 스트림 맵(310))에 포함된 데이터 스트림 오프셋(402)을 이용하여 불러온 데이터 청크를 적절한 순서로 배열하여 각각의 데이터 스트림을 역-최적화된 형태로(가령, 역-최적화된 데이터 스트림으로서) 재-생성할 수 있다.

단계(1504)에서, 역-최적화된 데이터 스트림 각각은 백업 저장장치에 저장된다. 예를 들어, 도 13에 도시된 바와 같이, 저장 동작(1304)에 따라 역-최적화된 데이터 스트림은 원상회복 백업 모듈(1308)에 의해 백업 저장장치(1304)에 저장될 수 있다. 따라서 데이터 스트림이 백업 저장장치(1304)로부터 복원되는 것이 희망될 때, 백업 저장장치(1304)에 저장된 역-최적화된 데이터 스트림이 불러와 질 수 있다.

따라서 (가령, 흐름도(1500) 및 원상회복 백업 모듈(1308)에 따르는) 역-최적화된 백업은 어떠한 상황에서도 최적화된 데이터 스트림을 백업하기 위해 수행될 수 있다. 최적화된 데이터 스트림의 데이터 청크가 청크 저장소(1334)의 저장 공간의 비교적 더 작은 부분을 채우는 경우 역-최적화된 백업이 수행되는 것이 바람직할 수 있다. 따라서 요청(1318)에서 식별된 최적화된 데이터 스트림과 무관한 많은 데이터 청크를 저장하는 것을 포함할 수 있는 전체 청크 컨테이너를 백업 저장장치(1304)에 저장하는 것 대신, 특정 최적화된 데이터 스트림이 원상회복되고 백업 저장장치(1304)에 저장될 수 있다. 따라서 백업 매체는 데이터 스트림을 이들의 역-최적화된, 원본 형태로 저장하고, 무관한 데이터 청크들을 저장하는 것을 피함으로써 백업 저장 공간은 절약될 수 있다.

역-최적화된 백업에 대한 실시예가 다양한 이점을 제공할 수 있다. 예를 들어, 더 선택적인 백업을 이용하는(그리고 선택적 복원을 가능하게 하는) 역-최적화된 백업이 비교적 구현되기 용이하다. 데이터 스트림이 역-최적화된 형태로 백업되기 때문에, 백업된 데이터 스트림의 복원은 저장 시스템에 의해 사용된 데이터-최적화 기법에 따라 달라지지 않는다. 따라서 데이터 스트림은 어디에서도 복원될 수 있고, 설치 및 동작되는 데이터-최적화 솔루션에 독립적으로 액세스될 수 있다.

원상회복 프로세스 때문에, 역-최적화된 백업이 비교적 느릴 수 있고, 데이터 백업 모듈(1302)에 성능 영향을 미칠 수 있다. 최적화된 데이터의 원상회복은, 수행되는 최적화된 데이터의 압축해제(decompression), 그리고 아마도 데이터 단편화로 인해, 정규 데이터 읽기보다 느리다. 덧붙여, 데이터 스트림은 역-최적화된 형태로 백업되기 때문에, 중복제거의 이점이 제공되지 않기 때문에 백업된 총 데이터 양이 클 수 있다. (백업 데이터는 최적화되지 않고 볼륨이 최적화되기 때문에) 총 데이터 양은 백업되는 볼륨보다 큰 가능성이 있다. 일부 경우, 백업 저장장치 크기의 한계 때문에 모든 데이터를 백업하는 것이 가능하지 않을 수 있다. 따라서 특히 백업 상황에서 사용되기 위해 역-최적화된 백업이 선택될 수 있다. 다른 백업 기법에 대해 역-최적화된 백업을 선택하는 예시가 이하에서 더 설명된다.

또 다른 실시예에서, 최적화된 데이터 스트림을 아이템 레벨 최적화된 형태로 저장하기 위해 아이템 레벨 백업이 수행될 수 있다. 아이템 레벨 백업에 따르면, 백업 저장장치를 위해 설계된 최적화된 데이터 스트림이 최적화된 형태의 저장을 위해 준비된다. 예를 들어, 특정 최적화된 데이터 스트림에 대하여, 최적화된 데이터 스트림의 스트림 맵 청크에 의해 참조되는 데이터 청크가 결정된다. 참조된 데이터 청크들 중 백업 저장장치에 이미 저장된 임의의 데이터 청크는 청크 저장소로부터 불러와 지지 않는다. 참조되는 데이터 청크들 중 백업 저장장치에 이미 저장된 것이 아닌 데이터 청크가 청크 저장소로부터 불러와 지고, 백업 저장장치에 저장된다. 예를 들어, 하나의 실시예에서, 아이템 레벨 백업 모듈(1310)이 백업 저장장치(1304)에 스트림 맵 청크 및 백업 저장장치(1304)에 이미 저장된 것이 아니며 참조된 데이터 청크를 저장함으로써 아이템 레벨 백업을 수행하도록 구성될 수 있다. 예를 들어, 하나의 실시예에서, 아이템 레벨 백업 모듈(1310)은 도 16에 도시된 흐름도(1600)를 수행할 수 있다. 흐름도(1600)는 요청(1318)에서 식별된 최적화된 데이터 스트림 각각에 대해 수행될 수 있다. 흐름도(1600) 및 아이템 레벨 백업 모듈(1310)이 이하에서 설명된다.

흐름도(1600)의 단계(1602)에서, 백업을 위해 식별된 제 1 최적화된 데이터 스트림이 수신된다. 예를 들어, 요청(1318)은 최적화된 데이터 스트림을 식별할 수 있다. 최적화된 데이터 스트림에 대해, 아이템 레벨 백업 모듈(1310)은 최적화된 스트림 메타데이터(가령, 스트림 컨테이너(302)로부터 스트림 맵 청크(1324))를 불러오고 청크 컨테이너(304)로부터 최적화된 스트림 메타데이터에 의해 참조되는 임의의 데이터 청크(322)를 불러올 수 있다. 예를 들어, 아이템 레벨 백업 모듈(1310)은 스트림 컨테이너(302)로의 스트림 컨테이너 액세스(1322)를 생성해 원하는 스트림 맵 청크를 스트림 맵 청크(1324)로서 불러오며, 청크 컨테이너 액세스(1326 및/또는 1330) 중 하나 이상을 생성해 제 1 및/또는 제 2 청크 컨테이너(304a 및 304b)로부터 참조된 데이터 청크(322)를 데이터 청크(1328 및/또는 1332)로서 획득할 수 있다.

단계(1604)에서, 제 1 최적화된 데이터 스트림의 최적화된 스트림 메타데이터에 의해 참조되고 백업 저장장치에 이미 저장된 것이 아닌 하나 이상의 데이터 청크가 결정된다. 하나의 실시예에서, 아이템 레벨 백업 모듈(1310)이 스트림 맵의 메타데이터에 의해 참조되는 데이터 청크를 백업 저장장치(1304)에 이미 저장된 임의의 데이터 청크에 비교하여, 참조된 데이터 청크들 중 임의의 것이 백업 저장장치(1304)에 이미 저장되어 있는지 여부를 결정할 수 있다. 아이템 레벨 백업 모듈(1310)은 임의의 방식으로 비교를 수행할 수 있으며, 예를 들어, (가령, 해시 인덱스(hash index), 등등을 이용해) 참조된 데이터 청크의 해시(hash)를 백업 저장장치(1304)에 저장된 데이터 청크의 해시에 비교함으로써, 참조된 데이터 청크에 대한 데이터 청크 식별자를 백업 저장장치(1304)에 저장된 데이터 청크의 데이터 청크 식별자에 비교할 수 있거나, 그 밖의 다른 기법에 따라 비교를 수행할 수 있다. 아이템 레벨 백업 모듈(1310)은, 예를 들어, 리스트 또는 그 밖의 다른 데이터 구조를 (가령, 메모리 내에) 유지관리함으로써, 백업 저장장치(1304)에 이미 저장된 것이 아니라고 결정되고 참조된 데이터 청크를 계속 파악할 수 있다.

단계(1606)에서, 제 1 최적화된 데이터 스트림의 최적화된 스트림 메타데이터가 백업 저장장치에 저장된다. 예를 들어, 아이템 레벨 백업 모듈(1310)은 최적화된 데이터 스트림에 대해 스트림 컨테이너(302)로부터 불러온 스트림 맵 청크를 (가령, 저장 동작(1320)을 이용해) 백업 저장장치(1304)에 저장할 수 있다.

단계(1608)에서, 결정된 하나 이상의 데이터 청크가 백업 저장장치에 저장된다. 아이템 레벨 백업 모듈(1310)은 최적화된 데이터 스트림에 대해 청크 컨테이너(302a 및/또는 302b)로부터 불러와 지고 단계(1604)에서 백업 저장장치(1304)에 이미 저장된 것이 아니라고 결정된 데이터 청크를 (가령, 저장 동작(1320)을 이용해) 백업 저장장치(1304)에 저장할 수 있다. 따라서 데이터 스트림이 백업 저장장치(1304)로부터 복원될 것이 희망될 때, 최적화된 데이터 스트림에 대해 백업 저장장치(1304)에 저장된 스트림 맵 청크 및 데이터 청크가 백업 저장장치(1304)로부터 불러와 지고 원상회복되어 데이터 스트림을 형성할 수 있다. 하나의 실시예에서, 최적화된 스트림 구조(가령, 흐름도(1400)의 단계(1404)와 관련해 앞서 기재된 스트림 메타데이터 스터브)(도 14)가 백업 저장장치(1304)에 백업될 수 있고, 데이터 스트림을 원상회복시키기 위한 재분석 포인트(reparse point)로서 백업 저장장치(1304)로부터 불러와 질 수 있다.

따라서 (가령, 흐름도(1600) 및 아이템 레벨 백업 모듈(1310)에 따르는) 아이템 레벨 백업이 어떠한 상황에서도 최적화된 데이터 스트림을 백업하기 위해 수행될 수 있다. 아이템 레벨 백업에 따르면, 백업을 최적화된 형태로 유지하면서, 중복제거된 데이터 청크가 백업되는 매 데이터 스트림과 연관된다(가령, 어떠한 원상회복 없이, 매 데이터 청크가 1회 백업된다). 전체 청크 저장소 컨테이너가 백업되는 것은 아니다.

하나의 실시예에서, 백업(및 선택사항으로서 복원) API(application programming interface)가 아이템 레벨 백업 모듈(1310)에 의해 구현될 수 있다. 예를 들어, 청크 저장소(1334)에 저장된 제 1 파일과 제 2 파일을 최적화된 형태로 백업하기 위해 백업 세션이 정의될 수 있다. 이 예시에서, 제 1 파일은 청크 컨테이너(302a)의 데이터 청크(322a 및 322b)와 청크 컨테이너(304b)의 데이터 청크(322d)를 포함하고, 제 2 파일은 청크 컨테이너(302a)의 데이터 청크(322a-322c)와 청크 컨테이너(304b)의 데이터 청크(322d 및 322e)를 포함한다고 가정된다. 백업 API는 제 1 파일을 백업하도록 호출될 수 있다. 이에 응답하여, API가 제 1 파일에 대한 스트림 맵 청크 및 데이터 청크(322a, 322b, 및 322d)를 반환(return)할 것이다. 반환된 스트림 맵 청크 및 데이터 청크(322a, 322b, 및 322d)는 제 1 파일에 대해 백업 저장장치(1304)에 저장된다. 백업 API는 제 2 파일을 백업하도록 순차적으로 호출될 수 있다. 이에 응답하여, API는 제 2 파일에 대한 스트림 맵 청크와 데이터 청크(322c 및 322e)를 반환할 것이다. 이는 API가 (제 1 파일이 백업 저장장치(1304)에 저장되어 있기 때문에) 제 2 파일의 데이터 청크(322a, 322b, 및 322d)가 백업 저장장치(1304)에 이미 저장되어 있다고 결정할 것이기 때문이다. 따라서 반환된 스트림 맵 청크 및 데이터 청크(322c 및 322e)가 제 2 파일에 대해 백업 저장장치(1304)에 저장된다.

아이템 레벨 백업에 따라 백업된 데이터 스트림을 복원하기 위한 복원 모듈이 유사한 API를 이용할 수 있으며, 여기서 최적화된 스트림 메타데이터가 복원 모듈 API가 참조된 데이터 청크를 가리키는 것을 보조한다. 아이템 레벨 백업은 전체 백업 및 선택적 백업 모두에 대한 (크기 별) 최적화된 백업을 가능하게 한다(백업의 입도(granularity)가 데이터 스트림/파일 입도이기 때문). 그러나 아이템 레벨 백업은 비교적 느리고 복잡할 수 있으며, 블록 레벨 백업 기법과 함께 잘 동작하지 않을 수 있다.

또 다른 실시예에서, 데이터 청크 식별자 백업이 최적화된 데이터 스트림을 또 다른 유형의 최적화된 형태로 저장하도록 수행될 수 있다. 데이터 청크 식별자 백업에 따르면, 최적화된 데이터 스트림이 백업되도록 데이터 청크 식별자가 결정된다. 데이터 청크 식별자는 백업 저장장치에 저장되고, 참조된 데이터 청크를 저장하는 청크 컨테이너가 백업 저장장치에 저장된다. 예를 들어, 하나의 실시예에서, 데이터 청크 식별자 백업 모듈(1312)은 백업 저장장치(1304)에 데이터 스트림의 최적화된 스트림 메타데이터에 의해 참조되는 데이터 청크 식별자와, 연관된 데이터 청크 식별자에 의해 식별되는 청크를 저장하는 청크 컨테이너를 저장함으로써 데이터 청크 식별자 백업을 수행하도록 구성될 수 있다. 예를 들어, 하나의 실시예에서, 데이터 청크 식별자 백업 모듈(1312)은 도 17에 도시된 흐름도(1700)를 수행할 수 있다. 흐름도(1700) 및 데이터 청크 식별자 백업 모듈(1312)이 이하에서 설명된다.

흐름도(1700)의 단계(1702)에서, 각각의 최적화된 데이터 스트림의 최적화된 스트림 메타데이터가 분석되어 최적화된 스트림 메타데이터에 의해 참조되는 적어도 하나의 데이터 청크에 대한 대응하는 적어도 하나의 데이터 청크 식별자를 결정할 수 있다. 예를 들어, 하나의 실시예에서, 요청(1318)에서 식별된 각각의 최적화된 데이터 스트림에 대해, 데이터 청크 식별자 백업 모듈(1312)이 스트림 컨테이너(302)로부터 대응하는 최적화된 스트림 메타데이터를 스트림 맵 청크의 형태로 불러올 수 있다. 덧붙여, 데이터 청크 식별자 백업 모듈(1312)은 불러온 스트림 맵 청크의 메타데이터를 분석하여, 청크 컨테이너(304)로부터 스트림 맵 청크의 메타데이터에 의해 참조되는 임의의 데이터 청크(322)에 대해 데이터 청크 식별자(가령, 도 4에 나타난 메타데이터(400)에 포함된 데이터 청크 식별자(404))를 결정할 수 있다. 데이터 청크 식별자는 메타데이터(예, 도 4에 도시된 메타데이터(400)에 포함된 데이터 청크 식별자(404))에 포함된다. 데이터 청크 식별자 백업 모듈(1312)은 리디렉션 테이블(가령, 도 9의 리디렉션 테이블(900))을 참조하여, 하나 이상의 참조된 데이터 청크가 청크 컨테이너(304)에서 이동된 경우 청크 오프셋 값을 업데이트하도록, 하나 이상의 데이터 청크 식별자에 대한 청크 오프셋 값을 매핑할 수 있다.

단계(1704)에서, 각각의 최적화된 데이터 스트림에 대한 최적화된 스트림 구조가 대응하는 적어도 하나의 데이터 청크 식별자와 함께 백업 저장장치에 저장된다. 예를 들어, 데이터 청크 식별자 백업 모듈(1312)이 각각의 최적화된 데이터 스트림의 최적화된 스트림 구조를 단계(1702)에서 결정된 대응하는 데이터 청크 식별자와 함께 백업 저장장치(1304)에 (가령, 저장 동작(1320)을 이용해) 저장할 수 있다. 청크 식별자는 최적화된 스트림 구조물과 연관하여 어떠한 방식으로도 저장될 수 있으며, 가령, 백업 저장장치(1304) 내 대응하는 최적화된 스트림 구조물 외부에 또는 내부에 저장될 수 있다.

단계(1706)에서, 최적화된 데이터 스트림을 포함하는 청크 저장소의 하나 이상의 청크 컨테이너가 백업 저장장치에 저장된다. 하나의 실시예에서, 데이터 청크 식별자 백업 모듈(1312)은 스트림 컨테이너(302)를 백업 저장장치(1304)에 저장하여, 최적화된 데이터 스트림의 스트림 맵 청크가 (가령, 저장 동작(1320)을 이용해) 백업되도록 한다. 덧붙여, 데이터 청크 식별자 백업 모듈(1312)은 청크 컨테이너(304) 중 최적화된 데이터 스트림의 스트림 맵 청크에 의해 참조되는 하나 이상을 저장하여, 참조된 데이터 청크가 (가령, 저장 동작(1320)을 이용해) 백업되도록 할 수 있다. 하나의 실시예에서, 데이터 청크 식별자 백업 모듈(1312)은 청크 저장소(1334) 전체를 백업 저장장치(1304)에 저장하여, 최적화된 데이터 스트림의 모든 청크가 백업되도록 할 수 있다.

따라서 백업 시점에서 "복원 플랜"을 제공하기 위해 각자의 컨테이너 파일 내 모든 데이터 청크(데이터 청크)의 위치도 역시 (데이터 청크 식별자에 의해) 저장된다는 것을 제외하고, 데이터 청크 식별자 백업은 앞서 기재된 최적화된 백업과 유사하다. 데이터 청크 식별자 백업의 이점은 백업 애플리케이션(가령, 데이터 백업 모듈(1302))이 자신의 카탈로그(catalog)에 "복원 플랜"을 저장할 수 있고, 각각의 복원 시나리오, 가령, 선택적 복원을 위해, 그 밖의 다른 어떤 파일(따라서 어떤 백업 매체)가 필요한지를 미리 알 수 있다. 앞서 설명된 역-최적화된 백업과 유사하게, 데이터 청크 식별자 백업은 비교적 느리고 복잡할 수 있고, 데이터 청크 식별자 백업 모듈(1312)에 의해 구현되는 백업 API를 이용할 수 있다. 덧붙여, 데이터 청크 식별자 백업은 청크 저장소의 모듈성(modularity)을 파괴하고 내부 청크 저장소 구현을 노출시킨다.

따라서 최적화된 백업, 역-최적화된 백업, 아이템 레벨 백업, 및 데이터 청크 식별자 백업이 각각, 도 13의 데이터 백업 모듈(1302)에 의해 구현될 수 있는 백업 실시예가 된다. 덧붙여, 데이터 백업 모듈(1302)은 최적화된 백업, 역-최적화된 백업, 아이템 레벨 백업, 및 데이터 청크 식별자 백업 중 하나 이상의 조합인 백업 실시예를 구현할 수 있다.

예를 들어, 하나의 실시예에서, 데이터 백업 모듈(1302)은 최적화된 백업과 역-최적화된 백업의 조합을 구현할 수 있다. 하나의 실시예에서, 전체 볼륨 백업이 수행될 때 최적화된 백업이 수행되도록 선택될 수 있다. 단일 최적화된 데이터 스트림이 백업되는 경우, 역-최적화된 백업이 수행될 수 있다. 하나 그리고 모든 최적화된 데이터 스트림 간 복수의 최적화된 데이터 스트림의 경우, 최적화된 백업 도는 역-최적화된 백업이 선택될 수 있다. 예를 들어, 휴리스틱스를 기초로 최적화된 백업 또는 역-최적화된 백업이 토글(toggle)될 수 있다.

예를 들어, 하나의 실시예에서, 데이터 백업 모듈(1302)은 도 18에 도시된 프로세스에 따라 최적화된 데이터 스트림의 백업을 수행하도록 구성될 수 있다. 도 18은 하나의 실시예에 따라 휴리스틱스를 기초로 백업 기법을 선택하고 실행하기 위한 프로세스를 제공하는 흐름도(1800)를 도시한다. 흐름도(1800)가 이하에서 설명된다.

흐름도(1800)의 단계(1802)에서, 휴리스틱스를 기초로 백업 기법이 선택된다. 예를 들어, 도 13에 도시된 바와 같이, 데이터 백업 모듈(1302)은 선택사항으로서 휴리스틱스 모듈(heuristics module)(1314)을 포함할 수 있다. 휴리스틱스 모듈(1314)은 최적화된 데이터 스트림을 백업하기 위해 사용될 백업 기법을 선택하기 위해 사용되는 휴리스틱스를 결정하도록 구성된다.

단계(1804)에서, 백업 저장장치에 복수의 최적화된 데이터 스트림을 백업하기 위한 백업 기법이 수행된다. 휴리스틱스 모듈(1314)에 의해 결정된 휴리스틱스를 기초로 하여, (가령, 각각 도 14 및 15와 관련하여 앞서 기재된 바와 같이) 최적화된 파일 백업 모듈(1306) 및 원상회복 백업 모듈(1308) 중 하나가 최적화된 데이터 스트림을 백업하기 위해 선택될 수 있다. 예를 들어, 하나의 실시예에서, 휴리스틱스 모듈(1314)은 인에이블 신호(enable signal)를, 최적화된 파일 백업 모듈(1306) 및 원상회복 백업 모듈(1308) 중 최적화된 데이터 스트림을 백업하기 위해 선택된 하나로 제공할 수 있다. 인에이블 신호는 최적화된 파일 백업 모듈(1306) 및 원상회복 백업 모듈(1308) 중 하나가 이들의 대응하는 백업 기법에 따라 최적화된 데이터 스트림을 백업하는 것을 가능하게 한다.

예를 들어, 하나의 실시예에서, 휴리스틱스 모듈(1314)은 "제외 모드(exclude mode)" 및 "포함 모드(include mode)"를 기초로 비교적 단순한 휴리스틱스를 구현할 수 있다. "제외 모드"에 따라, 사용자는 청크 저장소 볼륨을 선택하고 일부 폴더/파일을 백업으로부터 제외시킬 수 있다. 따라서 휴리스틱스 모듈(1314)은 제외 모드에 따라 백업되기 위해 최적화된 데이터 스트림이 선택되었다고 결정할 수 있다. 이러한 경우, 결정된 제외 모드로 인해, 휴리스틱스 모듈(1314)에 의해 최적화된 데이터 스트림 백업 기법이 선택된다. 이는 일반적으로 "제외 모드"가 청크 저장소 볼륨의 대부분을 범위 내에 갖기 때문이다. 따라서 컨테이너 파일이 사용자에 의해 선택된 것들이 아닌 다른 최적화된 데이터 스트림에 의해 참조되는 일부 청크를 포함할 수 있을지라도, 선택된 데이터 스트림(최적화된 형태를 가짐)과 모든 청크 저장소 컨테이너 파일을 백업하는 것이 더 나은 절충안(tradeoff)이다.

"포함 모드"에 따르면, 사용자는 백업을 위해 비교적 적은 폴더/파일을 선택할 수 있다. 따라서 휴리스틱스 모듈(1314)은 포함 모드에 따라 백업되기 위해 최적화된 데이터 스트림이 선택됐다고 결정할 수 있다. 이러한 경우, 결정된 포함 모드로 인해 최적화된 데이터 스트림 백업 기법은 휴리스틱스 모듈(1314)에 의해 선택된다. 이는 일반적으로 "포함 모드"가 청크 저장소 볼륨의 비교적 작은 부분을 범위 내에 갖기 때문이다. 따라서 선택된 파일만 그들의 역-최적화된 형태로 백업하는 것이 더 나은 절충안이다. 이러한 경우, 청크 저장소 컨테이너 파일을 백업할 필요가 없다.

또 다른 실시예에서, 휴리스틱스 모듈(1314)은 비교적 진보된 휴리스틱스를 구현할 수 있다. 백업 기법의 절충안이 백업 범위 내에서 파일의 최적화된 크기와 논리 크기 간의 델타(delta)를 기반으로 할 수 있다. 최적화된 데이터 스트림에 의해 참조만 되고 백업 공간에는 포함되지 않는 청크에 의해 소비되는 청크 저장소 컨테이너 파일 내 저장 공간으로서, 저장 공간 낭비(storage space waste)가 결정될 수 있다. 따라서 휴리스틱스 모듈(1314)은 청크 저장소 볼륨 내 파일 크기를 기초로, 그리고 청크 저장소 통계치(chunk store statistics)를 기초로 낭비된 저장 공간의 양을 결정(가령, 계산)할 수 있다. 하나의 실시예에서, 청크 저장소가 특정 데이터 스트림 그룹에 의해 참조되는 청크의 수를 정확하게 보고하도록 구성되지 않았다면 약간의 가정이 이뤄질 수 있다. 청크 저장소가 지정된 최적화된 데이터 스트림 그룹에 의해 참조되는 청크의 수를 보고할 수 있는 경우, 휴리스틱스 모듈(1314)은 낭비된 저장 공간의 크기를, 모든 청크에 의해 채워지는 공간에서 백업되도록 지정된 최적화된 데이터 스트림에 의해 참조되는 청크에 의해 채워지는 공간을 뺀 것으로서 결정할 수 있다. (가령, 총 저장 공간에 대한) 낭비된 저장 공간의 크기를 기초로, 휴리스틱스 모듈(1314)은 최적화된 백업 또는 역-최적화된 백업을 선택할 수 있다.

예를 들어, 도 13을 도시하면, 하나의 실시예에서, 휴리스틱스 모듈(1314)은 요청(1318)에서 식별되는 복수의 최적화된 데이터 스트림 중 임의의 데이터 스트림의 스트림 맵 청크 메타데이터에 의해 참조되지 않는 데이터 청크(322)에 의해 소비되는 청크 저장소(1334) 내 공간의 크기를 결정할 수 있다. 휴리스틱스 모듈(1314)은, 비-참조되는 데이터 청크에 의해 소비되는 청크 저장소(1334) 내 결정된 공간의 크기가 지정 임계치(가령, 청크 저장소(1334)의 총 저장 공간의 50% 또는 그 밖의 다른 퍼센티지) 미만인 경우 최적화된 데이터 스트림 백업 기법이 될 백업 기법을 선택할 수 있다. 휴리스틱스 모듈(1314)은, 비-참조되는 데이터 청크에 의해 소비되는 청크 저장소(1334) 내 결정된 공간의 크기가 지정 임계치보다 큰 경우, 역-최적화된 데이터 스트림 백업 기법이 될 백업 기법을 선택할 수 있다.

하나의 실시예에서, 휴리스틱스 모듈(1314)은 다음의 분석을 수행하여 백업 기법을 설정할 수 있다. 하나 이상의 명칭공간 루트(namespace root)를 포함하는 백업 범위가 주어지고, 이때 명칭공간 루트는 재귀적으로(recursively) 하위 폴더를 포함하는 폴더(folder)라면, 다음의 휴리스틱스 파라미터가 정의될 수 있다:

Scope = 백업 공간 내 모든 파일로서, 백업되도록 선택된 폴더 아래의 모든 파일을 의미함,

A = 범위 내 모든 파일의 논리 크기(logical-size)로서, 파일의 논리 크기는 파일이 중복제거되기 전의 파일의 크기임(A는 범위 내 파일의 모든 논리 크기의 합),

B = 범위 내 모든 파일의 디스크 상 크기(size-on-disk)로서, 파일의 디스크 상 크기는 파일의 중복제거 후 최적화된 파일이 디스크 상에서 차지하는 실제 크기임, 그리고

C = 청크 저장소의 크기로서, 이는 모든 청크 저장소 컨테이너 파일의 크기의 합임.

이들 정의를 고려할 때, 백업 애플리케이션이 최적화된 백업을 이용한다면, 백업 매체 상의 총 백업 크기는 B+C이다. 백업 애플리케이션이 역-최적화된 백업을 이용한다면, 백업 매체 상의 총 백업 크기는 A이다.

따라서 휴리스틱스 모듈(1314)은 A 및 B+C에 대한 값들을 계산함으로써, 백업 파일 범위가 결정된 후 최적화된 백업과 역-최적화된 백업 중에 결정하는 데 도움을 줄 수 있다. A > B+C인 경우, 최적화된 백업이 공간을 덜 차지하며, 선택될 수 있다. 그렇지 않고, A < B+C인 경우, 역-최적화된 백업이 공간을 덜 차지하며, 선택될 수 있다.

E. 예시적 데이터 최적화 복원 실시예

도 13을 참조하여, 백업 저장장치(1304)로 백업된 최적화된 데이터 스트림이, 일부 시점에서, 가령, 최적화된 데이터 스트림이 어떻게든 손상(corrupt)될 때, 주 저장장치로 복원되는 것이 바람직할 수 있다. 예를 들어, 최적화된 데이터 스트림의 하나 이상의 청크(가령, 스트림 맵 청크 및/또는 데이터 청크)가 청크 저장소(1334)에서 손상됐을 수 있다. 이러한 경우, 최적화된 데이터 스트림의 백업된 버전이 백업 저장장치(1304)로부터 비-최적화된 형태로 복원되기 바람직할 수 있다. 현재 사용되는 백업 기법은 최적화된 파일 및 청크 저장소 컨테이너 파일을 포함하는 전체 파일 시스템 명칭공간을 백업할 가능성이 높다. 덧붙여, 다수의 현재 사용되는 백업 기법은 여전히 백업 저장장치(2014)로서 순차 백업 매체를 이용하며, 가령 테이프 매체가 있다. 따라서 데이터 스트림을 복원하기 위한 기법이 서로 다른 백업 매체 유형 및 백업 포맷을 고려할 수 있는 것이 바람직하다.

이 서브섹션에서 백업 저장장치로부터 최적화된 데이터 스트림을 복원하기 위한 실시예가 기재된다. 실시예는 최적화된 데이터 스트림(가령, 파일)이 대기시간 및 디스크 I/O 연산을 감소시키는 방식으로 복원되는 것을 가능하게 한다. 하나의 실시예에 따르면, 백업된 청크 컨테이너의 추가로 필요하지 않은 부분을 복원하는 대신 특정 데이터 스트림에 대한 청크가 백업 저장장치로부터 복원되는 것이 가능해진다. 실시예는, 데이터 최적화 메타데이터를 이해할 필요 없이, 그리고 백업 매체 유형 또는 백업 포맷에 대해 가정하지 않고, 전체 최적화된 백업 중에서 데이터 스트림을 선택적으로 복원하는 것을 가능하게 한다.

실시예에서, 데이터 최적화 시스템에서의 데이터 스트림의 복원이 다양한 방식으로 수행될 수 있다. 예를 들어, 도 19는 하나의 예시적 실시예에 따라 데이터 최적화 시스템에서 백업 데이터의 복원을 수행하기 위한 흐름도(1900)를 도시한다. 하나의 실시예에서 흐름도(1900)는 도 1의 청크 저장 인터페이스(116)에 의해 수행될 수 있다. 흐름도(1900)는 설명을 목적으로 도 20과 관련하여 기재된다. 도 20은 하나의 예시적 실시예에 따라, 데이터 복원 시스템(2000)의 블록도를 도시한다. 하나의 실시예에서, 도 13의 데이터 백업 시스템(1300) 및 상기 데이터 복원 시스템(2000)은 공통 시스템에서(가령, 공통 백업/복원 애플리케이션, 등등에서) 구현되거나, 따로 따로 구현될 수 있다. 도 20에서 도시된 것처럼, 데이터 복원 시스템(2000)은 데이터 복원 모듈(2002) 및 백업 저장장치(2034)를 포함한다. 백업 저장장치(2034)는 스트림 컨테이너(302) 및 하나 이상의 청크 컨테이너(304)(가령, 청크 컨테이너(304a 및 304b))를 저장한다. 덧붙여, 데이터 복원 모듈(2002)은 파일 재구성기(file reconstructor)(2004)와 복원 애플리케이션(2006)을 포함한다. 하나의 실시예에서 흐름도(1900)는 파일 재구성기(2004)에 의해 수행될 수 있다. 흐름도(1900)에 대한 설명을 기초로 추가 구조 및 동작 실시예가 해당 분야의 통상의 기술자에게 자명할 것이다. 흐름도(1900) 및 데이터 복원 모듈(2002)이 이하에서 설명된다.

도 20을 참조하면, 복원 애플리케이션(2006)은 카탈로그(또는 그 밖의 다른 임의의 메커니즘)를 이용해 백업 저장장치에서 파일의 위치를 찾음으로써, 그리고 위치가 찾아진 파일을 저장장치로 씀(write)으로써, 백업 저장장치로부터 파일을 복원하도록 구성된 종래의 복원 애플리케이션이다. 복원 애플리케이션(2006)은 복원 기능만 포함하거나, 백업 기능도 더 포함할 수 있다(가령, 백업/복원 애플리케이션일 수 있다). 데이터 최적화 시스템의 경우, 파일 복원 요청에 응답하여 복원 애플리케이션(2006)에 의해 저장장치로 써진 파일은, 스트림 맵 청크로의 참조자를 포함하는 최적화된 시스템 구조이다.

예를 들어, 복원 애플리케이션(2006)은 데이터 스트림을 백업 저장장치(2034)로부터 불러오기 위한 요청(2010)을 수신할 수 있다. 요청(2010)은 데이터 스트림을 파일 명칭으로 식별할 수 있다. 도 20에 도시된 것처럼, 복원 애플리케이션(2006)은 백업 저장장치(2034)로부터, 요청(2010)의 요청된 파일 스트림에 대응하는 최적화된 스트림 구조(2038)(가령, 스트림 메타데이터 스터브)를 불러올 수 있다. 그러나 최적화된 스트림 구조(2038)가 요청(2010)에서 요청된 데이터 스트림에 대한 재분석 포인트(reparse point)이기 때문에(가령, 최적화된 스트림 구조(2038)가 파일 데이터를 포함하지 않기 때문에), 복원 애플리케이션(2006)은 파일 재구성기(2004)를 액세스하여 최적화된 스트림 구조(2038)에 대응하는 데이터 스트림을 재구성하도록 구성될 수 있다. 예를 들어, 파일 재구성기(2004)는 다음과 같이 도 19의 흐름도(1900)를 따르는 데이터 스트림을 재구성하도록 구성될 수 있다.

흐름도(1900)의 단계(1902)에서, 데이터 스트림을 저장장치 내 청크 저장소로부터 불러오기 위한 요청이 수신되고, 상기 요청은 데이터 스트림에 대응하는 최적화된 스트림 메타데이터에 대한 식별자를 포함한다. 예를 들어, 도 20에서 도시된 것처럼, 파일 재구성기(2004)는 복원 애플리케이션(2006)으로부터 요청(2036)을 수신할 수 있다. 요청(2036)은 파일 재구성기(2004)가 최적화된 스트림 구조(2038)에 대응하는 데이터 스트림을 재구성하기 위한 요청이다. 요청(2036)은 최적화된 스트림 구조(2038)를 포함한다. 최적화된 스트림 구조(2038)는 최적화된 스트림 메타데이터 지시자(optimized stream metadata indicator), 가령, 최적화된 데이터 스트림에 대응하는 최적화된 스트림 메타데이터(가령, 스트림 맵 청크)의 위치를 찾기 위해 사용될 수 있는 스트림 맵 표시자를 포함한다. 본원에서 기재된 바와 같이, 최적화된 스트림 메타데이터는 데이터 스트림을 재-어셈블하기 위해 파일 재구성기(2004)에 의해 사용될 수 있는 데이터 청크로의 참조자를 포함한다.

파일 재구성기(2004)는 하드웨어, 소프트웨어, 펌웨어, 또는 이들의 임의의 조합으로 구현될 수 있다. 예를 들어, 하나의 실시예에서, 파일 재구성기(2004)는 백업 저장장치로부터 복원된 최적화된 데이터 구조를 기초로 데이터 스트림을 원상회복하도록 구성된 애플리케이션 프로그래밍 인터페이스(API)일 수 있다. 하나의 실시예에서, 파일 재구성기(2004)의 API는 다음의 형태로 요청(2036)을 수신하도록 구성될 수 있다:

Reconstruct File ([in] restore-state/context, [in] file-name, [in] callback-interface) 여기서 요청 파라미터는 다음과 같이 정의된다:

"restore-state/context"은 복수의 콜(call)들 간 내부 상태를 유지하기 위해 사용되는 레이블(label)이고,

"file-name"은 최적화된 스트림 구조(2038)의 파일 명칭이며,

"callback-interface"는 파일 재구성기(2004)가 복원 애플리케이션(2006)으로 콜백하기 위해 사용될 콜백 인터페이스를 식별한다.

또 다른 실시예에서, 파일 재구성기(2004)는 API가 아닌 다른 방식으로 구성될 수 있다. 설명을 목적으로, 파일 재구성기(2004)를 위한 API 실시예가 이하에서 참조될 수 있지만, 이 실시예로 한정되는 것은 아니다.

단계(1904)에서, 최적화된 스트림 메타데이터 식별자를 기초로 하여 복원 애플리케이션으로 제 1 콜이 생성되고, 상기 제 1 콜은 최적화된 스트림 메타데이터 식별자에 의해 식별되는 최적화된 스트림 메타데이터를 저장하는 저장장치 내 제 1 청크 컨테이너에 대한 파일 명칭을 특정하고, 제 1 청크 컨테이너 내 최적화된 스트림 메타데이터에 대한 오프셋을 특정한다. 도 20에 도시된 바와 같이, 하나의 실시예에서, 파일 재구성기(2004)는 콜백 모듈(callback module)(2008)을 포함할 수 있다. 콜백 모듈(2008)은 콜을 생성하도록 구성되고, 파일 재구성기(2004)에 의해 사용되어(가령, 파일 재구성기(2004)의 API에 의해 사용되어), 복원 애플리케이션(2006)으로 콜백할 수 있다. 상기 콜백 모듈(2008)은 (가령, 복원 애플리케이션(2006)에 의해 제공되는 "콜백-인터페이스"에 따라) 복원 애플리케이션(2006)으로 콜백하여, 콜에서 식별되는 백업 저장장치(2034)로부터 청크를 복원할 수 있다. 상기 파일 재구성기(2004)는 복원된 청크를 수신하고 이들을 사용하여 식별된 데이터 스트림을 재-어셈블할 수 있다. 예를 들어, 하나의 실시예에서, 콜백 모듈(2008)은 다음의 콜백 구조에 따르는 콜을 구현할 수 있다:

Read ([in] restore-state/context, [in] file name, [in] offset, [in] size, [out] buffer), 여기서 콜 파라미터는 다음과 같이 정의된다:

"restore-state/context"는 복수의 콜 간 내부 상태를 유지하기 위해 사용되는 레이블이고,

"file name"은 요청된 청크를 저장하는 백업 저장장치(2034) 내 컨테이너에 대한 파일 명칭이며,

"offset"은 요청된 청크에 대한 컨테이너 내 오프셋이고,

"size"는 요청된 청크의 컨테이너 내 크기이며,

"buffer"는 복원된 청크를 액세스하기 위해 복원 애플리케이션(2006)이 파일 재구성기(2004)에 대해 복원된 청크를 저장할 수 있는 위치(가령, 메모리 또는 그 밖의 다른 저장장치 내 버퍼)이다.

또 다른 실시예에서, 콜은 그 밖의 다른 포맷 또는 구조를 가질 수 있다. 복원 애플리케이션(2006)은 백업 저장장치(2034)로부터 특정 백업된 파일 내 제공된 오프셋에서 청크를 복원할 수 있음으로써 선택적 복원을 하도록 구성된다. 예를 들어, 복원 애플리케이션(2006)은 수신된 콜을 {backup-media, offset-in-media}로 매핑{file-name, file-offset}하기 위해(파일-백업 매체 매핑을 위해) 백업 카탈로그를 이용할 수 있다.

하나의 실시예에서, 최적화된 스트림 메타데이터가 스트림 맵 청크의 형태로 저장되는 경우, (단계(1904)에 따라) 콜백 모듈(2008)에 의해 생성되는 제 1 콜은 최적화된 스트림 구조(2038)에서 스트림 맵 청크 식별자에 의해 식별된 스트림 맵 청크에 대한 복원 애플리케이션(2006)으로의 요청이다. 하나의 실시예에서, 콜백 모듈(2008)은 앞서 기재된 콜백 구조에 따라 제 1 콜을 생성할 수 있다. 콜백 모듈(2008)은 청크 컨테이너 식별자의 값을 "file name" 파라미터로서 포함하고, 청크 오프셋 값의 값을 "offset" 파라미터로서 포함하기 위해 제 1 콜을 생성할 수 있다. 복원 애플리케이션(2006)이 (가령, 디폴트로 크기가 정해진 청크로 인해, 백업 카탈로그 내 저장된 청크 크기 정보를 액세스함으로써, 등등) 백업 저장장치(2034) 내 요청 받은 청크의 크기를 독립적으로 결정할 수 있을 때 "size" 파라미터는 선택 사항이다. 도 20의 예시와 관련하여, 콜백 모듈(2008)은 스트림 컨테이너(302)의 파일 명칭을 "file name" 파라미터로서 포함하고, 스트림 컨테이너(302) 내 스트림 맵의 오프셋의 값을 "offset" 파라미터로서 포함하기 위해 제 1 콜을 생성할 수 있다. 도 20에서 나타날 때, 파일 재구성기(2004)는 콜백 모듈(2008)에 의해 생성된 제 1 콜(2014)을 복원 애플리케이션(2006)으로 송신한다.

단계(1906)에서, 제 1 콜에 응답하여 최적화된 스트림 메타데이터가 수신된다. 하나의 실시예에서, 복원 애플리케이션(2006)은 제 1 콜(2014)을 수신하고 백업 저장장치(2034)를 액세스하여 제 1 콜(2014)에 식별된 스트림 맵 청크를 획득할 수 있다. 복원 애플리케이션(2006)은 백업 저장장치(2034) 내 스트림 컨테이너(302)로 액세스(2016)를 생성하고, 제 1 콜(2014)이 나타내는 스트림 컨테이너(302) 내 오프셋에서 스트림 맵 청크(2018)를 불러온다. 복원 애플리케이션(2006)은 응답(2020)으로 스트림 맵 청크(2018)를 파일 재구성기(2004)로 전송한다.

단계(1908)에서, 최적화된 스트림 메타데이터에 참조된 적어도 하나의 데이터 청크 식별자가 결정된다. 하나의 실시예에서, 파일 재구성기(2004)는 참조된 데이터 청크에 대한 하나 이상의 데이터 청크 식별자에 대해 응답으로 수신된 스트림 맵 청크(2018)에 의해 정의된 스트림 맵의 메타데이터(가령, 도 3의 스트림 맵(310)의 메타데이터(314))를 분석한다. 스트림 맵의 메타데이터는 프로세싱될 데이터 스트림에 포함된 청크 컨테이너(304a 및 304b) 내 데이터 청크(322) 각각으로의 포인터를 데이터 청크 식별자(가령, 도 4의 데이터 청크 식별자(404))의 형태로 포함한다. 이러한 방식으로, 스트림 맵 청크(2018)에 포함된 하나 이상의 데이터 청크 식별자가 결정된다.

단계(1910)에서, 저장장치 내 적어도 하나의 청크 컨테이너로부터 적어도 하나의 데이터 청크를 획득하기 위해 적어도 하나의 데이터 청크 식별자에 대응하는 복원 애플리케이션으로 적어도 하나의 추가 콜이 생성된다. 하나의 실시예에서, 콜백 모듈(2008)은 복원 애플리케이션(2006)으로 하나 이상의 추가 콜을 생성하고, 각각의 콜은 단계(1908)에서 결정된 데이터 청크 식별자에 대응하는 백업 저장장치(2034) 내 데이터 청크(322)에 대한 요청이다. 예를 들어, 콜백 모듈(2008)은 결정된 데이터 청크 식별자(들) 중 대응하는 데이터 청크 식별자를 기초로 하여 복원 애플리케이션(2006)으로 제 2 콜을 생성할 수 있다. 상기 제 2 콜은 앞서 기재된 바와 같은 콜 구조 또는 그 밖의 다른 구조를 가질 수 있다. 상기 제 2 콜은 파일 명칭을 데이터 청크 식별자에 의해 식별되는 데이터 청크(322)를 저장하는 백업 저장장치(2034) 내 청크 컨테이너(304a 및 304b) 중 하나에 대해 ("file name" 파라미터로서) 특정할 수 있다. 제 2 콜은 파일 명칭에 의해 식별되는 제 1 및 제 2 청크 컨테이너(304a 및 304b) 중 하나에서 식별된 데이터 청크(322)에 대해 오프셋을 ("offset" 파라미터로서) 특정할 수 있다. 복원 애플리케이션(2006)이 식별된 데이터 청크(322)의 크기를 독립적으로 결정할 수 있을 때, "size" 파라미터는 선택사항이다. 도 20에 도시된 바와 같이, 파일 재구성기(2004)는 콜백 모듈(2008)에 의해 생성된 제 2 콜(2022)을 복원 애플리케이션(2006)으로 송신한다.

단계(1912)에서, 적어도 하나의 추가 콜에 응답하여 적어도 하나의 데이터 청크가 수신된다. 하나의 실시예에서, 복원 애플리케이션(2006)은 제 2 콜(2022)을 수신하고 백업 저장장치(2034)를 액세스하여 제 2 콜(2022)에서 식별된 데이터 청크(322)를 획득할 수 있다. 예를 들어, 식별된 데이터 청크가 제 1 청크 컨테이너(304a)에 저장되는 경우, 복원 애플리케이션(2006)은 백업 저장장치(2034) 내 제 1 청크 컨테이너(302a)로의 액세스(2024)를 생성할 수 있고, 제 2 콜(2022)에서 나타난 제 1 청크 컨테이너(302a) 내 오프셋에서 데이터 청크(2026)를 불러올 수 있다. 복원 애플리케이션(2006)은 응답(2028)으로 데이터 청크(2026)를 파일 재구성기(2004)로 전송한다.

단계(1908)에서 결정된 각각의 추가적인 데이터 청크 식별자에 대해, 파일 구성기(2004)는 백업 저장장치(2034)로부터 대응하는 데이터 청크(322)를 불러오기 위해, 제 2 콜(2022)과 유사한 방식으로 복원 애플리케이션(2006)으로 추가 콜을 생성할 수 있다. 예를 들어, 파일 재구성기(2004)로부터 수신된 제 3 콜에 응답하여, 복원 애플리케이션(2006)은 백업 저장장치(2034)를 액세스하여 상기 제 3 콜에서 식별된 데이터 청크(322)를 획득할 수 있다. 예를 들어, 식별된 데이터 청크가 제 2 청크 컨테이너(304b)에 저장된 경우, 복원 애플리케이션(2006)은 백업 저장장치(2034) 내 제 2 청크 컨테이너(302b)로의 액세스(2030)를 생성할 수 있고, 제 3 콜에서 나타나는 제 2 청크 컨테이너(302b) 내 오프셋에서 데이터 청크(2032)를 불러올 수 있다. 복원 애플리케이션(2006)은 또 다른 응답으로 데이터 청크(2032)를 파일 재구성기(2004)로 송신할 수 있다. 추가 데이터 청크에 대응하는 추가 콜이 파일 재구성기(2004)에 대한 백업 저장장치(2034)로부터 추가 데이터 청크를 불러오기 위한 유사한 방식으로 프로세싱될 수 있다.

단계(1914)에서, 최적화된 스트림 메타데이터 및 적어도 하나의 데이터 청크가 데이터 스트림을 복원하기 위해 조합된다. 하나의 실시예에서, 백업 저장장치(2034)로부터 불러온 스트림 맵 청크(2018)와 하나 이상의 데이터 청크(322)(가령, 데이터 청크(2026 및 2032))가 데이터 스트림을 복원하기 위해 조합 가능하다. 원상회복 모듈(rehydration module)(702)에 대해 앞서 기재된 것과 유사한 방식으로, 파일 재구성기(2004)는 스트림 맵 청크(2018)의 스트림 맵에 포함된 데이터 스트림 오프셋(402)(도 4)을 사용해, 불러온 데이터 청크(322)를 적절한 순서로 배열하여, 데이터 스트림을 재생성할 수 있으며, 상기 데이터 스트림은 파일 재구성기(2004)에 의해 데이터 스트림(2012)으로서 출력된다. 데이터 스트림(2012)은 주 저장장치에 저장되거나, 주 저장장치에 저장되기 위해 복원 애플리케이션(2006)으로 출력되거나, 특정 적용예에 대해 바람직하게 그 밖의 다른 방식으로 취급 또는 전달될 수 있다.

설명을 목적으로, 최적화된 파일의 예시적 복원이 도 19의 흐름도(1900) 및 도 20의 시스템(2000)을 참조하여 기재된다. 최적화된 파일에 대한 스트림 맵 청크가 스트림 컨테이너(302)에 저장되고, 최적화된 파일은 청크 컨테이너(304a)의 데이터 청크(322a 및 322b)와 청크 컨테이너(304b)의 데이터 청크(322e)를 포함한다. 이 예시에서, 스트림 컨테이너(302)는 파일 명칭(SC5)을 가지며, 청크 컨테이너(304a)는 파일 명칭(CC3)을 갖고, 청크 컨테이너(304b)는 파일 명칭(CC7)을 가진다. 앞서 기재된 바와 같이, 복원 애플리케이션(2006)은 백업 저장장치(2034)로부터 최적화된 파일에 대해 (가령, 파일 명칭 "OFN"을 갖는) 최적화된 스트림 구조(2038)를 복원할 수 있다. 단계(1902)에서, 복원 애플리케이션(2006)은 최적화된 파일에 대해 파일 재-빌드 프로세스(file rebuild process)를 시작하기 위해 (가령, Reconstruct File(OFN, Callback)을 이용해) 파일 재구성기(2004)로의 요청(2036)을 생성할 수 있다. 단계(1904)에서, 콜백 모듈(2008)은 최적화된 파일에 대해 최적화된 스트림 구조(2038)에서 식별된 스트림 맵 청크를 요청하는 복원 애플리케이션(2006)으로 제 1 콜을 생성할 수 있으며(가령, Callback -> Read(internal-state, SC5, streammapchunkoffset, 64K, buffer), 여기서 스트림 맵 청크의 크기가 64K이다. 단계(1906)에서, 복원 애플리케이션(2006)은 스트림 컨테이너(304)로부터 스트림 맵 청크를 불러오고, 응답으로 상기 스트림 맵 청크를 파일 재구성기(2004)로 제공한다. 단계(1908)에서, 파일 재구성기(2004)는 스트림 맵 청크를 분석하여, 원하는 파일에 포함된 데이터 청크(322a, 322b, 및 322e)에 대한 3개의 데이터 청크 식별자를 결정할 수 있다. 단계(1910)에서, 콜백 모듈(2008)은 각각 데이터 청크(322a, 322b, 및 322e)를 요청하는 복원 애플리케이션(2006)으로 3개의 콜을 생성한다(가령, Callback -> Read(internal-state, CC3, datachunk322aoffset, 64K, buffer)의 제 1 콜, Callback -> Read(internal-state, CC3, datachunk322boffset, 64K, buffer)의 제 2 콜, 및 Callback -> Read(internal-state, CC7, datachunk322eoffset, 64K, buffer)의 제 3 콜). 단계(1912)에서, 파일 재구성기(2004)는 상기 3개의 콜에 대한 응답으로 복원 애플리케이션(2006)으로부터 데이터 청크(322a, 322b, 및 322e)를 수신한다. 단계(1914)에서, 파일 재구성기(2004)는 스트림 맵 청크의 스트림 맵에 따라 최적화된 파일을 역-최적화된 형태로 재-어셈블하고, 어셈블된 파일을 저장한다(가령, 상기 재-어셈블된 파일을 디스크 상의 최적화된 스트림 구조(2038)에 다시 쓴다).

흐름도(1900)의 예시에서, 데이터 스트림이 재-어셈블된다(단계(1914)). 또 다른 실시예에서, 데이터 스트림을 재-어셈블하는 것 대신, 최적화된 스트림 구조(2038)가 저장장치(주 저장장치 또는 백업 저장장치)에서 최적화된 파일로서 유지될 수 있고, 데이터 스트림에 포함될 것으로 결정된 데이터 청크가 (백업 저장장치(2034)에 저장되지 않고) 청크 저장소에 저장될 수 있다. 이러한 방식으로, 최적화된 데이터 스트림이 청크 저장소 내 데이터 청크를 참조하는 최적화된 형태로 유지된다. 이러한 실시예에서, (단계(1906)에서 수신된) 스트림 맵 청크 및 (단계(1912)에서 수신된) 하나 이상의 데이터 청크가 청크 저장소에 저장된다.

앞서 기재된 바와 같이, 청크는 다양한 동작, 가령, 단편화제거 및 압축으로 인해 컨테이너 내에서 이동될 수 있다. 따라서 이러한 청크 이동을 추적하는 리디렉션 테이블이 유지될 수 있다. 하나의 실시예에서, 청크를 컨테이너 내 조절된 오프셋으로부터 불러오도록 콜을 조절하기 위해 파일 재구성기(2004)가 리디렉션 테이블을 액세스하도록 구성될 수 있다. 예를 들어, 도 21은 하나의 실시예에 따라 재분배 테이블(redistribution table)(900)을 액세스하는 콜백 모듈의 블록도를 나타낸다. 콜백 모듈(2008)은 백업 저장장치 내 컨테이너 각각(가령, 도 20의 예시의 경우, 스트림 컨테이너(302)와 청크 컨테이너(304a 및 304b) 각각)에 대해 재분배 테이블(900)을 액세스할 수 있다. 이러한 방식으로, 콜백 모듈(2008)은 오래된 오프셋(obsolete offset) 대신 컨테이너 내 조절된 오프셋으로 콜을 생성할 수 있다.

예를 들어, 하나의 실시예에서, 콜백 모듈(2008)은 도 22에 도시된 흐름도(2200)를 수행할 수 있다. 도 22는 하나의 예시적 실시예에 따라, 청크에 대한 업데이트된 오프셋을 획득하기 위한 재분배 테이블을 액세스하기 위한 프로세스를 제공하는 흐름도(2200)를 도시한다. 흐름도(2200)가 이하에서 설명된다.

흐름도(2200)의 단계(2202)에서, 데이터 청크에 대한 데이터 청크 식별자에 포함된 제 1 오프셋을 제 2 오프셋으로 매핑하기 위해 리디렉션 테이블이 액세스된다. 예를 들어, 콜백 모듈(2008)은 스트림 맵 청크가 불러와 질 스트림 컨테이너의 재분배 테이블(가령, 도 3의 스트림 컨테이너(302) 내 리디렉션 테이블(308)) 또는 데이터 청크가 불러와 질 청크 컨테이너의 재분배 테이블(가령, 도 3의 청크 컨테이너(304) 내 재분배 테이블(320))을 액세스할 수 있다. 콜백 모듈(2008)은 임의의 방식으로, 가령, 재분배 테이블을 불러오기 위해 콜을 생성함으로써, 재분배 테이블을 액세스할 수 있다. 예를 들어, 재분배 테이블을 포함하는 컨테이너의 파일 명칭과, 컨테이너 내 재분배 테이블에 대한 오프셋을 정의하는 콜이 생성되고 복원 애플리케이션(2006)으로 전송될 수 있다. 상기 복원 애플리케이션(2006)은 백업 저장장치(2034)로부터 재분배 테이블을 불러올 수 있고, 상기 재분배 테이블을 파일 재구성기(2004)로 제공할 수 있다. 이러한 방식으로, 콜백 모듈(2008)은 재분배 테이블을 액세스하여, 업데이트된 청크 오프셋을 결정할 수 있다.

단계(2204)에서, 데이터 청크 식별자를 기초로 하여 제 2 콜이 복원 애플리케이션으로 생성되고, 상기 제 2 콜은 데이터 청크 식별자에 대응하는 데이터 청크를 저장하는 저장장치 내 제 2 청크 컨테이너에 대한 파일 명칭을 특정하고, 상기 제 2 청크 컨테이너 내 데이터 청크에 대한 제 2 오프셋을 특정한다. 예를 들어, 데이터 청크에 대한 콜 이전에, 콜백 모듈(2008)이 데이터 청크에 대해 재분배 테이블을 액세스하여, (새 오프셋이 재분배 테이블 내에 존재하는 경우) 데이터 청크에 대한 업데이트된 제 2 오프셋을 결정할 수 있다. 콜백 모듈(2008)은 복원 애플리케이션(2006)으로의 콜 내 업데이트된 오프셋 값을 이용하여 데이터 청크를 불러올 수 있다. 상기 콜은 백업 저장장치(2034) 내 청크 컨테이너(304)의 파일 명칭을 특정하고, 재분배 테이블로부터 획득된 업데이트된 오프셋 값을 특정할 수 있다. 복원 애플리케이션(2006)은 콜을 수신하고, 나타난 청크 컨테이너 및 업데이트된 오프셋으로부터 데이터 청크를 불러오며, 상기 불러온 데이터 청크를 응답으로 파일 재구성기(2004)로 제공할 수 있다.

흐름도(2200)의 예시에서, 청크 컨테이너의 재분배 테이블이 액세스되어, 제 1 오프셋에서 제 2 오프셋으로 데이터 청크를 매핑할 수 있다. 대안적으로, 스트림 컨테이너의 재분배 테이블이 액세스되어 스트림 맵 청크를 제 1 오프셋에서 제 2 오프셋으로 매핑하도록 흐름도(2200)가 수정될 수 있다. 하나의 실시예에서, 청크에 대한 콜을 생성하기 전에, 콜백 모듈(2008)에 의해 미리 컨테이너의 리디렉션 테이블을 불러올 수 있다.

하나의 실시예에서, 백업 저장장치(2034)로부터 불러와 지는 청크의 크기는 상기 청크를 불러오기 전에 결정된다. 예를 들어, 하나의 실시예에서, 각각의 청크에 대해, 불러와 질 청크의 크기를 결정하기 위해 콜백 모듈(2008)에 의해 복원 애플리케이션(2006)으로 제 1 콜이 이뤄질 수 있고, 백업 저장장치(2034)로부터 결정된 크기를 갖는 청크를 불러오기 위해 콜백 모듈(2008)에 의해 복원 애플리케이션(2006)으로 제 2 콜이 이뤄질 수 있다.

예를 들어, 하나의 실시예에서, 콜백 모듈(2008)은 청크를 저장하는 백업 저장장치(2034) 내 컨테이너에 대해 파일 명칭과, 상기 청크에 대한 컨테이너 내 오프셋, 및 청크에 대한 헤더 크기(그리고 선택사항으로서 청크를 출력하는 버퍼)를 특정하는 제 1 콜을 생성할 수 있다. 예를 들어, 청크 헤더 크기는 콜백 모듈(2008)이 알고 있는 표준 헤더 크기이다. 제 1 콜은 복원 애플리케이션(2006)으로 전송되어, 상기 제 1 콜에 의해 나타내는 바와 같이 백업 저장장치(2034)로부터 청크 헤더를 불러올 수 있다. 복원 애플리케이션(2006)은 청크 헤더(가령, 스트림 맵 청크 헤더 또는 데이터 청크 헤더)를 불러올 수 있고, 제 1 응답으로 콜백 모듈(2008)로 청크 헤더를 제공할 수 있다. 상기 청크 헤더는 청크의 크기를 나타낼 수 있다. 예를 들어, 스트림 맵 청크 헤더는 스트림 맵 청크의 크기를 나타낼 수 있고, 데이터 청크 헤더는 데이터 청크의 크기를 나타낼 수 있다. 그 후 콜백 모듈(2008)은, 청크를 저장하는 백업 저장장치(2034) 내 컨테이너에 대한 파일 명칭, 상기 컨테이너 내 청크에 대한 오프셋, 및 청크 헤더로부터 결정된 청크에 대한 크기(그리고 선택사항으로서 청크를 출력하는 버퍼)를 특정하는 제 2 콜을 생성할 수 있다. 복원 애플리케이션(2006)은 나타낸 오프셋에서 지시된 크기를 갖는 청크(가령, 스트림 맵 청크 또는 데이터 청크)를 불러올 수 있다. 복원 애플리케이션(2006)은 제 2 응답으로 불러온 청크를 콜백 모듈(2008)로 제공할 수 있다. 이러한 방식으로, 콜백 모듈(2008)은 청크 크기를 결정하기 위해 복원 애플리케이션(2006)을 이용하고, 2개의 콜이 청크를 불러오기 위해 사용될 수 있다: 제 1 콜은 청크 크기를 결정하기 위해 사용될 수 있고, 제 2 콜은 결정된 크기를 갖는 청크를 불러오기 위해 사용될 수 있다.

하나의 실시예에, 콜백 모듈(2008)은 임의의 순서로, 가령, 데이터 청크 식별자가 스트림 맵 청크에 포함된 순서로, 데이터 청크를 불러오기 위해 콜을 생성할 수 있다. 또 다른 실시예에서, 콜백 모듈(2008)이 데이터 청크를 더 효율적인 순서로 불러오도록 파일 재구성기(2004)가 데이터 청크 식별자들을 정렬(sort)하도록 구성될 수 있다. 예를 들어, 도 23은 하나의 예시적 실시예에 따라 파일 재구성기(2004)의 블록도를 도시한다. 도 23에 도시된 바와 같이, 파일 재구성기(2004)는 식별자 정렬기(identifier sorter)(2302)를 포함한다. 식별자 정렬기(2302)는 데이터 청크가 복원되는 순서를 정렬하도록 구성된다. 예를 들어, 하나의 실시예에서, 식별자 정렬기(2303)는 도 24에 도시된 흐름도(2400)를 수행할 수 있다. 도 24는 하나의 예시적 실시예에 따라, 데이터 청크 복원 순서를 정렬하기 위한 프로세스를 제공하는 흐름도(2400)를 도시한다. 흐름도(2400)가 이하에서 설명된다.

흐름도(2400)의 단계(2402)에서, 결정된 청크 컨테이너를 제 1 정렬 키(sort key)로서, 그리고 청크 오프셋을 제 2 키로서 기초로 하여 복수의 데이터 청크 식별자가 정렬된다. 하나의 실시예에서, 하나 이상의 정렬 키에 따라, 식별자 정렬기(2302)는 스트림 맵 청크에 포함되는 데이터 청크 식별자를 정렬하여, 대응하는 데이터 청크를 더 효과적으로 불러오는 것을 가능하게 할 수 있다. 예를 들어, 컨테이너 파일을 제 1 정렬 키로서 그리고 컨테이너 파일 내 청크를 제 2 정렬 키로서 기초로 하여 데이터 청크 식별자들이 정렬될 수 있다. 추가 실시예에서, 추가적인 및/또는 대안적인 기준(criteria) 또는 키(key)를 이용해 데이터 청크 식별자가 정렬될 수 있다.

단계(2404)에서, 복원 애플리케이션으로, 복수의 데이터 청크 식별자에 대응하는 복수의 추가 콜이 단계(2402)에 의해 정의된 순서로 생성된다. 예를 들어, 흐름도(1900)(도 19)의 단계(1910)의 추가 콜이 단계(2402)의 정렬에 의해 정의된 순서로 생성될 수 있다. 이러한 방식으로 데이터 청크를 백업 저장장치(2034)로부터 더 효과적으로 불러올 수 있다. 예를 들어, 데이터 청크가 순차식 매체, 가령, 테이프에 저장되는 순차(sequence)에 일치하는 순차적 순서로 데이터 청크가 불러와 지도록, 그리고 다른 데이터 청크를 복원하기 전에 공통 백업 배체(가령, 동일한 테이프, 동일한 디스크, 등등)에 저장된 데이터 청크가 순차적으로 복원되도록 콜들이 정렬될 수 있다. 이러한 순서화(ordering)는 백업 매체 스위치의 횟수를 감소시킬 수 있고, 백업 매체 내에서, 테이프로부터 복원되기에 특히 바람직한 것이 무엇인지를 찾을 수 있다.

복원 애플리케이션이 복원 순서에 영향을 미치거나, 및/또는 각각의 컨테이너 파일로부터 어느 파일 익스텐트(file extent)가 복원되려 하는지에 대한 사전 통지를 수신할 수 있는 경우 복원 실시예의 성능이 개선될 수 있다. 예를 들어, 실시예에서, 다음의 콜백 함수 중 하나 이상이 파일 재구성기에 의해 사용되어 복원을 개선할 수 있다:

"ContainersRestoreOrder"은 모든 데이터 청크 컨테이너 파일 명칭을 갖는 어레이(array)를 입력으로서 수신하는 복원 순서 콜백이다. 파일 명칭은 파일 재구성을 위해 필요한 컨테이너들(파일 재구성을 위해 필요한 데이터 청크를 적어도 저장하는 컨테이너들)을 포함한다. 이들 콜백 함수의 출력은 동일한 컨테이너 파일 명칭 리스트를 갖는 어레이이며, 이때 리스트가 정렬된다(가령, 재-순서화된다).

이 복원 순서 콜백을 이용해, 테이프 백업의 경우, 복원 애플리케이션은 백업 테이프 및 테이프 상에서 컨테이너 파일이 저장되는 오프셋에 따라 테이프 순서를 기초로 컨테이너 파일 명칭을 정렬할 수 있다. 이러한 정렬 순서에 따라 복원 프로세스가 수행되는 경우, 테이프 매체의 (가령, 사용자에 의한) 교체 및 테이프 찾기(tape seek) 기능이 축소 또는 최소화될 수 있다. 테이프 매체 변경 및 테이프 찾기의 횟수를 최소화함으로써, 테이프 매체의 수명이 증가되고 복원 프로세스의 속도가 높아진다. 이들 컨테이너 파일을 포함하는 테이프가 물리적으로 현장 밖(off-site)에 위치하고, 현장 밖 위치로부터 요청되고 수송될 필요가 있는 경우, 이 능력은 복원 애플리케이션이 데이터의 복원을 완료하기 위해 현장 밖 위치로부터 회수될 필요가 있는 테이프의 리스트를 제공하는 것을 가능하게 한다. 현장 밖 테이프 회수는 수 시간 또는 수일이 걸릴 수 있기 때문에, 이 능력은 데이터 복구의 속도를 상당히 높일 수 있고, 매체 회수와 연관된 비용을 낮출 수 있다.

예를 들어 복원 애플리케이션은 먼저 컨테이너 파일들을, 그들이 위치하는 백업 테이프를 기초로 그룹화할 수 있고, 각각의 테이프 내에서, 컨테이너 파일들은 그들의 테이프 상에서의 위치(시작 오프셋)를 기초로 정렬될 수 있다. 그 후 파일 재구성기가 백업 애플리케이션에 의해 특정된 컨테이너 순서를 기초로 데이터 청크를 복원할 수 있다. 상기 백업 애플리케이션은 정렬된 리스트 내 제 1 데이터 청크 컨테이너 파일 상에 저장되는 데이터 청크에 대해 읽기 콜백 함수(read callback function)를 호출하고, 그 다음에, 정렬된 리스트 내 제 2 데이터 청크 컨테이너 파일 상에 저장된 데이터 청크에 대해 읽기 콜백을 호출할 수 있으며, 그 밖의 다른 나머지도 이런 식으로 호출할 수 있다.

복원의 순서화로부터 이익을 얻지 않는 파일 백업 또는 그 밖의 다른 백업 기법의 경우, 복원 애플리케이션은 데이터 청크 컨테이너 리스트를 정렬하는 것을 피하도록 선택하고 컨테이너 복원 순서를 임의로(arbitrary) 남겨둘 수 있다.

"ContainerRestorePlan"은 단일 데이터 청크 컨테이너 파일 명칭과 오프셋 및 데이터 청크의 크기의 어레이를 입력으로서 수신하는 컨테이너 복원 플랜 콜백이다. 상기 어레이는 명명된 컨테이너(named container)에 저장되고 파일의 재구성을 위해 필요한 모든 데이터 청크를 포함한다.

파일 재구성기는, 데이터 청크 컨테이너 상에 저장된 데이터 청크에 대해 읽기 콜백이 호출되기 전에 데이터 청크 컨테이너당 이 콜백을 1회 호출할 수 있다. 상기 ContainerRestorePlan 콜백은 복원 애플리케이션에 의해 사용되기 위한 복원 플랜을 생성한다. 상기 복원 애플리케이션은 콜백에 의해 출력되는 복원 플랜을 사용할 수 있고, 상기 복원 플랜은 백업 매체로부터 읽힐 필요가 있는 데이터 청크 컨테이너 파일의 파일 익스텐트를 가리킨다. 복원 애플리케이션은 일괄처리(batching), 캐싱(caching), 및 미리-읽기(read-ahead) 같은 기법을 이용해, 백업 매체로부터의 데이터 청크의 인출(fetching)을 최적화하기 위해, 이 복원 플랜을 사용할 수 있다.

이 콜백을 프로세싱하는 것은 선택사항이다. 복원 애플리케이션이 백업 매체로부터의 읽기를 최적화할 수 없거나, 최적화하지 않는 경우, 복원 애플리케이션은 플랜을 무시하고 최적화 없이 읽기 콜백을 프로세싱할 수 있다.

"CreateChunksRestorePlan"은 구조의 어레이를 입력으로서 수신하는 데이터 청크 복원 플랜 콜백이다. 어레이 내 각각의 구조가 파일을 재구성하는 데 필요한 단일 데이터 청크에 대응한다. 각각의 구조는 다음의 구성원을 포함할 수 있다: 컨테이너 파일 명칭(데이터 청크가 저장된 곳을 나타냄), 컨테이너 파일 내 청크 오프셋, 및 청크 크기. 콜백의 출력은 동일한 구조의 어레이이고, 복원이 수행될 순서로 정렬된다.

데이터 청크 복원 플랜 콜백은 복원 순서 콜백과 컨테이너 복원 플랜 콜백의 대안이다. 상기 데이터 청크 복원 플랜 콜백은 적어도 2개의 목적을 수행한다: 첫째, 상기 콜백은 복원 애플리케이션에게 어느 데이터 청크가 복원될 것인지를 나타낸다. 상기 콜백으로의 입력을 기초로 하여, 복원 애플리케이션은 각각의 청크를 갖는 백업 매체, 그리고 각각의 청크의 대응하는 매체 상 위치를 결정할 수 있다. 백업 매체로부터 데이터를 읽기 위한 동일한 최적화 기법이 사용될 수 있다. 둘째, 콜백의 출력을 기초로 하여, 복원 애플리케이션은 청크를 어느 순서로 복원할지에 대해 파일 재구성기에게 명령할 수 있다.

예를 들어, 테이프 백업의 경우, 특정 데이터 청크 컨테이너 파일이 복수의 테이프 상에 저장되는 것이 가능하다. 파일을 재구성하는 것은, 컨테이너 파일이 테이프들 간에 분할됐기 때문에, 동일한 컨테이너 파일 상에 위치하지만 2개의 서로 다른 테이프 상에 백업되는 2개의 데이터 청크를 필요로 할 수 있다. 복원 애플리케이션이 청크 데이터 입도(chunk data granularity)로 복원 순서를 지시할 기회를 가진다면, 컨테이너 파일이 복수의 테이프들 간에 분할된 경우라도, 복원 애플리케이션은 테이프 순서로 데이터 청크를 그룹화하고 정렬할 수 있다.

파일 재구성기가 파일의 복원 프로세스 당 데이터 청크 복원 플랜 콜백을 1회 호출할 수 있다. 파일 재구성기는 요구되는 데이터 청크와, 상기 데이터 청크가 데이터 청크 컨테이너 파일 내 위치하는 곳을 알게 되는 포인트에서 콜백을 호출할 수 있다. 파일 재구성기는 콜백의 출력을 이용하여 데이터 청크 복원의 순서를 제공할 수 있다. 상기 파일 재구성기는 출력 구조 리스트에 의해 지시되는 데이터 청크의 순서를 기초로 읽기 콜백 함수를 호출할 수 있다.

데이터 청크 복원 플랜 콜백의 프로세싱은 선택사항이다. 복원 애플리케이션이 백업 매체로부터의 읽기를 최적화하고 복원 순서를 지지할 수 없거나, 할 필요가 없는 경우, 콜백이 무시되거나 수행되지 않을 수 있다. 그 후 파일 재구성기는 데이터 청크를 앞서 기술된 그들 고유의 로직을 이용해, 또는 약간 임의의 순서(arbitrary order)로 복원할 수 있다.

Ⅲ. 예시적 컴퓨팅 장치 실시예

데이터 중복제거 모듈(104), 유지관리 모듈(106), 데이터 스트림 API(110), 청크 유지관리 API(112), 데이터 액세스 API(114), 청크 저장 인터페이스(116), 데이터 스트림 파서(402), 데이터 청크 저장 관리자(404), 메타데이터 생성기(406), 스트림 맵 생성기(408), 원상회복 모듈(702), 데이터 스트림 어셈블러(1102), 세대 체커(1106), 데이터 청크 리트리버(1108), 데이터 백업 모듈(1302), 최적화된 파일 백업 모듈(1306), 원상회복 백업 모듈(1308), 아이템 레벨 백업 모듈(1310), 데이터 청크 식별자 백업 모듈(1312), 휴리스틱스 모듈(1314), 데이터 복원 모듈(2002), 파일 재구성기(2004), 복원 애플리케이션(2006), 콜백 모듈(2008), 및 식별자 정렬기(2302)가 하드웨어, 소프트웨어, 펌웨어, 또는 이들의 임의의 조합으로 구현될 수 있다. 예를 들어, 데이터 중복제거 모듈(104), 유지관리 모듈(106), 데이터 스트림 API(110), 청크 유지관리 API(112), 데이터 액세스 API(114), 청크 저장 인터페이스(116), 데이터 스트림 파서(402), 데이터 청크 저장 관리자(404), 메타데이터 생성기(406), 스트림 맵 생성기(408), 원상회복 모듈(702), 데이터 스트림 어셈블러(1102), 세대 체커(1106), 데이터 청크 리트리버(1108), 데이터 백업 모듈(1302), 최적화된 파일 백업 모듈(1306), 원상회복 백업 모듈(1308), 아이템 레벨 백업 모듈(1310), 데이터 청크 식별자 백업 모듈(1312), 휴리스틱스 모듈(1314), 데이터 복원 모듈(2002), 파일 재구성기(2004), 복원 애플리케이션(2006), 콜백 모듈(2008), 및/또는 식별자 정렬기(2302)가 하나 이상의 프로세서에서 실행되도록 구성된 컴퓨터 프로그램 코드로서 구현될 수 있다. 또는, 데이터 중복제거 모듈(104), 유지관리 모듈(106), 데이터 스트림 API(110), 청크 유지관리 API(112), 데이터 액세스 API(114), 청크 저장 인터페이스(116), 데이터 스트림 파서(402), 데이터 청크 저장 관리자(404), 메타데이터 생성기(406), 스트림 맵 생성기(408), 원상회복 모듈(702), 데이터 스트림 어셈블러(1102), 세대 체커(1106), 데이터 청크 리트리버(1108), 데이터 백업 모듈(1302), 최적화된 파일 백업 모듈(1306), 원상회복 백업 모듈(1308), 아이템 레벨 백업 모듈(1310), 데이터 청크 식별자 백업 모듈(1312), 휴리스틱스 모듈(1314), 데이터 복원 모듈(2002), 파일 재구성기(2004), 복원 애플리케이션(2006), 콜백 모듈(2008), 및/또는 식별자 정렬기(2302)가 하드웨어 로직/전기 회로로서 구현될 수 있다.

도 25는 본 발명의 실시예가 구현될 수 있는 컴퓨터(2500)의 예시적 구현예를 도시한다. 예를 들어, 저장 시스템(102) 및/또는 이의 임의의 부분이 컴퓨터(2500)와 유사한 하나 이상의 컴퓨터 시스템, 가령, 컴퓨터(2500)의 하나 이상의 특징부 및/또는 대안적 특징부에서 구현될 수 있다. 컴퓨터(2500)는 가령, 종래의 개인 컴퓨터, 모바일 컴퓨터, 또는 워크스테이션의 형태로 된 범용 컴퓨팅 장치이거나, 컴퓨터(2500)는 특수 목적 컴퓨팅 장치일 수 있다. 본원에서 제공되는 컴퓨터(2500)의 기재는 설명을 목적으로 제공된 것이며, 이에 한정되는 것은 아니다. 본 발명의 실시예는 해당 분야의 통상의 기술자에게 자명할 또 다른 유형의 컴퓨터 시스템으로 구현될 수 있다.

도 25에 도시된 바와 같이, 컴퓨터(2500)는 프로세싱 유닛(2502), 시스템 메모리(2504), 및 상기 시스템 메모리(2504)를 포함해 다양한 시스템 구성요소를 프로세싱 유닛(2502)으로 연결하는 버스(2506)를 포함한다. 버스(2506)는 몇 가지 유형의 버스 구조 중 임의의 하나 이상을 나타내는데, 가령, 메모리 버스 또는 메모리 제어기, 주변장치 버스, 가속 그래픽 포트, 및 다양한 버스 아키텍처 중 임의의 것을 이용하는 프로세서 또는 로컬 버스가 있다. 시스템 메모리(2504)는 리드 온리 메모리(ROM)(2508) 및 랜덤 액세스 메모리(RAM)(2510)를 포함한다. 기본 입/출력 시스템(2512)(BIOS)이 ROM(2508)에 저장된다.

또한 컴퓨터(2500)는 다음의 드라이브 중 하나 이상을 가진다: 하드 디스크로부터 읽고 쓰기 위한 하드 디스크 드라이브(2514), 이동식 자기 디스크(2518)로부터 읽고 쓰기 위한 자기 디스크 드라이브(2516), 및 이동식 광학 디스크(2522), 가령, CD ROM, DVD ROM, 또는 그 밖의 다른 광학 매체로부터 읽고 쓰기 위한 광학 디스크 드라이브(2520). 하드 디스크 드라이브(2514), 자기 디스크 드라이브(2516), 및 광학 디스크 드라이브(2520)는 하드 디스크 드라이브 인터페이스(2524), 자기 디스크 드라이브 인터페이스(2526), 및 광학 드라이브 인터페이스(2528)에 의해 각각 버스(2506)로 연결된다. 상기 드라이브 및 이들의 연관된 컴퓨터 판독형 매체는 컴퓨터 판독형 명령, 데이터 구조, 프로그램 모듈, 및 그 밖의 다른 컴퓨터용 데이터의 비휘발성 저장장치를 제공한다. 하드 디스크, 이동식 자기 디스크, 및 이동식 광학 디스크가 기재되었지만, 데이터를 저장하기 위해 그 밖의 다른 유형의 컴퓨터 판독형 저장 매체가 사용될 수 있으며, 가령, 플래시 메모리 카드, 디지털 비디오 디스크, 랜덤 액세스 메모리(RAM), 리드 온리 메모리(ROM), 및 등등이 있다.

복수의 프로그램 모듈이 하드 디스크, 자기 디스크, 광학 디스크, ROM 또는 RAM 상에 저장될 수 있다. 이들 프로그램은 운영 체제(2530), 하나 이상의 애플리케이션 프로그램(2532), 그 밖의 다른 프로그램 모듈(2534), 및 프로그램 데이터(2536)를 포함한다. 애플리케이션 프로그램(2532) 또는 프로그램 모듈(2534)은, 예를 들어, 데이터 중복제거 모듈(104), 유지관리 모듈(106), 데이터 스트림 API(110), 청크 유지관리 API(112), 데이터 액세스 API(114), 청크 저장 인터페이스(116), 데이터 스트림 파서(402), 데이터 청크 저장 관리자(404), 메타데이터 생성기(406), 스트림 맵 생성기(408), 원상회복 모듈(702), 데이터 스트림 어셈블러(1102), 세대 체커(1106), 데이터 청크 리트리버(1108), 데이터 백업 모듈(1302), 최적화된 파일 백업 모듈(1306), 원상회복 백업 모듈(1308), 아이템 레벨 백업 모듈(1310), 데이터 청크 식별자 백업 모듈(1312), 휴리스틱스 모듈(1314), 데이터 복원 모듈(2002), 파일 재구성기(2004), 복원 애플리케이션(2006), 콜백 모듈(2008), 식별자 정렬기(2302), 흐름도(500), 흐름도(1000), 흐름도(1200), 흐름도(1400), 흐름도(1500), 흐름도(1600), 흐름도(1700), 흐름도(1800), 흐름도(1900), 흐름도(2200), 흐름도(2400)(흐름도(500, 1000, 1200, 1400, 1500, 1600, 1700, 1800, 1900, 2200, 및 2400)의 임의의 단계를 포함), 및/또는 본원에 기재된 추가 실시예를 구현하기 위한 컴퓨터 프로그램 로직을 포함할 수 있다.

사용자는 입력 장치, 가령, 키보드(2538) 및 위치지시 장치(pointing device)(2540)를 통해 명령어(command) 및 정보를 컴퓨터(2500)로 입력할 수 있다. 그 밖의 다른 입력 장치(도시되지 않음)가 마이크로폰, 조이스틱, 게임 패드, 위성 접시, 스캐너, 또는 등등을 포함할 수 있다. 종종 이들 입력 장치 및 그 밖의 다른 입력 장치가 버스(2506)로 연결된 직렬 포트 인터페이스(2542)를 통해 프로세싱 유닛(2502)으로 연결되지만, 인터페이스, 가령, 병렬 포트, 게임 포트 또는 전역 직렬 버스(USB)에 의해 연결될 수 있다.

디스플레이 장치(2544)는 또한 인터페이스를 통해, 가령, 비디오 어댑터(2546)를 통해 버스(2506)로 연결된다. 모니터에 추가로, 컴퓨터(2500)는 그 밖의 다른 주변 출력 장치(도시되지 않음), 가령, 스피커 및 프린터를 포함할 수 있다.

컴퓨터(2500)는 어댑터 또는 네트워크 인터페이스(2550), 모뎀(2552), 또는 네트워크를 통한 통신을 확립하기 위한 그 밖의 다른 수단을 통해 네트워크(2548)로 연결된다. 내부형 또는 외부형일 수 있는 모뎀(2552)이 직렬 포트 인터페이스(2542)를 통해 버스(2506)로 연결된다.

본원에서 사용될 때, 용어 "컴퓨터 프로그램 매체", "컴퓨터 판독형 매체", 및 "컴퓨터 판독형 저장 매체"는 매체, 가령, 하드 디스크 드라이브(2514)와 연관된 하드 디스크, 이동식 자기 디스크(2518), 이동식 광학 디스크(2522), 및 그 밖의 다른 매체, 가령, 플래시 메모리 카드, 디지털 비디오 디스크, 랜덤 액세스 메모리(RAM), 리드 온리 메모리(ROM), 및 등등을 포괄적으로 지칭하기 위해 사용된다. 이러한 컴퓨터 판독형 저장장치 매체는 통신 매체와 구별되며 중첩되지 않는다. 통신 매체는 일반적으로 컴퓨터 판독형 명령, 데이터 구조, 프로그램 모듈 또는 그 밖의 다른 데이터를 변조된 데이터 신호, 가령, 반송파로 구현한다. 용어 "변조된 데이터 신호"는 신호 내 정보를 인코딩하기 위한 방식으로 특성 중 하나 이상의 설정되거나 변형된 신호를 의미한다. 비-제한적 예를 들면, 통신 매체는 무선 매체, 가령, 음향, RF, 적외선 및 그 밖의 다른 무선 매체를 포함한다. 실시예는 또한 이러한 통신 매체와 관련된다.

상기에서 기재된 바와 같이, 컴퓨터 프로그램 및 모듈(가령, 애플리케이션 프로그램(2532) 및 그 밖의 다른 프로그램 모듈(2534))이 하드 디스크, 자기 디스크, 광학 디스크, ROM 또는 RAM에 저장될 수 있다. 이러한 컴퓨터 프로그램은 또한 네트워크 인터페이스(2550) 또는 직렬 포트 인터페이스(2542)를 통해 수신될 수 있다. 이러한 컴퓨터 프로그램은, 애플리케이션에 의해 실행되거나 로딩될 때, 컴퓨터(2500)로 하여금 본원에 기재된 본 발명의 실시예의 특징을 구현하도록 한다. 따라서 이러한 프로그램은 컴퓨터(2500)의 제어기를 나타낸다.

본 발명은 또한 임의의 컴퓨터 이용 가능한 매체 상에 저장된 소프트웨어를 포함하는 컴퓨터 프로그램 프로덕트에 관한 것이다. 이러한 소프트웨어는, 하나 이상의 데이터 프로세싱 장치에서 실행될 때, 데이터 프로세싱 장치(들)로 하여금 본원에 기재된 바와 같이 동작하게 한다. 본 발명의 실시예는 현재 알려져 있거나 장차 알려질 임의의 컴퓨터 이용 가능형 또는 컴퓨터 판독형 매체를 이용한다. 컴퓨터 판독형 매체의 예로는, 저장 장치, 가령, RAM, 플래시 저장장치(가령, 플래시 메모리), 솔리드-스테이트 드라이브(SSD), 하드 드라이브, 플로피 디스크, CD ROM, DVD ROM, 집 디스크(zip disk), 테이프, 자기 저장 장치, 광학 저장 장치, MEMS, 나노기술 기반 저장 장치, 및 등등을 포함하지만, 이에 한정되지는 않는다.

Ⅵ. 결론

본 발명의 다양한 실시예가 앞서 기재되었지만, 이들은 예시를 위해 제공된 것이며 한정이 아님을 이해해야 한다. 해당 분야의 통상의 기술자라면, 특허청구범위에 의해 정의되는 본 발명의 사상과 범위 내에서 형태와 세부사항의 다양한 변형이 이뤄질 수 있음을 알 것이다. 따라서 본 발명의 사상과 범위는 앞서 기재된 어떠한 예시적 실시예에 의해서도 제한되지 않고, 이하의 특허청구범위 및 이의 균등물에 따라서만 정의된다.

Claims (20)

1. 데이터 스트림 백업을 위한 방법으로서,
   청크 저장소(chunk store)에 저장된 복수의 최적화된 데이터 스트림(optimized data stream)을 백업을 위해 식별하는 단계 - 상기 청크 저장소는 각각의 최적화된 데이터 스트림을 복수의 청크 및 대응하는 최적화된 스트림 메타데이터로서 포함하며, 상기 복수의 청크는 적어도 하나의 데이터 청크를 포함하며, 상기 대응하는 최적화된 스트림 메타데이터는 상기 적어도 하나의 데이터 청크를 참조하며, 상기 청크 저장소는 상기 백업을 위한 식별 전에 모든 포함된 데이터 청크를 중복제거(deduplicate)된 방식으로 포함함 - 와,
   백업을 위하여 식별된 상기 복수의 최적화된 데이터 스트림을 백업하기 위해 상기 청크 저장소의 적어도 일부분을 백업 저장장치에 저장하는 단계를 포함하며,
   상기 저장하는 단계는
   상기 복수의 최적화된 데이터 스트림이 백업을 위하여 제외 모드(exclude mode)에 따라 선택됐는지 또는 포함 모드(include mode)에 따라 선택됐는지를 결정하는 단계 - 상기 제외 모드는 백업을 위한 적어도 하나의 볼륨이 특정하게 선택되고 하나 이상의 데이터 스트림이 백업으로부터 제외되도록 특정하게 선택되는 제 1 백업 모드이고, 상기 포함 모드는 백업을 위한 적어도 하나의 데이터 스트림이 특정하게 선택되는 제 2 백업 모드임 - 와,
   상기 제외 모드와 상기 포함 모드 중 어떠한 것이 선택되도록 결정되었는지에 기초하여 백업 기법을 선택하는 단계
   를 포함하는
   데이터 스트림 백업을 위한 방법.
   
2. 제1항에 있어서,
   상기 저장하는 단계는
   상기 청크 저장소의 전체를 상기 백업 저장장치에 저장하는 단계와,
   상기 복수의 최적화된 데이터 스트림에 대한 복수의 스트림 메타데이터 스터브(stream metadata stub)를 상기 백업 저장장치에 저장하는 단계 - 각각의 스트림 메타데이터 스터브는 데이터 스트림을 상기 청크 저장소 내 대응하는 데이터에 링크함 - 를 포함하는
   데이터 스트림 백업을 위한 방법.
   
3. 제1항에 있어서,
   상기 저장하는 단계는
   각각의 최적화된 데이터 스트림을, 상기 대응하는 최적화된 스트림 메타데이터에 의해 참조되는 임의의 데이터 청크를 포함하는 대응하는 역-최적화된 데이터 스트림(un-optimized data stream)으로 원상회복(rehydrate)하는 단계와,
   상기 복수의 최적화된 데이터 스트림의 백업을 위하여 각각의 역-최적화된 데이터 스트림을 상기 백업 저장장치에 저장하는 단계를 포함하는
   데이터 스트림 백업을 위한 방법.
   
4. 제1항에 있어서,
   상기 저장하는 단계는
   백업을 위해 식별된 제 1 최적화된 데이터 스트림을 수신하는 단계와,
   상기 제 1 최적화된 데이터 스트림의 최적화된 스트림 메타데이터에 의해 참조되며 상기 백업 저장장치에 이미 저장된 것이 아닌 하나 이상의 데이터 청크를 결정하는 단계와,
   상기 제 1 최적화된 데이터 스트림의 최적화된 스트림 메타데이터를 상기 백업 저장장치에 저장하는 단계와,
   상기 결정된 하나 이상의 데이터 청크를 상기 백업 저장장치에 저장하는 단계를 포함하는
   데이터 스트림 백업을 위한 방법.
   
5. 제1항에 있어서,
   상기 저장하는 단계는
   상기 최적화된 스트림 메타데이터에 의해 참조되는 상기 적어도 하나의 데이터 청크에 대한 대응하는 적어도 하나의 데이터 청크 식별자를 결정하기 위해 각각의 최적화된 데이터 스트림에 대응하는 최적화된 스트림 메타데이터를 분석하는 단계와,
   각각의 최적화된 데이터 스트림에 대해 최적화된 스트림 구조를 상기 대응하는 적어도 하나의 데이터 청크 식별자와 함께 상기 백업 저장장치에 저장하는 단계와,
   상기 최적화된 데이터 스트림의 데이터 청크를 저장하는 상기 청크 저장소의 하나 이상의 청크 컨테이너(chunk container)를 상기 백업 저장장치에 저장하는 단계를 포함하는
   데이터 스트림 백업을 위한 방법.
   
6. 제1항에 있어서,
   상기 제외 모드와 상기 포함 모드 중 어떠한 것이 선택되도록 결정되었는지에 기초하여 백업 기법을 선택하는 단계는
   상기 제외 모드가 선택된 것으로 결정되면, 상기 백업 기법이 최적화된 데이터 스트림 백업 기법이도록 선택하는 단계와,
   상기 포함 모드가 선택된 것으로 결정되면, 상기 백업 기법이 역-최적화된 데이터 스트림 백업 기법이도록 선택하는 단계를 포함하는
   데이터 스트림 백업을 위한 방법.
   
7. 제1항에 있어서,
   상기 식별하는 단계는 각각의 최적화된 데이터 스트림을 파일 명칭에 의하여 식별하는 단계를 포함하는
   데이터 스트림 백업을 위한 방법.
   
8. 제1항에 있어서,
   상기 포함 모드는 하나 이상의 데이터 스트림 중 상기 제외 모드보다 적은 수의 데이터 스트림을 포함하는
   데이터 스트림 백업을 위한 방법.
   
9. 백업으로부터 파일을 복원하는 방법으로서,
   백업 저장장치 내 청크 저장소로부터 최적화된 데이터 스트림을 불러오기 위한 요청을 수신하는 단계 - 상기 요청은 상기 데이터 스트림에 대응하는 최적화된 스트림 메타데이터에 대한 식별자를 포함함 - 와,
   상기 최적화된 스트림 메타데이터에 기초하여 복원 애플리케이션에 대한 제 1 콜을 생성하는 단계 - 상기 제 1 콜은 상기 최적화된 스트림 메타데이터 식별자에 의해 식별된 최적화된 스트림 메타데이터를 저장하는 상기 백업 저장장치 내 제 1 청크 컨테이너에 대한 파일 명칭을 특정하고, 상기 제 1 청크 컨테이너 내 상기 최적화된 스트림 메타데이터에 대한 오프셋을 특정함 - 와,
   상기 제 1 콜에 응답하여 상기 최적화된 스트림 메타데이터를 수신하는 단계와,
   상기 최적화된 스트림 메타데이터에서 참조된 적어도 하나의 데이터 청크 식별자를 결정하는 단계와,
   상기 백업 저장장치 내 적어도 하나의 청크 컨테이너로부터 적어도 하나의 데이터 청크를 획득하기 위해 상기 적어도 하나의 데이터 청크 식별자에 대응하는 상기 복원 애플리케이션에 대한 적어도 하나의 추가 콜을 생성하는 단계와,
   상기 적어도 하나의 추가 콜에 응답하여 상기 적어도 하나의 데이터 청크를 수신하는 단계를 포함하는
   백업으로부터 파일을 복원하는 방법.
   
10. 제9항에 있어서,
    상기 백업 저장장치 내 적어도 하나의 청크 컨테이너로부터 적어도 하나의 데이터 청크를 획득하기 위해 상기 적어도 하나의 데이터 청크 식별자에 대응하는 상기 복원 애플리케이션에 대한 적어도 하나의 추가 콜을 생성하는 단계는,
    대응하는 데이터 청크 식별자에 기초하여 상기 복원 애플리케이션에 대한 제 2 콜을 생성하는 단계를 포함하며, 상기 제 2 콜은 상기 데이터 청크 식별자에 의해 식별된 데이터 청크를 저장하는 상기 백업 저장장치 내 제 2 청크 컨테이너에 대한 파일 명칭을 특정하고, 상기 제 2 청크 컨테이너 내 상기 식별된 데이터 청크에 대한 오프셋을 특정하는
    백업으로부터 파일을 복원하는 방법.
    
11. 제9항에 있어서,
    상기 백업 저장장치 내 적어도 하나의 청크 컨테이너로부터 적어도 하나의 데이터 청크를 획득하기 위해 상기 적어도 하나의 데이터 청크 식별자에 대응하는 상기 복원 애플리케이션에 대한 적어도 하나의 추가 콜을 생성하는 단계는,
    데이터 청크를 위한 데이터 청크 식별자 내에 포함된 제 1 오프셋을 제 2 오프셋으로 매핑시키기 위하여 리디렉션 테이블에 액세스하는 단계와,
    상기 데이터 청크 식별자에 기초하여 상기 복원 애플리케이션에 대한 제 2 콜을 생성하는 단계를 포함하며,
    상기 제 2 콜은 상기 데이터 청크 식별자에 대응하는 데이터 청크를 저장하는 상기 백업 저장장치 내 제 2 청크 컨테이너에 대한 파일 명칭을 특정하고, 상기 제 2 청크 컨테이너 내 상기 데이터 청크에 대한 상기 제 2 오프셋을 특정하는
    백업으로부터 파일을 복원하는 방법.
    
12. 제9항에 있어서,
    상기 제 1 콜은 상기 최적화된 스트림 메타데이터를 스트림 맵 청크로서 저장하는 상기 백업 저장장치 내 상기 제 1 청크 컨테이너에 대한 상기 파일 명칭, 상기 제 1 청크 컨테이너 내의 상기 스트림 맵 청크를 위한 오프셋 및 상기 스트림 맵 청크를 위한 헤더 크기를 특정하고,
    상기 제 1 콜을 생성하는 단계는,
    상기 제 1 콜을 생성하여 상기 스트림 맵 청크를 위한 스트림 맵 헤더를 획득하는 단계와,
    상기 스트림 맵 헤더로부터 상기 스트림 맵 청크의 크기를 결정하는 단계와,
    상기 스트림 맵 청크를 획득하기 위해 제 2 콜을 생성하는 단계를 포함하고,
    상기 제 2 콜은 상기 스트림 맵 청크를 저장하는 상기 백업 저장장치 내 상기 제 1 청크 컨테이너에 대한 상기 파일 명칭, 상기 제 1 청크 컨테이너 내의 상기 스트림 맵 청크를 위한 오프셋 및 상기 스트림 맵 청크의 크기를 특정하는
    백업으로부터 파일을 복원하는 방법.
    
13. 제9항에 있어서,
    복수의 데이터 청크 식별자는 상기 최적화된 스트림 메타데이터 내에 참조되며,
    상기 방법은 결정된 청크 컨테이너를 제 1 정렬 키로, 청크 오프셋을 제 2 키로 사용하여 상기 복수의 데이터 청크 식별자를 정렬하는 단계를 더 포함하며,
    상기 백업 저장장치 내 적어도 하나의 청크 컨테이너로부터 적어도 하나의 데이터 청크를 획득하기 위해 상기 적어도 하나의 데이터 청크 식별자에 대응하는 상기 복원 애플리케이션에 대한 적어도 하나의 추가 콜을 생성하는 단계는 상기 정렬에 의하여 정의된 순서로 상기 복수의 데이터 청크 식별자에 대응하는 상기 복원 애플리케이션에 대한 복수의 추가적인 콜을 생성하는 단계를 포함하는
    백업으로부터 파일을 복원하는 방법.
    
14. 제9항에 있어서,
    상기 복원 애플리케이션에 대한 추가 콜을 생성하여 청크 컨테이너의 정렬된 리스트를 생성하는 단계를 더 포함하며,
    상기 백업 저장장치 내 적어도 하나의 청크 컨테이너로부터 적어도 하나의 데이터 청크를 획득하기 위해 상기 적어도 하나의 데이터 청크 식별자에 대응하는 상기 복원 애플리케이션에 대한 적어도 하나의 추가 콜을 생성하는 단계는 상기 정렬된 리스트에 의하여 정의된 순서로 상기 적어도 하나의 데이터 청크에 대응하는 상기 복원 애플리케이션에 대한 복수의 추가적인 콜을 생성하는 단계를 포함하는
    백업으로부터 파일을 복원하는 방법.
    
15. 제9항에 있어서,
    복원된, 그리고 적어도 하나의 청크 컨테이너와 연관된 상기 데이터 스트림의 모든 데이터 청크의 리스트, 컨테이너의 파일 명칭 중 적어도 하나, 적어도 하나의 데이터 청크를 위한 상기 컨테이너 내의 청크 오프셋 및 상기 컨테이너 내의 상기 적어도 하나의 데이터 청크를 위한 데이터 청크 크기를 포함하는 상기 복원 애플리케이션에 대한 추가 콜을 생성하는 단계를 포함하는
    백업으로부터 파일을 복원하는 방법.
    
16. 시스템으로서,
    백업을 위해 청크 저장소(chunk store)에 저장되는 복수의 최적화된 데이터 스트림(optimized data stream)의 식별을 수신하는 데이터 백업 모듈 - 상기 청크 저장소는 각각의 최적화된 데이터 스트림을 복수의 청크 및 대응하는 최적화된 스트림 메타데이터로서 포함하고, 상기 복수의 청크는 적어도 하나의 데이터 청크를 포함하며, 상기 대응하는 최적화된 스트림 메타데이터는 상기 적어도 하나의 데이터 청크를 참조하며, 상기 청크 저장소는 상기 백업을 위한 식별 전에 모든 포함된 데이터 청크를 중복제거(deduplicate)된 구성으로 포함함 - 을 포함하고,
    상기 데이터 백업 모듈은 백업을 위하여 식별된 상기 복수의 최적화된 데이터 스트림을 백업하기 위해 상기 청크 저장소의 적어도 일부분을 백업 저장장치에 저장하고, 백업을 위해 식별된 상기 복수의 최적화된 데이터 스트림에 의해 참조되지 않는 데이터 청크에 의해 소비되는 상기 청크 저장소 내 제 1 공간 크기를 결정하고, 상기 복수의 최적화된 데이터 스트림을 전부 역-최적화된 형태로 저장하기 위한 공간 크기에서 상기 복수의 최적화된 데이터 스트림을 전부 최적화된 형태로 저장하기 위한 공간 크기를 뺀 공간 크기로서 제 2 공간 크기를 결정하고, 상기 결정된 제 1 공간 크기 및 제 2 공간 크기에 기초하여 백업 기법을 선택하도록 구성되는
    시스템.
    
17. 제16항에 있어서,
    상기 데이터 백업 모듈은
    상기 결정된 제 1 공간 크기가 상기 결정된 제 2 공간 크기보다 작은 경우, 상기 백업 기법이 최적화된 데이터 스트림 백업 기법이도록 선택하고,
    상기 결정된 제 1 공간 크기가 상기 결정된 제 2 공간 크기보다 큰 경우, 상기 백업 기법은 역-최적화된 데이터 스트림 백업 기법이도록 선택하도록 더 구성되는
    시스템.
    
18. 제16항에 있어서,
    상기 데이터 백업 모듈은
    상기 청크 저장소의 전체를 상기 백업 저장장치에 저장하도록 구성된 최적화된 파일 백업 모듈(optimized file backup module)과,
    각각의 최적화된 데이터 스트림을, 상기 대응하는 최적화된 스트림 메타데이터에 의해 참조되는 임의의 데이터 청크를 포함하는 대응하는 역-최적화된 데이터 스트림(un-optimized data stream)으로 원상회복시키고, 각각의 역-최적화된 데이터 스트림을 상기 백업 저장장치에 저장하도록 구성된 원상회복 백업 모듈(rehydrating backup module)과,
    각각의 최적화된 데이터 스트림에 대해, 상기 최적화된 데이터 스트림의 상기 최적화된 스트림 메타데이터에 의해 참조되며 상기 백업 저장장치에 이미 저장된 것이 아닌 하나 이상의 데이터 청크를 결정하고, 상기 최적화된 데이터 스트림의 상기 최적화된 스트림 메타데이터를 상기 백업 저장장치에 저장하며, 결정된 상기 하나 이상의 데이터 청크를 상기 백업 저장장치에 저장하도록 구성된 아이템 레벨 백업 모듈(item level backup module)과,
    상기 최적화된 스트림 메타데이터에 의해 참조되는 상기 적어도 하나의 데이터 청크에 대한 대응하는 적어도 하나의 데이터 청크 식별자를 결정하기 위해 각각의 최적화된 데이터 스트림의 최적화된 스트림 메타데이터를 분석하고, 각각의 최적화된 데이터 스트림을 상기 대응하는 적어도 하나의 데이터 청크 식별자와 함께 상기 백업 저장장치에 저장하고, 상기 최적화된 데이터 스트림의 데이터 청크를 저장하는 상기 청크 저장소의 하나 이상의 청크 컨테이너를 상기 백업 저장장치에 저장하도록 구성된 데이터 청크 식별자 백업 모듈(data chunk identifier backup module)
    중 적어도 하나를 포함하는
    시스템.
    
19. 제16항에 있어서,
    상기 백업 저장장치 내 청크 저장소로부터 데이터 스트림을 불러오기 위한 요청을 수신하는 파일 재구성기(file reconstructor) - 상기 요청은 상기 데이터 스트림에 대응하는 최적화된 스트림 메타데이터에 대한 식별자를 포함함 - 를 더 포함하고,
    상기 파일 재구성기는 상기 최적화된 스트림 메타데이터 식별자에 기초하여 복원 애플리케이션에 대한 제 1 콜을 생성하는 콜백 모듈(callback module)을 포함하며, 상기 제 1 콜은 상기 최적화된 스트림 메타데이터 식별자에 의해 식별된 최적화된 스트림 메타데이터를 저장하는 상기 백업 저장장치 내 제 1 청크 컨테이너에 대한 파일 명칭을 특정하고, 상기 제 1 청크 컨테이너 내 상기 최적화된 스트림 메타데이터에 대한 오프셋을 특정하며,
    상기 파일 재구성기는 상기 제 1 콜에 응답하여 상기 최적화된 스트림 메타데이터를 수신하고, 상기 최적화된 스트림 메타데이터에서 참조된 적어도 하나의 데이터 청크 식별자를 결정하고,
    상기 콜백 모듈은 상기 백업 저장장치 내 적어도 하나의 청크 컨테이너로부터 적어도 하나의 데이터 청크를 획득하기 위해 상기 적어도 하나의 데이터 청크 식별자에 대응하는, 상기 복원 애플리케이션에 대한 적어도 하나의 추가 콜을 생성하며,
    상기 파일 재구성기는 상기 적어도 하나의 추가 콜에 응답하여 상기 적어도 하나의 데이터 청크를 수신하고 상기 적어도 하나의 데이터 청크를 조합하여 상기 데이터 스트림을 복원하는
    시스템.
    
20. 제16항에 있어서,
    상기 데이터 백업 모듈은 각각의 최적화된 데이터 스트림을 파일 명칭에 의하여 식별하는
    시스템.

Images