파일 복제 메커니즘을 자동으로 결정하는 방법, 파일 업데이트를 저장 매체에 백업하는 방법, 및 컴퓨터 프로그램 제품 document_id A220623065777

컴퓨터화된 시스템의 인기가 상승함에 따라, 컴퓨터화된 시스템과 연관된 사용자 및 애플리케이션에 의해 생성된 전자 파일 및 기타 통신물(communications)을 저장 및 백업하고자 하는 니즈(needs)도 증가한다. 일반적으로, 컴퓨터 시스템 및 관련 장치는, 예컨대, 직장(a work setting)에서 워드 프로세싱 문서를 작성하는 일반적인 경우뿐 아니라 보다 정교한 데이터베이스 용도로 사용되는 파일을 생성하는 경우에서와 같이 다양한 이유로 파일을 생성한다. 또한, 이들 문서 중 다수는 보호되어야 하는 가치있는 작업 산출물(work product), 또는 민감한 정보(sensitive information)를 포함할 수 있다. 따라서, 조직(organization)이 정규적으로 전자 파일을 백업하고, 필요할 때 원래 생성된 파일의 신뢰성 있는 복구(restoration)를 행하길 원하는 다양한 이유가 존재한다는 것을 이해할 것이다. 일반적으로, 하나 이상의 이런 백업 솔루션을 구현하는 조직이 직면하는 일부 도전 과제는 특정 복제 메커니즘의 선택(choices)에 관한 것이다. 즉, 보호될 데이터를 프로덕션 서버 볼륨(production sever volume)으로부터 백업 서버의 백업 저장소 볼륨에 복사하는 여러 방식(즉, 복제 메커니즘)이 존재하며, 여기서 백업 서버는 복구를 목적으로 보호되는 데이터가 상주하는 곳이다. 각 복제 메커니즘은 소정의 장점 및 단점을 지닌다는 것을 인해할 수 있다. 예를 들어, 한가지 종래의 복제 메커니즘은 프로덕션 서버가 변경된 파일의 이름을 보호될 볼륨에 로깅(logging)한 후, 전체, 업데이트된 파일을 프로덕션 서버에 있는 보호될 볼륨에 대응하는 백업 서버에 있는 백업 볼륨에 전송하는 것을 필요로 한다. 이를 행하기 위한 또 하나의 유사한 메커니즘은, 프로덕션 서버가 변경된 파일(들)의 이름(들)을 로깅할 뿐만 아니라, 프로덕션 서버에 있는 변경된 파일(들)과 백업 서버에 있는 파일(들)의 대응하는 백업 복사본(들)을 비교하여, 그 후 차이를 나타내는, 변경된 바이트만을 백업 서버에 전송하는 것이다. 특히, 후자의 메커니즘은 그것이 변경들을 모니터링(monitoring)하기 위한 파일 시스템 필터의 사용 없이 행해질 수 있기 때문에 부분적으로 고속 모니터링을 허용할 수 있다. 불행히도, 이 복제 메커니즘은 파일의 이전 복사본(a prior copy)과 업데이트된 버전을 비교하는 경우 더 많은 리소스 오버헤드를 필요로 할 수 있다. 이처럼, 이러한 유형의 복제 메커니즘 모두는 작은 파일, 또는 빈번히 변경되는 한 블록의 바이트에서 하나의 동일한 바이트 세트만을 갖는 대용량 파일에 더욱 효과적으로 되는 경향이 있다. 반대로, 이들 복제 메커니즘은 데이터베이스 파일, 특히 비교적 낮은 빈도로 변경되는 여러 개의 바이트 또는 바이트 블록의 세트들을 갖는 파일 등의 매우 대용량 파일에서는 매우 비효율적일 수 있다. 다른 종래의 복제 메커니즘은 단지 변경된 파일들만을 식별하기보다는 파일들에 대한 변경들을 식별하는 것을 필요로 한다. 파일들에 대한 변경들을 식별하는 이런 메커니즘은, 통상적으로 복제되도록 의도된 파일들(예컨대, 이름, 유형, 또는 위치)을 식별하는 것과, 복제 사이에서 관리자가 정한 시간 간격 사이에(between administrator-defined time intervals) 파일에서 변경된 바이트만을 식별하는 것에 의존한다. 따라서, 백업 에이전트(예컨대, 프로덕션 서버에 있는 "파일 시스템 필터"와 협력하는 "클론 에이전트(clone agent)")는 이들 변경된 바이트만을 로깅하고, 궁극적으로 이들 변경된 바이트를 백업 저장소 볼륨(즉, 저장 매체 상의 "복제 볼륨(replica volume)")에 전달한다. 불행히도, 이 복제 메커니즘은 여전히 매우 대용량 파일 또는 복제 간격 사이에 드물게 변경되는 파일들의 경우에 리소스 소비 관점(resource expenditure standpoint)에서는 보다 비용 효율적인 경향이 있지만, 빈번히 변경되거나 또는 매 업데이트마다 전체 덮어쓰기되는 경향이 있는 파일들의 경우에는 덜 비용 효율적인 경향이 있다. 전술된 복제 메커니즘 모두의 몇몇 개소의 혼성(hybrid)으로 생각될 수 있는 또 다른 유형의 복제 메커니즘은, "바이트 블록(byte blocks)"에 의하여 파일을 식별하는 것을 필요로 한다. 일반적으로, "바이트 블록"은 고정된 사이즈의 인접하는 블록들의 바이트를 포함하고, 여러 개수의 블록이 임의의 소정의 파일에 존재할 수 있다. 예를 들어, 프로덕션 서버(또는 "파일 서버")는 복수의 블록 세트로서 파일을 식별할 수 있고, 각 블록은 복수의 바이트를 포함한다. 임의의 바이트가 소정의 블록 내에서 변경(즉, 업데이트, 기입, 및 기타 등등)되면, 복제 메커니즘은 변경된 블록에 플래그를 설정하고(flag the changed block), 적절한 시점에 전체 블록을 복제 볼륨에 전송할 수 있다. 이처럼, 복제 에이전트는 파일에서 변경된 바이트 각각을 식별하기보다는 변경된 블록의 바이트들을 식별하는 데 필요할 수 있는 그러한 리소스만을 소비할 수 있다. 이는 다수의 변경들이 동일한 바이트 블록에 행해질 수 있더라도 소정의 서버가 추가 오버헤드를 초래하는 것을 회피하게 해줄 수 있다. 그럼에도, 이는 전술된 메커니즘을 통하여 복제 에이전트에게 일부 리소스 소비 장점을 제공할 수 있지만, 이 메커니즘은 여전히 데이터베이스 파일 등의 대용량 파일, 또는 바이트 블록이 동일한 복제 사이클 내에서 두 번 이상 변경되는 파일에 더 적합할 수 있다. 따라서, 자신의 백업 서비스를 위해 특정 복제 메커니즘을 사용하기로 결정하고 있는 조직은, 여러 고려사항에 가중치를 부여할 필요가 있을 수 있다. 이를 복잡하게 하는 것은, 조직이 자신의 현재의 파일 생성/변경 니즈에 관한 결정을 행하더라도, 이러한 고려사항이 향후에 부적절할 수 있다는 생각이다. 예를 들어, 조직에 의해 결정된 특정 복제 메커니즘은, 파일 유형, 사이즈, 위치, 또는 기타 등등과 같이 다른 파일보다는 어떤 특정 파일들에 대해서는 보다 적용가능한 결정을 행할 수 있는 표지(indicia)에 상관없이, 통상적으로 보호될 모든 파일에 적용될 것이다. 따라서, 결정은 가장 통상적인 파일 유형 및/또는 통상적으로 사용되는 애플리케이션의 세트 등의 조직이 느끼기에 자신의 현재의 환경에 최상인 것이 무엇인가에 기초하여 행해질 수 있다. 물론, 지배적인(predominant) 파일 유형(들) 및/또는 애플리케이션 유형들이 나중에 변경되는 경우, 처음에 선택된 복제 메커니즘은 교체될 필요가 있을 수 있다. 이런 가능성은, 처음에 어떤 복제 메커니즘이 선호될 것인가를 추정(project)하려고 하는 경우와 나중에 리소스 소비 관점으로부터(resource expenditure perspective of) 변경이 필요할 때 또는 경우에, 특히 조직에게 어려움을 줄 수 있다. 예를 들어, 조직은, 조직에서 사용되는 많은 수의 애플리케이션(bulk of applications)이 선택된 복제 메커니즘에 적합하거나, 또는 다른 대안으로서 변경되는 조직의 복제 메커니즘에 주기적으로 자신을 의탁(commit)하는 특정한 파일 유형 및/또는 애플리케이션 유형을 사용할 것을 주장한다. 물론 이들 시나리오 전부는 조직에 상당한 비용 및 리소스 소비 문제를 일으킬 수 있다.