WIM 백업 : ImageX 를 드라이브 백업 복원 도구로 활용하기, 기초적인 ImageX 의 사용법

고스트나 트루 이미지의 대용으로 ImageX 를 사용해보는 건 어떨까?

윈도우 드라이브 이미징 백업/복구 프로그램의 삼두마차. 시만텍 고스트, 노턴 고스트, 트루 이미지

윈도우 전체를 백업하고 복원할 때는 보통 고스트나 트루 이미지와 같은 프로그램이 많이 사용됩니다. 고스트나 트루 이미지와 같은 프로그램은 드라이브 이미징(Imaging) 프로그램으로, 지정한 디스크 또는 드라이브(파티션, 볼륨, 이하 드라이브)를 통채로 이미지 파일(Image File) 형태로 저장하는 프로그램입니다. 이제 이러한 드라이브 전체의 데이터는 용량이 매우 크기 때문에 그대로 저장하지 않고, 보통은 압축을 통해 용량을 줄여 저장하게 됩니다. 이러한 이미징 작업을 아주 쉽게 생각하면 드라이브 전체를 압축 파일로 저장해두었다가 다시 풀어주는 것과 비슷하다고 생각하면 됩니다. 다만 ZIP 이나 RAR, 7Z 와 같은 압축 프로그램은 개개의 파일에 설정된 하드 링크, 접근 권한 등의 메타 데이터 정보를 처리할 수 없지만, 이미징 프로그램들은 그러한 정보들까지 모두 처리가 가능한 차이가 있습니다. [윈도우를 백업할 땐 이러한 정보들이 중요하며, 이것이 제대로 처리되지 않을 경우 문제가 발생하게 됩니다. 그래서 윈도우는 일반적인 압축 프로그램으로 백업하지 않는(못하는) 것입니다.]

이미징 방식을 통한 윈도우의 백업/복원 과정

아무튼, 이러한 고스트나 트루 이미지와 같은 드라이브 이미징 프로그램을 통해 윈도우가 설치된 드라이브를 이미징하여 통채로 저장해두고, 이렇게 저장해둔 윈도우 이미지 파일을 필요할 때 다시 원래의 드라이브에 풀어줌으로써, 결론적으로 우리는 윈도우를 백업하고 복원할 수 있습니다.


자~ 그런데 이러한 고스트, 트루 이미지 외에도 마이크로소프트사에서 공식적으로 제공하는 드라이브 이미징 프로그램이 존재하고 있습니다. 바로 윈도우 WAIK(WADK) 에서 제공되는 ImageX(Windows Imaging Utility) 라는 드라이브 이미징 프로그램이 그것입니다. 실제로 윈도우 설치 DVD 에 포함된 설치용 이미지 파일인 Install.wim 파일이 바로 이러한 ImageX 를 통해 제작된 이미지 파일입니다.

[윈도우 8, 7, 비스타] 변화된 윈도우의 설치 구조와 Install.wim 이미지 파일 이해하기
Microsoft TechNet > 배포 기술 참조 > ImageX 기술 참조 > ImageX란?


아무튼, 이러한 ImageX 는 마이크로소프트사에서 공식적으로 윈도우를 이미징하여 배포(설치)하는 용도로 사용하고 있으며, 또한 시스템 관리자들에게도 그러한 용도로 사용하라고 제공한 도구이기 때문에, 그만큼 안정적이고 윈도우와의 호환성도 매우 우수합니다. 자기들이 팔아 먹을 윈도우를 설치하고 배포하는데에 사용되는 도구인데, 안정적이지도 않고, 호환성도 개판이라면 안 되겠죠? 그래서 그러한 부분 만큼은 확실하다고 할 수 있습니다. 예로 윈도우 또는 윈도우 PE 에서 어떠한 드라이브가 인식이 되고 파일을 읽을 수 있다면, ImageX 에서도 해당 드라이브를 문제 없이 인식할 수 있고, 고로 이미징할 수 있으며 반대로 해제할 수도 있다고 보시면 됩니다.

Windows Assessment and Deployment Kit(WADK) 에 포함된 ImageX

ImageX 는 윈도우의 배포(설치)를 목적으로 제공된 도구이지만, 어쨌든 ImageX 는 드라이브 이미징 도구입니다. 태생이 그러하기 때문에 도구의 특성에 맞춰 이미징 기능에만 초점을 맞춰 활용할 수도 있는 것이죠. 이를 통해 ImageX 를 고스트나 트루 이미지를 대체하는 윈도우 이미징 백업/복원 프로그램의 용도로도 충분히 활용할 수 있습니다. [물론 데이터 드라이브도 이미징할 수 있습니다. ^^]

사실 윈도우의 백업과 복원에서 가장 중요한 것은 고스트나 트루 이미지와 같은 프로그램이 아니라 윈도우가 설치된 드라이브 전체를 이미징하고, 이를 올바로 적절하게 풀어주는 그 일련의 작업이 아닐까 생각합니다. 드라이브의 이미징이 가능하다면 기본적으로 그 어떤 도구라도 윈도우의 백업과 복원에 사용할 수 있습니다. 이제 이 글에서는 그것으로 ImageX 라는 도구도 추가로 사용해보자는 것입니다. ^^


ImageX 를 고스트나 트루 이미지를 대신하는 도구로 사용하려면, 분명 ImageX 에도 이들에 비견되는, 또는 뛰어넘는 어떠한 매력이 있어야 할텐데요. ImageX 의 주요한 매력이라면 마이크로소프트의 공식 도구로, 윈도우와의 호환성 및 안정성이 좋고, WAIK(WADK) 를 통해 무료로 제공되며, 단일 파일이고, 크기 또한 매우 작다는 것입니다. 특히나 단일 파일이고, 그 용량이 매우 작기까지 하다는 것은 분명 굉장히 큰 장점이 됩니다. 이는 윈도우의 백업과 복원에 필요한 윈도우 PE 에 단순히 실행 파일을 추가하는 것만으로 매우 쉽게 이식이 가능하다는 것을 의미하니까요.

여기에 더해 ImageX 는 명령을 통해 작동하는 명령(커맨드, 콘솔)형 프로그램이기 때문에 배치 파일이나 스크립트를 통해 사용자가 원하는 대로 손쉽게 자동화 시킬 수 있습니다. 이러한 배치 파일을 통한 자동화가 얼마나 유용한지는 마찬가지로 커맨드 작업을 지원하는 고스트에 관련된 수없이 많은 종류의 팁과 정보, 자료들로 잘 알 수 있습니다. 사실 구닥다리로 취급될 수도 있는 시만텍 고스트가, 지금까지도 널리 사용되는 이유 중에 하나가 바로 배치 파일이나 스크립트를 통한 자동화니까요. 대표적으로 저의 고스트 자동 복구 시스템 시리즈, 스누피님의 스누피 고스트, 중국발의 원키 고스트 등을 보면 하나의 명령형 프로그램이 자동화를 통해 얼마나 변화무쌍한 모습으로 사용될 수 있는지를 잘 알 수 있습니다.

자동화를 통해 다양한 모습으로 활용되고 있는 시만텍 고스트

ImageX 도 이와 같은 명령형 도구이기 때문에 원한다면 고스트와 같은 다양한 자동화가 가능합니다. 실제로 ImageX 를 GUI 환경으로 손쉽게 사용할 수 있도록 만든 GImageX 라는 도구도 존재하고 있습니다. 비단 이런 거창한 프로그램 말고도 간단하게 배치 파일을 다룰 줄 안다면 알아서 자유자재로 활용할 수 있습니다. 물론 배치 파일이나 스크립트를 어느 정는도 다룰 줄 알아야 하겠지만요. ^^

아무튼, 이러한 여러 가지 장점들로 ImageX 를 고스트나 트루 이미지를 대신하는 윈도우의 백업 복원 도구로써 매우 유용하게 활용할 수 있다고 생각합니다. 아니 어쩌면 경우에 따라 ImageX 가 매우 탁월한 선택이 될 수도 있을 듯 하네요.


서론이 조금 길었죠? 실제로 저는 윈도우를 백업하고 복원하는 것에 고스트는 물론 ImageX 도 매우 유용하게 잘 사용하고 있습니다. 그래서 여러분들께 제가 알고 있는 것들을 이야기해보고자 합니다. ImageX 를 통해 어떠한 작업이 가능하고, 어떤 식으로 작업을 처리해야 하는지 등에 대해서 말이죠. 참고로 서론이 이만큼 길다는 것은 그만큼 이번 글은 작정하고 길게 가겠다는 소리입니다. [근데 진짜로 이렇게까지 길어질 줄은 몰랐습니다. 미리 죄송 합니다...]

이번 글에서는 ImageX 의 기초적인 기능에 대한 설명으로, 일단 어떻게 드라이브를 백업하고 복원하는지 그 방법에 대해서 이야기를 하고, 그 외 여러 가지 ImageX 라는 프로그램 자체의 기능과 특성, 알아둬야 할 점 등에 초점을 맞춰 이야기하는 시간을 가져보도록 하겠습니다. 그럼 시작하죠. ^^

p.s 이 글을 단 한 분이라도 처음부터 끝까지 정독하여 읽어주셨으면 하는 작은 바램이 생기네요. 분량 조절 실패...

ImageX 다운로드하기

ImageX 는 윈도우 Vista, 7 용 WAIK 또는 윈도우 8 용 WADK 에 포함되어 제공되는 도구로써, 기본적으로 WAIK 나 WADK 를 설치하면 함께 포함되어 있습니다.

마이크로소프트 다운로드 센터 : Windows 7 용 Windows AIK(자동 설치 키트)
마이크로소프트 다운로드 센터 : Windows 7 SP1 용 Windows AIK(자동 설치 키트) 추가 기능
마이크로소프트 다운로드 센터 : Windows(R) 8 용 Windows ADK(평가 및 배포 키트)

하지만 ImageX 는 ImageX.exe 라는 단일 파일로 작동하는 프로그램이기 때문에, 굳이 위의 WAIK 나 WADK 를 설치하지 않고, ImageX.exe 파일 하나만 따로 준비하여 사용해도 됩니다. 이러한 ImageX 는 32비트 버전과 64비트 버전이 있으며, 두 비트 버전간 기능상의 차이는 없기 때문에, 원하는 비트 버전을 사용하시면 됩니다. 보통 윈도우에서 곧바로 사용할 것이라면 32비트 버전으로 충분하며, 윈도우 PE 에 추가하여 사용할 것이라면 사용할 PE 의 비트 버전과 동일한 버전을 다운로드 받으시면 됩니다.

글에서는 현재 가장 최신 버전인 윈도우 8 ADK 에서 제공하는 6.2.9200.16384 버전을 제공해드리겠습니다. 참고로 ImageX 는 윈도우 8, 7, 비스타, XP 모두에서 사용할 수 있습니다. 파일은 아래와 같습니다.

imagex.exe [32Bit, 6.2.9200.16384, 590KB]
imagex.exe [64Bit, 6.2.9200.16384, 697KB]

윈도우에서 ImageX 를 사용할 수 있도록 준비하기

다운로드 받은 ImageX 파일을 C:\Windows 나 C:\Windows\System32 폴더에 복사해 넣어두면 기본적으로 명령 프롬프트 어느 경로에서나 실행이 가능합니다.

하지만 간혹 윈도우 경로나 시스템 경로에 대한 Path 설정이 깨진 분들이 계시는데요. 그런 분들은 C:\Windows 폴더나 C:\Windows\System32 폴더에 놓아도 정상 작동하지 않습니다. 그래서 그런 분들은 사용할 경로에 직접 ImageX.exe 파일을 복사해놓고 사용하셔야 합니다. 즉, 예를 들자면 E:\ 에 ImageX.exe 파일을 복사해놓고, 명령 프롬프트 경로를 E:\ 로 이동하여 그곳에서 명령을 내리시는 방식으로 사용해야 한다는 이야기입니다.

끝입니다. 이제 ImageX 를 통해 원하는 작업을 진행하면 됩니다. 참고로 현재 글에서 알아보려는 대부분의 ImageX 작업은 관리자 권한을 필요로 합니다. 그렇기 때문에 명령 프롬프트는 반드시 관리자 권한으로 실행하여 작업을 진행하시길 바랍니다.

명령 프롬프트를 관리자 권한으로 실행하기

여기에 더해 미리 말씀드리는 건데 ImageX 를 통해서는 현재 실행 중인 윈도우를 백업할 수 없습니다. 현재 실행 중인 윈도우를 백업하기 위해선 반드시 다른 윈도우, 시스템에 설치된 윈도우가 하나인 단일 윈도우 상태라면 윈도우 PE 로 부팅하여 백업을 진행해야 합니다. 그래서 보통은 ImageX 를 통해 윈도우를 백업하기 위해선 ImageX 를 담은 윈도우 PE 가 필요합니다. 그것은 다음 글에서 알아보도록 하겠으며 일단 이번 글에서는 일단 윈도우가 아닌 일반 데이터 드라이브를 대상으로 하여 ImageX 의 기초적인 사용법 및 특성에 대해서 알아보도록 하겠습니다.

ImageX 를 통해 드라이브 백업하기 - /Capture

일단 앞서의 단락에서 ImageX 를 어느 위치에서나 실행가능하도록 잘 준비해두었다는 가정하에 출발하도록 하겠습니다. 이번 단락은 ImageX 를 통해 어떻게 드라이브를 백업하는지에 대해서 알아보기 위한 것이니 따로 데이터 드라이브를 하나 준비한 후 해당 드라이브를 ImageX 를 통해 이미징(백업)하도록 하겠습니다. 그럼 실제로 ImageX 를 통해 원하는 드라이브를 백업해보도록 하죠.

데이터를 백업할 D: 드라이브

예제로 위와 같은 D: 드라이브가 있습니다. 이 드라이브를 통채로 E:\Backup.wim 파일로 백업해보도록 하겠습니다. ImageX 에서 이미징 작업은 /Capture 명령을 통해 작업합니다. 일단 실제로 드라이브를 백업하는 명령을 보시죠. 관리자 권한으로 명령 프롬프트를 실행한 후 다음과 같이 작업합니다. [이 때 /Compress fast 는 기본값으로 생략해도 적용되지만 원할한 설명을 위해 일부러 추가하였음을 알려드립니다.]

imagex /Capture D: E:\Backup.wim "Drive-D 1st" /Compress fast /Verify

해당 드라이브가 WIM 파일로 백업되었습니다. 명령이 조금 복잡한 듯 보이지만 천천히 살펴보면 그렇게 어려울 것은 없습니다. 그럼 ImageX 에서 백업을 의미하는 /Capture 명령에 대해서 좀 더 알아보도록 하겠습니다. 일단 /Capture 명령의 기본 형식은 다음과 같습니다. 여기에 포함된 매개 변수들은 /Capture 작업에 반드시 포함되어야 하는 것들입니다.

imagex /Capture {원본 드라이브} {저장할 WIM 파일} {"이미지 이름"}

ex) imagex /Capture D: E:\Backup.wim "Drive-D"

간단하죠? 사실 백업은 이렇게만 작업을 해도 됩니다. 즉, 어디를 백업할 것이고, 어떤 백업 파일로 저장할 것이고, 해당 백업 이미지 파일의 이름은 무엇인지 이 세 가지만 적용해주면 된다는 것이죠. 이렇게만 작업을 하면 빠른 압축(/Compress fast) 옵션이 자동으로 적용되어 백업 작업이 진행됩니다. 이게 ImageX 를 통한 백업 작업의 기본형입니다. 실제로 여기까지만 알고 계서도 윈도우를 백업하고 복원하는 것에는 큰 무리가 없습니다. 하지만 이번 글은 ImageX 자체에 대한 전체적인 설명을 목표로 하고 있기 때문에 좀 더 자세하게 알아보도록 하겠습니다.

초기 백업을 담당하는 /Capture 명령의 이해와 WIM 파일의 구조

1. /Capture 명령의 형식 및 매개 변수

일단 /Capture 명령의 전체적인 명령의 구성은 아래와 같습니다.

imagex /Capture {원본 드라이브} {저장할 WIM 파일} {"이미지 이름"} ["이미지 설명"] [/Boot] [/Check] [/Compress (maximum|fast|none)] [/Config] [/Norpfix] [/Scroll] [/Temp] [/Verify]

참고로 {} [] 는 각 매개 변수를 구별하기 위한 표식이며, 이 중에서 {} 는 반드시 포함해야 하는 매개 변수를 의미하고, [] 는 사용자가 임의로 선택하여 적용할 수 있는 매개 변수들입니다. [색으로도 구별을 시켜 놓았습니다.] 추가적인 매개 변수들의 적용 순서는 상관이 없습니다.

일단 딱 봐도 매개 변수가 좀 많죠. 각 매개 변수의 정확한 설명은 명령 프롬프트에서 imagex /Capture /? 명령으로 도움말을 통해 직접 확인하실 수 있습니다. 앞으로 나올 모든 명령들도 이와 같이 확인이 가능하니 막힌다면 도움말을 참고하시면 됩니다. 그리고 아래의 문서는 마이크로소프트에서 제공하는 ImageX 명령줄 옵션에 대한 도움말 페이지입니다. 비스타용 WAIK 의 ImageX 에 대한 설명이지만 크게 변경된 부분이 없기 때문에 이해에 무리는 없습니다. 참고하세요.

Microsoft TechNet > 배포 도구 기술 참조 > ImageX 기술 참조 > ImageX 명령줄 옵션


아무튼, 이야기를 계속 이어나가자면 ImageX 는 드라이브 이미징 도구이기는 하지만, 처음에 이야기한 것과 같이 윈도우의 배포(설치)와 PE 용 이미지의 제작도 겸하는 이미징 도구이기도 하다 보니, 그와 관련된 옵션(매개 변수)들도 함께 포함되어 있습니다. 그래서 모든 옵션을 다 살펴 볼 필요는 없습니다. 그러니 배포와 PE 이미지를 위한 매개 변수들은 일단 제외시키도록 하겠습니다.

아래는 /Capture 명령에서 사용되는 매개 변수들 중 윈도우의 백업과 복원이라는 관점에서 필요한 주요 매개 변수들을 정리한 표입니다. 이 외의 매개 변수들은 딱히 알아두지 않으셔도 될 듯 하네요.

매개 변수		설명
원본 드라이브		캡쳐할 드라이브(볼륨)을 지정합니다.
저장할 WIM 파일		새 WIM 파일의 전체 경로와 이름을 지정합니다. 만약 지정한 WIM 파일이 이미 존재하는 경우 해당 파일을 제거하고 새로 만듭니다.
"이미지 이름"		생성할 이미지의 이름을 지정합니다. 이 값은 이미지 정보에서 <NAME> 속성으로 저장됩니다.
"이미지 설명"		생성할 이미지에 대한 설명을 지정합니다. 이 값은 이미지 정보에서 <DESCRIPTION> 속성으로 저장됩니다.
/Compress	Maximum	최고 압축. LZX 알고리즘을 사용하여 이미지를 압축합니다. 시간이 오래 걸리지만 그만큼 WIM 파일의 크기는 줄어듭니다.
	Fast	빠른 압축. Xpress 알고리즘을 사용하여 이미지를 압축합니다. 더 빠르게 압축하지만 그만큼 WIM 파일의 크기는 늘어납니다. /Compress 매개 변수를 생략하는 경우 기본적으로 이미지에 Fast 압축 옵션이 적용됩니다.
	None	이미지를 압축하지 않습니다.
/Norpfix		내부 링크된 재분석 지점(Reparse Point)의 대상 경로를 수정하지 않습니다.
/Check		이미지에 해시 정보를 함께 저장하여 이미지의 무결성 여부를 검사합니다. 이는 이미지 자체에 대한 무결성 여부를 검사하는 옵션입니다. (Integrity Check)
/Verify		파일들이 정상적으로 이미징되었는지 파일 리소스 유효성 검사를 실행합니다. 이는 원본 파일과 이미지에 백업된 파일을 서로 비교하여 빠진 파일이 없는지 등을 확인하는 것입니다. (Verification)

2. 이미징 작업의 정확한 이해를 위해 알아보는 WIM 파일의 구조

일단 옵션들에 대해서 좀 더 자세하게 이야기하기 전에 기본적으로 알아두셔야 할 것이 바로 WIM 파일은 다중 이미지 형식이라는 것을 먼저 이해하셔야 합니다. 즉, WIM 파일은 그 자체가 하나의 이미지가 아니라, WIM 파일 안에 각기 다른 여러 개의 이미지가 함께 포함되어 있을 수 있다는 겁니다.

WIM 파일의 구조
Microsoft TechNet : WIM(Windows Imaging) 파일 형식

위 그림 속의 WIM 파일은 두 개의 이미지가 포함되어 있죠. 이런 식으로 WIM 파일에는 여러 개의 이미지를 포함시킬 수 있습니다. 이러한 WIM 파일의 구조는 앞으로 이야기 할 ImageX 를 통한 백업과 복원에서 매우 중요한 기초가 되니 필히 기억하시길 바랍니다.

WIM 이미징 파일 포맷의 기본적인 구조에 대해서 궁금하신 분들은 아래의 문서를 참고하시길 바랍니다. 마이크로소프트의 공식 문서입니다. [마이크로소프트 - WIM(Windows 이미지) 파일 형식 백서]

Windows Imaging File Format.rtf

3. /Capture 이미징 작업의 정확한 의미

그럼 처음부터 다시 이야기하도록 하겠습니다. 일단 /Capture 명령은 지정한 드라이브를 새로운 WIM 파일로 이미징하는 명령입니다. 위에서 말했다시피 WIM 파일에는 하나의 이미지만 존재할 수 있는 게 아닙니다. 하나의 WIM 파일에 계속 추가하여 이미지를 저장할 수 있죠. 그렇다면 이미징 작업에서 어떠한 WIM 파일을 지정했는데, 해당 WIM 파일이 이미 존재한다면 ImageX 는 어떻게 해야 할까요?

1. 해당 WIM 파일을 지우고 새로운 WIM 파일을 만든다.
2. 해당 WIM 파일에 이미지를 추가하여 저장한다. (기존 이미지 + 새 이미지)

/Capture 명령은 이 중에서 1 번 작업에 해당하는 명령입니다. 물론 2 번에 해당하는 작업은 따로 /Append 라는 명령으로 존재하고 있습니다. 이는 뒤에서 알아보도록 하겠습니다.

아무튼, 백업과 복원이라는 관점에서 보자면 최초에 새로운 백업셋으로 백업을 시작할 때 사용하는 명령이 바로 /Capture 명령입니다. 설명과 같이 /Capture 명령에서 지정한 WIM 파일이 이미 존재하는 경우라면 ImageX 는 해당 WIM 파일을 지워버리고, 다시 WIM 파일을 만들게 됩니다. "/Capture 명령은 드라이브를 캡쳐(이미징)하여 새로운 WIM 파일을 만드는 명령이다." 기억하세요.



4. 이미지 이름과 이미지 설명의 이해 : Name 과 Description

말했다시피 하나의 WIM 파일에는 여러 개의 이미지가 동시에 존재할 수 있습니다. 이러한 이미지들은 저장되어 있는 순서대로 번호를 부여 받습니다. 그리고 이렇게 설정된 이미지의 번호를 인덱스(Index) 번호라고 부릅니다. 즉, Index 1 이미지는 해당 WIM 파일의 첫 번째 이미지를 의미합니다. 하지만 이러한 인덱스 번호는 뒤에서 더 이야기하겠지만 이미지를 추가하고 삭제하면서 변할 수 있습니다. 그렇기 때문에 인덱스 번호 외에도 해당 이미지를 정확하게 파악할 수 있는 이미지의 이름이(Name) 필요하죠.

그것이 바로 /Capture 명령에서 지정하는 "이미지 이름" 이며, 이는 필수값입니다. 이러한 이미지 이름은 해당 이미지의 XML 데이터에 <NAME> 값으로 저장됩니다. 여기에 더해 해당 이미지에 대한 설명을 기록해두길 원한다면 추가로 "이미지 설명"을 지정해줄 수 있습니다. 이미지 설명은 이미지의 XML 데이터에 <DESCRIPTION> 값으로 저장됩니다. 이미지 설명은 필수값은 아니기 때문에 간단한 백업과 복원의 용도로 사용할 땐 보통 생략하게 됩니다.

참고로 "이미지 이름" 은 각각의 이미지를 정확하게 구별하는 역할을 하기 때문에, 반드시 이미 저장되어 있는 다른 이미지들의 이름과는 다른 이름으로 지정해줘야 합니다. 이는 /Append 명령에서 다시 이야기하도록 하겠습니다.



5. 이미지 압축 옵션의 이해

WIM 파일은 무압축, 빠른 압축, 최고 압축, 총 세 가지 단계의 압축 옵션을 지원합니다. 하지만 모든 압축이 그러하듯이 압축률이 높아지면 파일의 용량은 줄어들지만 그만큼 작업 시간은 늘어나게 됩니다. 참고로 무압축은 설명할 필요가 없겠죠?


먼저 WIM 이미지의 기본 압축 옵션은 Fast 빠른 압축입니다. 위에서 잠깐 이야기한 것과 같이 만약 /Capture 명령에서 /Compress 매개 변수를 생략하면 ImageX 는 자동으로 Fast 압축 옵션으로 이미지를 압축하여 저장하게 됩니다. 그래서 빠른 압축을 사용할 것이라면 굳이 /Compress fast 압축 옵션은 적용할 필요가 없습니다. 이 부분은 기억을 해두시길 바랍니다.

이러한 Fast 압축 옵션은 Xpress 라는 압축 알고리즘을 통해 이미지를 압축합니다. 그게 뭐냐고 물으신다면 그냥 RAR 나 ZIP, 7Z 와 같은 압축 알고리즘의 하나라는 것 밖에는 이야기를 못 드리겠네요. 깊게 들어가면 저도 모르니 그냥 그러려니 하시고 마이크로소프트가 사용하는 압축 알고리즘 중에 하나라는 것만 알아두시면, 앞으로 인생을 살아가는데에 있어서 어떠한 지장은 없을 거라고 생각합니다. 물론 몰라도 큰 지장은 없습니다. 알아도 그만이고 몰라도 그만입니다.


다음으로 사용할 수 있는 게 Maximum 최고 압축입니다. 이 Maximum 압축 옵션은 LZX 라는 압축 알고리즘을 통해 이미지를 압축합니다. 역시나 뭐냐고 물으시면 그냥 RAR, ZIP, 7Z... 아무튼 이 LXZ 압축 알고리즘은 마이크로소프트가 가장 즐겨 사용하는 압축 알고리즘입니다. CAB 캐비넷 파일이나 CHM 도움말 파일 등이 동일한 LZX 압축 알고리즘으로 압축되어 제공되는 파일들이죠. 아무튼 그렇습니다.


두 압축 옵션에 각기 다른 압축 알고리즘을 사용한다는 것은 좀 특이하네요. 아무튼, 지금까지는 별로 중요하지 않은 내용이었고요. 이제 최종 사용자인 우리에게 정말로 중요한 것은 각각의 압축 옵션이 얼마의 압축률을 보여주며, 생성된 이미지에 용량은 얼마나 차이가 나고, 최종적으로 작업 시간에 얼마의 차이가 나느냐 뭐 그런 것이겠죠. [그러면서 위의 이야기는 왜 했느냐? 그냥 삼천포로 잘 빠지는 제 스타일입니다. 크리스마스 이브에 집구석에 쳐박혀서 글이나 쓰는 솔로의 한풀이라고 생각하세요. 솔직히 말해서 지금 기분이 매우 안 좋아요. -_-]


그래서 아래와 같은 현재 제가 멀티 부팅으로 사용 중인 윈도우 XP 를 무압축, 빠른 압축, 최고 압축으로 각각 이미징하여 비교해보았습니다. ImageX 는 Hiberfil.sys 나 Pagefile.sys, 휴지통 데이터와 같이 필요 없는 파일들은 자동으로 제외하고, 하드 링크와 같은 중복 파일도 자동으로 통합하여 저장하기 때문에, 무압축인 None 이미지의 용량은 그 부분을 감안하여 보시면 됩니다. 참고로 시간은 스캐닝 작업을 제외한 순수한 이미징 작업에 걸린 시간을 측정한 것입니다.

* 하드웨어 환경 : I7 2600 + Asus P8H67 + 16GB RAM + SSD 128GB(원본) + HDD 3TB(대상) [AHCI 모드]
* 작업 환경 : 윈도우 8 Pro 64비트 + ImageX 6.2.9200.16384 32비트
* 백업 요약 : SSD 윈도우 XP SP3 9.5GB -> HDD 3TB
* 복원 요약 : 백업의 반대

ImageX 압축 옵션 비교
[6.2.9200.16384 32비트 버전 기준]

		백업 시간		복원 시간		이미지 크기
None		0:50		3:39		8,975,121KB [8,765MB]
Fast		3:06		3:41		5,900,387KB [5,762MB]
Maxmium		3:21		3:51		5,725,212KB [5,591MB]

* 백업 시간은 압축 옵션마다 동일하게 5 번씩 작업을 수행하여 얻은 결과이며, 복원 시간은 3 번씩 수행하여 얻은 결과입니다. 각 결과의 시간차가 1~2초 정도로 미미했기 때문에, 중간값 하나로 정리하였습니다. 또한 ImageX 의 특성상 복원시마다 드라이브를 포맷하였으며, SSD 의 특성상 빈 데이터가 작업 속도에 영향을 미칠 수 있기 때문에, 포맷 후 Hex 에디터로 살펴보아 트림이 진행된 것을 확인한 후에 새로운 복원 작업을 진행하였습니다. [하아... 내가 왜 복원 테스트를 SSD 에서 했지... 하아... 내 SSD 수명......]

결과를 보시면 아시겠지만, Fast 나 Maximum 이나 백업 이미지 용량과 작업 시간의 차이가 눈에 띌 정도로 그리 크게 차이가 나지 않는 것을 알 수 있습니다. 또한 각 압축 옵션의 복원 시간도 그리 크게 차이가 난다고 볼 수 없습니다. 고로 ImageX 를 통해 작업을 진행할 땐, 조금이라도 백업 이미지 파일의 용량을 더 줄이길 원한다면 Maximum 압축 옵션을, 조금이라도 더 빨리 작업을 끝내고 싶다면 Fast 압축 옵션을 사용하는 게 좋아 보입니다. 결론은 뭐가 가장 좋다고 딱히 이야기하기 그러니 그냥 그 때 그 때 마음이 드는 압축 옵션을 사용하면 될 것 같습니다. 전 명령 내리기 귀찮아서 Fast 를 즐겨 사용합니다. ^^



6. /Check 와 /Verify 의 차이

사용된 단어 자체만 놓고 보자면 Check 와 Verify 는 굉장히 헷갈릴 수 있는 옵션이라고 할 수 있습니다.


일단 먼저 /Check 옵션은 이미지를 저장하면서 Integrity Table(무결성 테이블)에 이미지에 대한 SHA-1 해시값을 함께 저장하는 것입니다. 이를 통해 이미지를 해제할 때 이미지에 어떠한 문제가 생기지 않았는지 무결성을 검사할 수 있도록 하는 것이죠. 즉, /Check 옵션은 이미지 자체의 무결성 검사에 대한 옵션입니다. 참고로 Integrity Table 에 해시값을 추가로 저장하기 때문에 약 몇 KB 내외로 이미지의 용량이 소폭 증가하게 됩니다.


반면 /Verify 는 이미징을 완료한 후 원본 파일과 이미지에 저장된 파일을 비교하여, 혹시나 이미징 과정 중간 빠지거나 잘못 저장된 파일은 없는지를 확인하는 것입니다. 즉, /Verify 옵션은 이미징이 정상적으로 이루어졌는지 작업의 오류 여부를 확인하는 옵션입니다. 단순 비교 확인하는 것이기 때문에 이미지 용량에 변화는 없습니다.


이제 /Check 옵션과 /Verify 옵션의 정확한 차이를 아시겠죠? 참고로 /Check 옵션을 사용하면 해시값을 계산하고 저장하기 위해 약간의 시간이 소요되고, /Verify 옵션은 전체 파일을 다시 한 번 비교하여 확인해야 하기 때문에, 또 그만큼 작업 시간이 늘어나게 됩니다. 작업 시간이 늘어나는 것을 별로 좋아하지 않는 분들은 싫어하실 수도 있겠네요. 참고로 이러한 Integrity Check 와 Verification 과정은 이미지의 생성이 완료된 후 진행되기 때문에, 작업 진행률의 100% 지점에서 멈춘 것처럼 보일 수 있습니다. 100% 에서 작업이 종료되지 않는 것은 멈춘 것이 아니라 확인 중인 겁니다.

아래는 이미징에 /Check 와 /Verify 옵션을 적용하였을 때 얼마 만큼의 시간이 늘어나는지를 정리한 것입니다. 기준은 Fast 압축 옵션으로 잡았습니다. 총 세 번씩 테스트하였고 그 중간값으로 정리하였습니다. 마찬가지로 스캐닝 작업에 소요되는 시간은 제외하였습니다.

ImageX - Integrity Check 옵션과 Verifycation 옵션의 작업 시간 비교
[6.2.9200.16384 32비트 버전, Fast 압축 옵션 기준]

		No		/Check		/Verify		/Check /Verify
Fast		3:06		3:38		4:08		4:45

참고로 마이크로소프트는 ImageX 를 통해 윈도우를 이미징하는 경우, 이 두 가지 옵션을 모두 적용하여 이미지를 생성할 것을 권장하고 있습니다. 왜냐하면, 마이크로소프트에서 이야기하는 윈도우의 이미징은 배포를 위한 것을 전제로 두고 있기 때문에 그렇습니다. 배포는 DVD 에 구워서 나갈 수도 있지만, 기업과 같은 환경에선 대체로 서버에서 클라이언트로 네트워크를 통해 쏴주는 방식으로 진행되는 경우도 많습니다. 심지어 이미징도 네트워크의 드라이브를 대상으로 할 수도 있고 말이죠. 데이터가 네트워크를 타고 돌아다니면 로컬 내부에서만 다루어질 때보다 오염될 가능성이 매우 높아집니다. 그래서 마이크로소프트는 이 두 가지 옵션을 모두 사용할 것을 권장하는 것이죠.

하지만 우리는 네트워크 환경이 아닌 로컬 시스템에서 윈도우나 데이터를 백업하고 복원하는 용도로만 ImageX 를 사용할 것이기 때문에, 굳이 이 두 가지 옵션을 모두 적용할 필요는 없을 듯합니다. 뭐 굳이 따지자면 Verifycation 정도는 해볼만 하지만 Integrity Check 는 굳이 큰 효용은 없다는 생각입니다. 그래도 이 두 가지 옵션을 함께 적용하면 좀 더 확실하긴 하겠죠. 다만 보신 것과 같이 그만큼 시간은 더 걸리게 됩니다. 저는 그냥 대충 그때그때 기분에 따라서 기분 좋을 때 /Verify 옵션만 주는 편입니다. ^^;



7. 이미징 작업시 생략되는 파일과 폴더들

ImageX 는 기본적으로 드라이브를 이미징할 때 아래와 같은 파일들은 제외함을 알려줍니다.

ImageX 로 이미징(백업)시 제외되는 파일과 폴더들

해당 파일들은 설치 임시 파일, 페이징 파일, 최대 절전 모드 파일, 휴지통 파일들로 윈도우가 시작될 때마다 새로 생성되어 초기화되거나, 백업시 굳이 필요치 않기 때문에 자동으로 제외하게 됩니다. 그래서 최종적으로 이미지에 포함되는 전체 파일의 용량은 현재 드라이브의 전체 용량보다 작은 것이 보통입니다. 또한 하드 링크로 연결된 중복 파일 등도 자동으로 통합하여 저장하기 때문에 그만큼 이미지의 용량은 더욱 줄어들 수 있습니다.



8. 이미징 작업시 발생하는 딜레이에 대해서

작업을 시작하고 빠른 시간 이내에 이미징 단계로 넘어가지 못하고 위와 같은 Scanning files and directories... 단계에서 오랜 시간 딜레이가 발생하는 경우가 있습니다. 어떠한 경우엔 몇 분이 넘는 시간 동안 파일과 폴더를 확인하기도 합니다. 이 과정은 단순한 딜레이가 아닌 이미징 작업 전 미리 드라이브 전체의 파일과 폴더를 모두 확인하는 과정입니다. 이 과정을 끝내야 ImageX 는 비로소 이미징 작업을 시작하게 됩니다.

특이한 것은 어떠한 드라이브를 연속하여 두 번 이상 이미징을 하게 된다면, 처음 작업시에만 해당 딜레이가 발생하고, 두 번째 작업부터는 스캐닝 작업이 순식간에 끝나고 곧바로 이미징이 시작됩니다. 실제로 그런 식으로 작업하는 경우는 없을 것이기 때문에 이 내용은 그냥 참고로만 알아두시면 될 듯 합니다.


참고로 위에서 제공해드린 None, Fast, Maximum 압축 옵션과 /Check, /Verify 옵션에 대한 백업 시간의 비교 자료는, 이야기한 것과 같이 이와 같은 스캐닝 과정에서 걸리는 시간은 제외한 것입니다. 방법을 간단하게 설명하자면 연속하여 작업한다면 첫 번째 이미징 작업에서만 스캐닝에 시간이 소요되고, 이후의 나머지 연속된 이미징 작업들에서는 스캐닝에 시간이 소요되지 않는 것을 이용하여 첫 번째 테스트 자료의 값은 버리는 식으로 측정하였습니다. 즉, 5 번의 테스트 자료가 필요하다면 총 6 번의 테스트를 진행한 후 첫 번째 테스트 자료의 값은 버리는 식으로 진행을 한 것이죠.

그래서 사실 ImageX 를 통한 전체적인 백업 시간은 이미징 작업 시간 외에 이와 같은 스캐닝 작업의 시간도 함께 포함해야 하는 것이 맞습니다. 하지만 이러한 스캐닝 작업은 대충 얼마나 걸린다고 결론짓기가 난해할 정도로 시간에 대한 편차가 매우 컸습니다. 어떨 때는 몇 초에서 몇십 초 이내에 스캐닝이 완료되는가 하면 어떨 때는 5 분 가까이 걸린 예도 있었으니까요. 미친X 널뛰기 하듯이 말이죠. 아쉽게도 어떠한 원인이 스캐닝 작업에 이와 같은 널뛰기 편차를 발생시키는지는 정확하게 파악하지 못했습니다.

이러한 이유로 이번 글에서 제공해드린 백업 시간 비교 자료에서는 정확한 비교를 위해 순수하게 각 압축 옵션과 추가 옵션별로, 연속으로 이미징 작업을 진행하는 방식을 사용하여 순수하게 이미징 작업에 걸리는 시간만을 비교한 것입니다. 그것도 대여섯번씩... 내가... 날을 넘겨서 이 좋은 크리스마스에도... 할 게 없어서.. 이 짓을... 아우!!!!!! ㅡㅡ



9. 재분석 지점(Reparse Point) 대상 링크의 수정

ImageX 는 기본적으로 드라이브 내부로 설정된 정션 폴더 및 심볼릭 링크의 대상 경로를 자동으로 현재의 드라이브 문자에 맞춰 수정하게 됩니다. 이것에 대해서는 좀 더 자세한 이야기가 필요하기 때문에 따로 글로 작성하도록 하겠습니다. 아래의 글을 참고하시길 바랍니다.

WIM 백업 : ImageX 를 통한 백업과 복원시 정션과 심볼 링크 자동 수정 방지하기


이 정도면 ImageX 를 통한 드라이브의 백업과 복원에서 백업에 해당하는 /Capture 이미징 작업에 대해선 충분히 알아 보았다고 생각이 드네요. 그럼 다음으로 복원에 해당하는 이미지 해제로 넘어 가죠.

ImageX 를 통해 드라이브 복원하기 - /Apply

1. ImageX 이미지 해제(복원)의 특성 이해하기

ImageX 가 고스트나 트루 이미지와 같은 여타의 이미징 프로그램들과 다른 점이 바로 이 이미지 해제(복원, 이하 복원) 작업에 있습니다. 보통 고스트나 트루 이미지로 복원을 진행하게 되면 해당 드라이브가 초기화됩니다. 즉, 이전의 자료는 모두 사라지는 것이죠. 쉽게 생각하면 자동으로 (백업된 파일 시스템으로) 포맷이 된다고 생각하시면 됩니다.

하지만 ImageX 는 해당 드라이브의 파일 시스템과 기존 파일들은 건드리지 않습니다. 그냥 그 위에 추가로 이미지에 포함된 파일들을 풀어줄 뿐입니다. 풀려는 파일이 이미 존재한다면 덮어 씌우는 것이죠. 쉽게 생각하면 ZIP 과 같은 압축 파일을 풀어주는 것과 비슷합니다. 어떤 ZIP 압축 파일을 D: 드라이브에 풀어준다고 D: 드라이브가 포맷되거나 기존 자료가 사라지지 않는 것처럼요. 백업과 복원의 관점에서 보자면 ImageX 작업은 리눅스에서 tar xvfpz 작업과 비슷하다고 할 수 있습니다.

ImageX 의 이미지 해제 과정은 압축 파일의 압축 해제 과정과 비슷하다.

ImageX 를 통한 복원의 주요 특성을 정리하면 아래와 같습니다.

첫 째, ImageX 를 통한 복원은 파일 시스템을 초기화하지 않는 덕에 원본의 파일 시스템과 상관 없이 파일 시스템을 넘나들어 복원할 수 있는 장점이 있습니다. 즉, 원본 드라이브의 파일 시스템은 FAT32 였지만, 복원할 땐 NTFS 파일 시스템을 가진 드라이브에 복원하는 식으로도 작업이 가능합니다. [단! 하드 링크 데이터를 포함한 경우엔 FAT32 로 복원 불가]

둘 째, ImageX 를 통한 복원은 드라이브에 존재하는 기존의 파일들을 건드리지 않는 덕에 백업 이후 저장된 파일들을 초기화하지 않고 복원을 진행할 수 있는 장점도 있습니다. 즉, 백업했던 당시의 파일들은 원래대로 되돌아가고, 그 이후에 추가된 파일들은 그대로 남겨두는 것이 가능합니다.

윈도우의 백업과 복원이라는 관점에서 이것은 굉장히 유용할 수도, 또는 굉장히 귀찮을 수도 있는 양날의 검과 같습니다. 백업 이후 새로 추가된 데이터들을 그대로 지키고 싶을 땐 유용하겠지만, 고스트나 트루 이미지와 같이 기존의 자료는 전부 밀어버리고 순수하게 백업했던 데이터로만 깨끗하게 복원되길 원한다면 사용자가 직접 포맷 작업을 진행해야 하기 때문에 귀찮을 수 있습니다. 참고로 윈도우를 복원할 땐 보통 포맷을 통해 기존의 윈도우 자료를 모두 밀어버리고 깨끗하게 되돌리는 것이 일반적인 모습입니다. 그것이 어떠한 오류나 악성 코드 등을 좀 더 확실하게 처리할 수 있기 때문이죠.

그래서 ImageX 의 복원을 고스트나 트루 이미지와 같은 방식으로 하고자 한다면 ImageX 작업에 앞서 미리 해당 드라이브를 포맷하는 과정을 추가해줘야 합니다. 이것은 Format 명령을 통해서도 진행할 수 있지만, 그보다는 DiskPart 를 통해 진행하는 것이 좀 더 수월합니다. 특히나 배치 파일을 통해 자동화할 것이라면 DiskPart 가 좋습니다. Format 명령은 포맷하려는 드라이브에 레이블이 존재하면 해당 레이블을 입력해야만 포맷이 가능한 특성이 있고, 이로 인해 자동화가 끊기게 되기 때문에 배치 파일에선 잘 사용되지 않습니다.



2. /Apply 명령의 형식 및 옵션의 이해

이번엔 /Capture 때와는 반대로 먼저 명령을 알아 보고 이후 실제 예제를 보도록 하겠습니다. ImageX 에서 이미지 해제 즉, 복원에 해당하는 명령은 /Apply 명령이며 /Apply 명령의 기본형은 아래와 같습니다.

imagex /Apply {WIM 파일} {이미지 인덱스 번호} {대상 드라이브}

ex) imagex /Apply E:\Backup.wim 1 D:

/Capture 명령과 비교하여 WIM 파일 뒤에 인덱스 번호가 추가되었고, 원본과 대상의 순서가 바뀌었다고 보시면 됩니다.


다음으로 아래는 /Apply 명령의 전체 명령 구성입니다.

imagex /Apply {WIM 파일} {이미지 인덱스 번호} {대상 드라이브} [/Check] [/Norpfix] [/Ref] [/Scroll] [/Verify]

나머지 옵션은 /Capture 명령에서도 본 옵션들이지만 새로이 /Ref 라는 옵션이 보입니다. 이별 장면에선 항상 비가 오지? 는 아니고요. 해당 옵션은 WIM 의 분할 파일인 SWM 파일을 통해 이미지 해제 작업을 진행할 때 나머지 SWM 파일들을 지정해주는 옵션입니다. 이것은 뒤의 이미지 분할에서 좀 더 자세하게 다루겠습니다.



3. Format 과정을 포함하여 기존 파일을 초기화한 후 이미지 해제(복원)하기

앞서 미리 백업해둔 WIM 백업 파일

그럼 앞서 미리 백업해두었던 E:\Backup.wim 파일을 통해 D: 드라이브를 깨끗하게 포맷한 후 복원해보도록 하겠습니다. 이야기했다시피 ImageX 에서 이미지 해제 작업은 /Apply 명령을 통해 작업합니다.

참고로 이전 단락에서 알아본 것과 같이 하나의 WIM 파일 안에는 여러 개의 이미지가 있을 수 있기 때문에, 반드시 이미지 인덱스 번호를 통해 어떤 이미지를 해제할 것인지를 지정해줘야 합니다. 이는 WIM 파일 안에 이미지가 단 하나만 존재할 지라도 반드시 지정해줘야 하죠. 만약에 WIM 파일에 이미지가 하나만 존재한다면 인덱스 번호는 무조건 1 이 됩니다. 참고로 /Capture 명령은 새로운 WIM 파일을 시작하는 명령이죠. 그래서 /Capture 로 생성한 WIM 파일에는 이미지가 하나 밖에 없습니다. 그렇기 때문에 현재 상황에선 이미지 인덱스 번호는 1 로 지정해주면 됩니다.

작업은 DiskPart 의 포맷 작업과 ImageX 의 이미지 해제(복원) 작업으로 나눠서 보시길 바랍니다. [기존 드라이브의 파일 시스템이 NTFS 였기 때문에 이와 동일하게 포맷하였습니다.]

diskpart

select volume=D
format fs=ntfs quick label="Data"
exit

imagex /Apply E:\Backup.wim 1 D:

이전의 데이터 상황 그대로 복원이 된 것을 확인할 수 있습니다. 윈도우의 백업과 복원에선 주로 이러한 방식을 사용하게 됩니다.



4. 기존 파일을 유지한 채 이미지 해제(복원)하기

사실 /Apply 명령에서 더 살펴볼 것은 없습니다. 그래도 실제로 보여 드려야 한다는 쓸데없는 사명감이 가슴 속 깊은 곳에서 우러나오네요. 그것은 글을 쓰고 있는 오늘이 크리스마스이기 때문에 그런 건지 모르겠습니다. 이 좋은 날 집 구석에 쳐박힌 작금의 현실에 한 줄이라도 더 긴 글로 잊고 싶을 뿐입니다.

기존의 파일을 유지한 채 복원하는 방법은 매우 간단합니다. 그냥 이전과는 다르게 포맷 작업 없이 드라이브에 이미지를 곧바로 해제해주면 되는 것이죠. 그러면 백업 이후 추가된 파일들은 모두 그대로 남고, 백업 당시 있었던 파일들은 백업 당시의 파일로 교체되게 됩니다. 사라진 파일들은 복원되는 것이고요. 간단하죠?

일부 파일은 사라지고, 새로운 파일이 추가되어 있는 D: 드라이브의 모습

어떤가요? 사라진 파일도 복원되었고, 백업 이후 저장했던 새로운 파일도 정상적으로 존재하는 것을 확인할 수 있죠? 일부 대기업 PC 에 포함된 시스템 복원 프로그램이 이러한 방식을 지원하기도 합니다. 특히나 대부분 디스크 하나로 구성되어 있는 노트북의 시스템 복원 프로그램이 이러한 방식을 지원하는 경우가 많죠. 해당 복원 프로그램들을 살펴보면 복원시 기존 파일을 유지할 것인지 초기화할 것인지를 선택할 수 있는 메뉴가 있는 경우가 있습니다. 해당 시스템 복원 프로그램은 지금 이야기하고 있는 ImageX 의 백업 복원과 동일한 방식을 사용한다고 생각하시면 됩니다. [이는 해당 이미징 백업/복원 프로그램이 파일 기반(File-Based) 방식의 이미징 프로그램임을 의미하기도 합니다. ImageX 도 파일 기반입니다.]


일단 여기까지 하여 ImageX 를 통해 드라이브를 백업하고 복원하는 것의 기초는 모두 알아보았습니다. 이것저것 많이 이야기했지만 사실 실제 백업과 복원을 실행하는 명령을 알아본 부분은 간단했죠? 물론 완벽한 윈도우의 백업과 복원을 위해선 이것 외에도 몇 가지 내용들을 더 이야기해야 합니다. 그건 실제로 윈도우를 백업하고 복원할 때 이야기하도록 하겠습니다. 일단은 여기까지만 알아두셔도 됩니다.

기왕 시작한 것 ImageX 의 기초는 이번 글에서 모두 끝내죠. 그럼 계속하여 다음으로 넘어가도록 하겠습니다.

WIM 파일 내 이미지들의 데이터 대통합과 증분 백업 효과

1. 전체 백업과 증분 백업은 어떻게 다른가? - 증분 백업이란?

일단 백업에 대해서 이야기하도록 하겠습니다. 어떠한 데이터 개체를 백업할 땐 전체 백업(Full Backup), 증분 백업(Incremental Backup), 차등 백업(Differential Backup), 합성 백업(Synthetic Backup)이라는 각기 다른 개념의 백업 방식 중 하나를 선택하여 백업 계획을 수립하게 됩니다.

각 백업의 차이에 대해서 자세하게 설명을 드리고 싶지만, 지금은 순수한 백업의 개념을 잡는 시간이 아니기 때문에 이 중에서 ImageX 와 관련이 있다고 할 수 있는 전체 백업과 증분 백업만 살펴보도록 하겠습니다. 일단 그렇다 하더라도 참고할 수 있는 문서의 링크를 걸어드릴텐데요. 제가 지금까지 본 글들 중에서 각 백업의 개념을 가장 이해하기 쉽게 설명한 글이지 않을까 생각합니다. 일본 웹이지만 아시다시피 일본어는 한국어로 번역이 상당히 매끄럽게 되기 때문에, 구글의 번역 페이지를 통해서도 충분히 이해할 수 있을 만큼 잘 번역이 되어서 나옵니다. 각 백업 방식의 정확한 차이에 대해서 궁금하신 분들은 아래의 글을 참고해보세요.

ASCII.jp - 전체 백업 및 증분 백업은 무엇이 다른가? [구글 번역 페이지]


A. 전체 백업(Full Backup)

기왕 이야기한 것 그냥 저도 해당 글의 이미지를 사용하여 설명을 해보도록 하겠습니다. 일단 전체 백업이란 말 그대로 언제나 모든 데이터를 백업하는 방식을 의미합니다.

전체 백업 방식, 위 원본 데이터, 아래 백업 데이터.

이 방식은 모든 백업의 기초입니다. 모든 이미징 방식의 백업 프로그램은 이 방식을 지원합니다. 참고로 시만텍 고스트는 오직 이 방식만을 지원하죠. 그래서 좀 안타까워 하시는 분들도 많습니다. 각설하고, 보시는 것과 같이 전체 백업은 백업을 진행할 때마다 모든 데이터를 백업하는 방식입니다.

전체 백업 방식의 장점이라면 백업 파일 하나 하나가 모두 독립적으로 작동하는 완전한 하나의 백업 개체라는 점입니다. 즉, 복원을 진행할 때 다른 백업 파일이 전혀 필요치 않습니다. 오직 복원을 진행하려는 그 백업 파일만 정상적으로 존재하면 되죠. 그래서 관리가 쉽습니다.

하지만 전체 백업 방식의 치명적인 단점이라면 언제나 모두를 백업하기 때문에 백업에 그만큼 시간이 오래 걸리고, 백업 용량도 크게 잡아 먹는다는 점입니다. 즉, 중복된 데이터들을 백업본마다 모두 각기 가지고 있기 때문에 백업 매체에서 그만큼 용량이 낭비됩니다.

이 방식은 백업과 백업 사이의 텀이 매우 길 때 유용합니다. 날마다 진행해야 하는 백업에 이 방식을 사용한다는 것은 미친 짓이라고 할 수 있죠. 백업의 텀이 꽤 긴 편인 윈도우는 주로 이러한 전체 백업 방식을 통해 백업을 하는 편입니다.


B. 증분 백업(Incremental Backup)

증분 백업이란 먼저 어떠한 시점에 전체를 백업한 하나의 기준 백업(Base Backup)을 작성한 후, 이후부터는 각 백업 시점마다 이전 백업 이후에 변경된 파일들만 백업하는 방식을 의미합니다.

증분 백업 방식. 위 원본 데이터, 아래 백업 데이터.

노턴 고스트의 복구 지점 세트 백업과 트루 이미지에 기본적으로 선택된 백업이 바로 이 증분 백업에 해당합니다.

증분 백업 방식의 가장 큰 장점이라면 바로 백업 용량이 가장 적게 소모된다는 점 입니다. 새로 추가된 데이터만 백업하기 때문이죠. 백업할 데이터도 적기 때문에 각 백업에서의 백업 시간도 그만큼 적게 걸립니다.

하지만 증분 백업 방식의 단점이라면 일단 복원시 그 시점 이전의 모든 백업 파일을 사용해야 하기 때문에 전체 백업보다 복원에 다소 시간이 오래 걸릴 수 있습니다. 하지만 이것은 사실 큰 문제가 아닙니다. 증분 백업 방식의 가장 큰 단점은 바로 백업 파일의 관리가 지랄맞게 어렵다는 점입니다. 어떠한 백업 시점으로 복원을 진행하기 위해선 해당 시점의 백업 이미지는 물론 그 이전의 다른 모든 증분 백업본과 기준 백업본이 전부 필요합니다. 하나라도 없으면 안 되죠. 그래서 만약에 어떠한 백업 파일을 유실하였다면, 그 이후의 모든 증분 백업본들은 쓰레기가 됩니다. 만약에 기준 백업을 잃어버리면, 모든 백업이 삽질이 되는 것이고요. 말 그대로 지랄맞은 상황이라고 할 수 있죠.

증분 백업에선 이 모든 백업 파일들을 철저하게 관리해야 하는 불편이 있다.

그래서 증분 백업을 백업 방식으로 결정했을 땐 적당한 스케줄을 짜고, 해당 스케줄에 맞춰 일정한 기간마다 다시 새로이 기준 백업을 작성하여 새로운 증분 백업 세트를 시작하는 방식을 사용하게 됩니다.

이러한 증분 백업의 어떠한 증분 백업본을 잃어버리면 이후의 모든 증분 백업본들은 쓰레기가 된다는 단점을 보완하는 방식이 바로 차등 백업 방식이며(기준 백업과 해당 차등 백업 지점만 존재하면 복원 가능), 하나의 증분 백업을 진행하면 그 이전의 증분 백업본과 기준 백업본을 하나로 합쳐 새로운 기준 백업본을 생성하는 방식이 바로 합성 백업입니다. 다른 백업 방식들은 더 설명할 필요는 없겠죠?

아무튼, 증분 백업이나 차등 백업은 윈도우와 같이 잘 변하지 않는 대상보다는 일반 데이터를 백업하는데에 주로 이용됩니다. 물론 노턴 고스트나 트루 이미지는 이러한 증분, 차등 백업을 좀 더 직관적이고 관리하기 쉽게 만들어 윈도우의 백업에서도 이용하고 있습니다. 그런데 사실 일반적인 사용자가 윈도우를 아주 디테일하게 스케줄을 작성하여 증분 백업이나 차등 백업 방식으로 굳이 관리할 필요까지 있을까라는 게 제 개인적인 생각입니다. 하지만 [1. 초기 윈도우 설치], [2. 드라이버만 설치], [3. 프로그램 설치] 와 같이 미리 일정한 백업 시점을 계획하고, 이를 스케줄 없이 해당 시점에 각각 증분(차등) 백업하는 방식으로 백업하는 것은 충분히 유용하다고 생각합니다.

어쩌다보니 필요한 설명은 다 설명을 해버렸네요? 그러려니 하고 넘어 가죠.



2. WIM 파일내 개별적인 이미지에서의 중복 파일 통합과 이미지와 이미지 사이의 중복 파일 대통합

다시 WIM 파일과 그곳에 저장되는 이미지에 대해서 이야기를 해보도록 하겠습니다. 일단 WIM 파일에 포함되는 이미지는 중복 파일 통합을 기본으로 하고 있습니다. 즉, 두 개 이상의 완전히 동일한 파일이 있다면 이미지에는 실제로 하나의 파일만 저장한다는 것이죠.(메타 데이터는 따로 저장) 이러한 중복 파일 통합은 하드 링크된 파일들 뿐만 아니라, 일반 파일이더라도 완전히 동일한 파일이라면 통합하여 처리합니다. 실제로 그럴까요? 아래의 테스트를 보시죠.

T: 드라이브에 두 개의 완전히 동일한 파일을 별개의 폴더에 따로 준비하였습니다. 해당 파일들은 하드 링크된 파일이 아닙니다. 그래서 실제 디스크에서 해당 파일들이 차지하는 용량은 약 4GB 정도입니다. 이는 드라이브 속성을 통해서도 확인할 수 있습니다.

그리고 WIM 파일의 정확한 용량 확인을 위해 ImageX 를 통해 무압축으로 이미징하였습니다. 이미징 완료 후 XML 데이터의 용량 정보를 살펴보아도 총 데이터의 크기가 약 4GB 인 것을 확인할 수 있습니다. 더불어 하드 링크 데이터가 0 으로 나오므로 해당 파일들은 하드 링크된 파일도 아님을 알 수 있습니다. 그렇다면 이러한 파일들을 이미징하여 생성된 WIM 파일은 파일 전체 용량대로 4GB 일까요?

아뇨. 2GB 입니다. 왜냐하면, 두 파일은 완전히 동일한 파일이기 때문에 WIM 이미지 자체 내에서 통합하여 하나의 파일로 처리하였기 때문입니다. 이와 같이 이미지엔 하나의 파일로 통합하여 저장하였지만, 해당 이미지를 통해 복원을 진행하면 원래대로 두 개의 파일로 정상적으로 복원됩니다. 메타데이터는 따로 저장되어 있으니 두 개의 파일을 분리할 수 있기 때문이죠.

간단하죠? 이러한 이미지 내에서의 중복 파일 통합을 간단하게 그림으로 표현해보면 아래와 같습니다. 이 때 중복 파일은 단순히 파일 이름만 같은 것이 아니라 완전하게 동일한 파일을 의미합니다.

WIM 파일 내 이미지의 중복 파일 통합 처리

메타데이터(metadata) : 데이터에 관한 데이터. 어떠한 데이터에 대한 설명이나 정보를 담고 있는 데이터. 파일에서 메타데이터란 실제 파일(데이터)에 대한 정확한 위치, 속성, 소유자, 접근 권한 등 파일 시스템에 기록된 파일에 대한 정보(메타데이터)를 의미. [데이터 ← 메타데이터]

"쉽게 네가 사진을 찍었어. 이제 그 사진을 노트에 붙인 거야. 그리고 사진 밑에 '2012년 12월 25일 크리스마스에 명동에서 혼자 찍음!' 이렇게 적어 뒀어. 그럼 여기에서 노트는 저장 장치이고, 사진은 파일이고, '2012년 12월 25일 크리스마스에 명동에서 혼자 찍음!' 이란 설명은 메타데이터가 되는 거야. OK? 왜 혼자 찍었냐면, 난 커플은 용납 못하거든. -_-+"

그런데 중요한 것은 이러한 중복 파일의 통합이 비단 하나의 이미지 내에서만 적용되는 것이 아니라 WIM 파일에 존재하는 모든 이미지들 사이에서도 이루어진다는 것입니다. 이야기했듯이 하나의 WIM 파일에는 여러 개의 이미지를 저장할 수 있습니다. 만약에 현재 이미지 1 에 존재하는 파일이 역시나 이미지 2 에도 존재한다면, WIM 파일은 해당 파일을 각각의 이미지마다 따로 저장하는 게 아니라, 역시나 또 통합해서 하나로 처리합니다.

WIM 파일 내 각 이미지들간의 중복 파일 통합 처리

이처럼 WIM 이미지 포맷은 개별적인 이미지들 내부에서는 물론 이미지와 이미지 사이에서까지 그야말로 모든 중복 파일을 통합 처리합니다. 대통합이죠. 대통합이라... 대통합......

이것을 아주 쉽게 볼 수 있는 예제가 바로 윈도우 설치 DVD 에서 제공되는 Install.wim 파일입니다. Install.wim 파일은 하나의 WIM 파일 안에 여러 개의 윈도우 에디션 이미지를 가지고 있는 대표적인 WIM 파일이죠. 그런데 사실 윈도우는 에디션마다 실질적인 파일들은 거의 대부분 동일하기 때문에, 중복 파일 통합 처리 후 Install.wim 파일은 마치 하나의 에디션만을 담고 있는 것과 비슷한 파일 크기를 가지게 됩니다.

윈도우 7 32비트 설치 DVD 의 Install.wim 파일에는 아래와 같이 총 다섯 개의 에디션 이미지가 포함되어 있다. 이러한 이미지들은 각각 약 2GB 정도의 크기를 가지고 있다. 즉, 원래대로라면 Install.wim 파일은 총 10GB 정도의 데이터를 담고 있는 것이다.

하지만 각 에디션들마다 실제 파일의 구성은 거의 차이가 없다. 그리하여 앞서 설명한 것과 같이 각각의 이미지들에 존재하는 중복 파일들은 모두 하나로 통합 저장되고, 결국 Install.wim 파일은 각각 2GB 의 크기를 가진 총 10GB 에 달하는 다섯 개의 이미지를 포함하고 있음에도 불구하고, 최종적으로 약 2GB 의 파일 크기를 유지하는 것이다. 이것이 Install.wim 파일 용량의 비밀이며, 이게 WIM 이미지 포맷의 최대 강점이다.

어떤가요? 그리 어렵지는 않죠? 아무튼 WIM 파일의 이러한 중복 파일 통합은, 개별적인 이미지 안에서, 그리고 각각의 이미지들끼리도 종합적으로 처리하여, 개개의 이미지의 용량을 최적화하는 것은 물론, 여러 개의 비슷한 이미지를 하나의 WIM 파일에 보다 작은 용량으로 담을 수 있게 만들어 줍니다. 굉장히 효율적이죠.


그런데 잘 생각해보면 그림 설명에서도 이야기했지만 이러한 WIM 파일의 중복 파일 통합 과정을 거쳐 저장된 각 이미지들은 순서대로 마치 증분 백업을 진행한 것과 같이 저장되었다고도 볼 수 있습니다. 즉, 이미지 1 에 이어 이미지 2 를 추가로 저장하면, 각 이미지 사이의 중복 파일 통합 과정을 거쳐 최종적으로 이미지 2 에는 이미지 1 에 없는 새로운 파일들만 저장된다고도 볼 수 있기 때문이죠. 정리하면 이러한 WIM 포맷의 중복 파일 통합의 결과를 논리적으로 비틀어 다른 시각으로 보면 WIM 파일 자체 내에서 증분 백업을 구현하고 있다고도 볼 수 있는 겁니다. 이제 첫 번째 이미지는 기준 백업본이 되고, 이후의 이미지들은 증분 백업본이 되는 것이죠.

그럼 결론을 이야기해볼까요? 하나의 WIM 파일에 새 이미지를 추가하는 방식을 통해 동일한 윈도우를 연속적으로 백업하면 증분 백업을 한 것과 같은 효과를 얻을 수 있습니다. 그것도 관리하기 불편하게 여러 파일로 흩어지지 않고, 오직 하나의 WIM 파일로 구현할 수 있죠. 즉, 하나의 WIM 파일이 하나의 증분 백업 세트가 되는 겁니다.



3. 기존 WIM 파일에 새로운 이미지를 저장하는 것은?

앞서 /Capture 명령을 통해 새로운 WIM 파일을 생성했습니다. 백업이라는 관점에서 본다면 이것은 전체 백업 또는 증분 백업 세트에서 기준 백업이라고 할 수 있습니다. 이미 존재하는 WIM 파일에 추가로 새로운 이미지를 저장하는 것은 이제부터 알아 볼 /Append 명령이 담당합니다. 백업이라는 관점에서 본다면 이것은 증분 백업이 되는 겁니다.

즉, 매번 /Capture 를 통해 새로운 WIM 파일로 백업을 진행하면 그것은 매번 전체 백업을 진행하는 것과 같고, /Capture 후 /Append 로 하나의 WIM 파일에 새 이미지를 계속 추가하는 방식으로 백업을 진행하면, 그것은 증분 백업을 진행하는 것과 같은 효과를 얻을 수 있는 것이죠. 무슨 의미인지 대충 이해하시겠죠?

저는 이것을 ImageX 를 통한 데이터 백업의 굉장히 큰 장점이자 매력 중에 하나로 보고 있는데, 여러분은 이것을 어떻게 받아들이실련지 모르겠네요. 이게 요즘 제가 고스트 대신 ImageX 를 주로 사용하는 가장 큰 이유 중에 하나입니다. 물론 고스트도 잘 사용하고 있습니다. 그럼 계속가죠.

ImageX 를 통해 기존 WIM 파일에 새 이미지 저장하기(증분 백업하기) - /Append

끊어야 할 타이밍을 놓쳐서 이 글을 크리스마스를 넘어서 26 일에도 여전히 작성하고 있네요. 원래는 이브에 작성을 시작해서 크리스마스에 짜잔! 하고 공개하려고 했는데 말이죠. 분량 조절 실패입니다. 그런데 더 열받는 건 뭔지 아세요? 지금 전체적인 틀이 안 맞아서 앞서의 몇몇 내용들과 이 단락 이후를 한 번 뒤집어 엎었고, 다시 27일이 되었습니다. 기왕 이렇게 된거 이번 글에서 백업과 복원이라는 관점에서 ImageX 를 아주 영혼까지 탈탈 털어 보죠.

"나는야 근성의 영혼 탈곡기! 그런데 어째 내 영혼이 먼저 털릴 것 같다... 헛소리하는 거 보니 이미 좀 털린 듯..."



1. /Appned 명령의 형식 및 옵션의 이해

앞서 /Capture 명령을 통해 새로운 WIM 백업 파일을 생성하였습니다. 최초의 WIM 파일 생성(이미징)은 /Capture 명령을 통해 진행하게 되고, 이제 이렇게 생성된 WIM 파일에 새로운 이미지를 추가로 저장하려면 이후부터는 /Append 명령을 사용하면 됩니다. /Append 명령의 기본적인 사용법은 아래와 같습니다.

imagex /Append {원본 드라이브} {기존 WIM 파일} {"이미지 이름"}

ex) imagex /Append D: E:\Backup.wim "Drive-D 2st"

기본적인 명령의 구조는 /Capture 명령과 동일합니다. 이 때 반드시 주의할 것이 있는데 이미지 이름은 WIM 파일의 다른 이미지들에 저장했던 이름과는 반드시 다르게 지정해야 한다는 겁니다. 이것만 기억하시면 되겠네요. 그리고 /Append 명령에서는 /Compress 압축률을 지정하지 않습니다. /Append 명령에서 이미지의 압축률은 자동으로 해당 WIM 파일에 설정된 압축률을 [최초에 /Capture 명령에서 지정했던 압축률을] 따라갑니다.

다음으로 아래는 /Append 명령의 전체 명령 구성입니다. /Capture 와 동일하니 따로 각 옵션들에 대한 설명은 하지 않겠습니다.

imagex /Capture {원본 드라이브} {저장할 WIM 파일} {"이미지 이름"} ["이미지 설명"] [/Boot] [/Check] [/Config] [/Scroll] [/Verify]

2. 기존 WIM 파일에 새로운 이미지 저장하기 - 증분 백업하기

앞서 미리 백업해둔 WIM 파일(이미지를 한 개 포함하고 있음).

기존의 파일들에 더해 새롭게 [Data 2] 폴더 데이터를 추가한 D: 드라이브의 모습.

이처럼 앞서 미리 백업해 둔 E:\Backup.wim 파일에 /Append 명령을 통해 연속하여 새로운 이미지를 저장해보도록 하겠습니다. 마찬가지로 동일한 D: 드라이브를 백업할 것입니다. D: 드라이브엔 첫 번째 백업할 당시에는 약 520MB 정도의 파일들이 있었고, 그 때와 비교하여 약 380MB 정도의 새로운 파일들이 더 추가가 된 상태입니다. 그래서 현재는 도합 900MB 정도의 파일이 들어 있습니다.

명령은 아래와 같으며 /Appned 명령에선 기존의 다른 이미지들과 반드시 이미지 이름을 다르게 지정해야 한다는 것을 잊지 마세요.

imagex /Append D: E:\Backup.wim "Drive-D 2nd" /Verify

어떤가요? 현재 Backup.wim 파일엔 두 개의 백업 이미지가 포함되어 있습니다. 그리고 백업 상황을 요약해보자면 아래와 같습니다.

첫 번째 /Capture 백업 당시 데이터 양 : 약 520MB
두 번째 /Append 백업 당시 데이터 양 : 약 900MB (새로운 데이터 약 380MB)

첫 번째 백업 후 WIM 파일 크기 : 약 500MB (Fast 압축)
두 번째 백업 후 WIM 파일 크기 : 약 876MB (Fast 압축)

만일 이것을 전체 백업으로 진행했다면, 그러니까 /Capture 를 통해 각각의 WIM 파일로 저장했다면, 아래 이미지의 Backup-1st.wim 과 Backup-2nd.wim 같이 나왔을 것입니다. [참고로 실수로 데이터가 날아가서 다시 처음부터 백업했습니다.]

Backup-1st.wim 과 Backup-2nd.wim 은 각각 해당 시점에 /Capture 를 통해 전체 백업한 것.
Backup.wim 은 글에서와 같이 각각의 시점에서 /Capture 로 백업한 후 /Append 로 추가 백업 한 것.

설명하자면 Backup-1st.wim 파일은 첫 번째 시점에서 /Capture 로 전체 백업한 것이고, Backup-2nd.wim 파일은 두 번째 시점에서 마찬가지로 /Capture 로 전체 백업을 진행한 것입니다. 고로 각각의 WIM 파일에는 하나의 이미지만 저장되어 있고, 해당 시점의 전체 데이터를 가지고 있기 때문에 백업 파일의 전체 용량은 그만큼 많이 나오게 됩니다.

하지만 Backup.wim 파일은 글에서와 같이 백업한 파일로, 첫 번째 시점에서 /Capture 명령을 통해 전체 백업한 후, 두 번째 시점에서 /Append 를 통해 추가 백업을 한 것입니다. 고로 현재 Backup.wim 파일에는 첫 번째 시점과 두 번째 시점에 해당하는 두 개의 이미지가 순서대로 저장되어 있습니다. 이는 뒤에서 더 자세하게 알아 볼 /Info 명령을 통해서도 확인할 수 있습니다. /Info 명령은 WIM 파일에 존재하는 이미지들에 대한 XML 데이터 정보를 확인하는 명령입니다.

앞서 설명할 때 이미지 이름은 XML 데이터에서 <NAME> 필드에 저장된다고 했죠? 그래서 아래는 Findstr 명령과 결합시켜서 <NAME> 부분만 따로 출력해본 모습입니다. [XML 정보가 워낙에 많아서 확인이 좀 어려운 감이 있어서 이렇게 했습니다.]

현재 E:\Backup.wim 파일에는 "Drive-D 1st" 와 "Drive-D 2nd" 두 개의 이미지가 존재하고 있다.
참고로 순서대로 이미지 인덱스 1 과 이미지 인덱스 2 이다.

정확하게 두 개의 이미지가 포함되어 있는 것을 확인할 수 있죠. 하지만 WIM 파일의 용량은 앞서의 단락에서 설명한 중복 파일 최적화를 통해, 마치 두 번째 시점의 백업만 진행한 것과 비슷한 용량을 가지게 된 겁니다. 이게 제가 그렇게 설명했던 증분 백업 효과이고, ImageX 를 통한 WIM 백업의 가장 큰 장점이 아닐까 생각합니다.

참고로 해당 WIM 파일에는 앞으로도 동일하게 /Append 명령으로 새로운 이미지를 계속하여 추가 저장할 수 있습니다. 즉, WIM 파일 하나로 여타 이미징 백업/복원 프로그램들의 증분 백업 세트를 구현할 수 있는 것이죠.

참고로 WIM 파일에는 /Append 명령을 통해 이미지를 추가만 할 수 있는 게 아닙니다. 뒤에서 알아 볼 /Delete 명령을 통해 WIM 파일에 포함된 이미지 중 원하는 이미지를 삭제할 수도 있죠. 하지만 이렇게 어떠한 이미지를 삭제하여도 해당 이미지가 포함하고 있던 크기 만큼 다시 WIM 파일의 크기가 줄어들진 않습니다. 마치 동적 확장 방식의 VHD 파일이 한 번 크기가 늘어나면 다시 줄어들지 않는 것과 비슷하죠.

문제는 ImageX 에는 이를 자동으로 최적화할 수 있는 명령도 없다는 겁니다. 하지만 WIM 파일에서 이미지를 추출 저장하는 /Export 라는 명령을 통해 이미지를 새로이 재구성하는 방법을 통해 수동으로 최적화를 해줄 수 있습니다. 그런 건 뒤에서 더 이야기하도록 하죠.

여러 개의 이미지를 포함하고 있는 WIM 파일을 통해 원하는 시점으로 복원하기

그러니까 현재 글에서 알아보고 있는 예제인 E:\Backup.wim 파일에는 두 개의 시점에 해당하는 데이터가 백업되어 있습니다. 각각의 시점은 각각의 이미지로 분리가 되어 있죠. 그래서 해당 WIM 파일에 저장된 이미지들 중에 원하는 이미지로(원하는 시점으로) 복원을 원한다면 해당 이미지에 해당하는 이미지 인덱스를 통해 /Apply 복원을 진행하면 됩니다.

참고로 하나의 WIM 파일에 이미지를 여러 개 추가하여 사용하다 보면 몇 번째 이미지가 자신이 복원을 원하는 이미지인지 그 이미지 인덱스 번호가 헷갈릴 수 있습니다. 그래서 만약에 헷갈린다면 /Info 명령을 통해 해당 WIM 파일에 포함된 이미지들을 확인하는 것이 좋습니다. /Info 명령을 통해 출력되는 정보들은 굉장히 많기 때문에 따로 보기가 힘이 듭니다. 그러니 아래의 명령은 그냥 외워두세요.

imagex /Info E:\Backup.wim | findstr /i ^<name^>

해당 명령은 ImageX /Info 명령으로 출력된 결과 중 <NAME> 부분만 따로 추려서 보여주는 명령입니다. 참고로 < > 는 명령 프롬프트에서 리디렉션 명령이기 때문에 ^ 를 붙여줘야 리디렉션이 아닌 문자로 인식하게 됩니다. 그 점은 참고하셔서 명령을 보시고요. 아무튼, 위와 같이 명령을 내리면 스크린 샷과 같이 순서대로 /Capture 와 /Append 명령으로 캡쳐할 당시 입력했던 이미지 이름이 출력됩니다. 이 순서대로 이미지 인덱스 번호가 나가게 됩니다. [그래서 백업할 때는 이름을 잘 입력하셔야 나중에 확인이 용이 합니다. 참고로 이미지 이름은 한글로 지정할 수도 있지만, Find 나 Findstr 과정에서 한글이 깨져버립니다. DISM 을 통해 확인하면 되지만 ImageX 만을 사용할 것이라면 가급적 영문으로만 이미지 이름을 지정하시길 권장합니다.]

그럼 각각의 이미지로 복원을 진행해보도록 하겠습니다. 정확한 비교를 위해 복원 전 드라이브를 포맷하는 과정을 추가하였습니다.


A. 첫 번째 이미지로 복원 - 이미지 인덱스 1

diskpart

select volume=D
format fs=ntfs quick label="Data"
exit

imagex /Apply E:\Backup.wim 1 D:

B. 두 번째 이미지로 복원 - 이미지 인덱스 2

diskpart

select volume=D
format fs=ntfs quick label="Data"
exit

imagex /Apply E:\Backup.wim 2 D:

WIM 파일과 이미지의 정보 확인하기 - /Info

1. /Info 명령의 기본 사용법

이제부터는 WIM 파일과 그 안에 포함된 이미지들을 관리하는 방법에 대해서 알아보게 될텐데요. 그 전에 먼저 정확하게 해당 WIM 파일에 어떤 이미지들이 저장되어 있고, 해당 이미지들은 어떠한 것인지 정확하게 알아야겠죠?

이처럼 WIM 파일에 포함된 이미지들의 정보를 확인하는 것은 /Info 명령이 담당하게 됩니다. 아래와 같이 WIM 파일을 지정하면 해당 WIM 파일에 포함되어 있는 모든 이미지들에 대한 XML 데이터를 출력해줍니다.

imagex /Info E:\Backup.wim

아래와 같이 명령에 인덱스 번호를 지정하면 해당 이미지의 정보만 출력해줍니다.

imagex /Info E:\Backup.wim 2

2. WIM 이미지의 XML 데이터 이해하기

그럼 이렇게 출력된 XML 데이터들은 무엇을 의미하는지도 알아야겠죠? 모든 걸 알아볼 필요는 없고, 백업과 복원에서 중요한 정보만을 선택하여 알아보도록 하겠습니다. 일단 이 글의 최종 목표는 윈도우 백업이기 때문에 제가 미리 윈도우 8 을 백업한 WIM 파일로 바꾸도록 하겠습니다. 해당 WIM 파일 중 두 번째 이미지의 정보는 아래와 같습니다. [참고로 해당 XML 데이터는 순수하게 백업의 용도로 작성한 것이기 때문에 배포용으로 제작된 이미지의 XML 데이터와 비교하여 몇 가지 정보들이 없습니다.]

A. 이미지 인덱스 정보

XML 데이터의 가장 처음에 출력되는. <IMAGE INDEX="X"> 의 X 가 바로 해당 이미지의 인덱스 번호입니다. 현재 WIM 파일에 존재하는(저장된) 이미지들의 순서에 따라 차례로 1 부터 연속된 번호로 매겨집니다. 참고로 미리 말하지만 /Delete 명령을 통해 중간의 이미지를 삭제하게 되면 그 뒤의 이미지들은 인덱스 번호가 하나씩 당겨지게 됩니다. 즉, 인덱스 번호는 해당 이미지에 고유하게 부여된 값이 아니라, 그냥 현재 WIM 파일에 존재하는 이미지들의 순서를 의미하는 겁니다.


B. 파일 관련 정보의 이해

주요하게 살펴볼 항목들은 제가 위에서 박스를 쳐놨으면 세 가지 범주로 나눠서 살펴보도록 하겠습니다. 먼저 이미지에 포함된 파일들에 대한 정보입니다.

BBCode	출력 결과
<DIRCOUNT>	해당 이미지에 포함된 전체 폴더의 개수.
<FILECOUNT>	해당 이미지에 포함된 전체 파일의 개수.
<TOTALBYTES>	해당 이미지에 포함된 전체 파일들의 총 용량.
<HARDLINKBYTES>	해당 이미지에 포함된 파일들 중 하드 링크 파일들의 용량.

일단 DirCount 와 FileCount 는 따로 설명할 필요가 없겠죠? 하지만 TotalBytes 와 HardLinkBytes 는 좀 설명이 필요합니다. 일단 하드 링크 파일에 대해서 이해가 필요한데요. 하드 링크란, NTFS 파일 시스템에서 하나의 실제 파일에 두 개 이상의 각기 다른 이름과 경로로 링크 연결된 파일이 존재하는 상태를 의미합니다. 흐음... 이것도 설명하려면 글 한 편이 나와야 하는데... 그림으로 설명하면 아주 간단한데 이젠 그림 그리기가 귀찮네요. 그제 어제 오늘 너무 많이 그렸어요. 지금 영혼조차 피곤해질려고 해요. 징글징글하니 이젠 그냥 말로 설명할께요. 제 원래 주특기가 고급스럽게 말로 털어주는 나불거림이니까요.


원래 전통적으로(기본적으로) 윈도우에서 우리 눈에 보이는 어떠한 파일은 디스크 상의 실제 파일과 1:1 로 연결이 됩니다. 즉, 우리가 윈도우에서 보는 파일들은 모두 디스크에도 각각 그에 맞는 실제 파일이 존재하고 있는 게 기본이자 일반적인 모습이란 거죠.

자 여기서부터 일단 개념을 잘 잡으세요. 우리가 윈도우에서 보는 파일들은 디스크에 위치한 실제 파일을 보고 있는 게 아니라 해당 파일에 대한 파일 시스템의 (메타데이터) 링크를 보고 있는 겁니다. 우리가 윈도우에서 파일을 열면 이제 링크를 통해 그 파일에 연결된 디스크 상의 실제 파일에 접근을 하는 것이죠. 이러한 실제 파일의 위치는 메타데이터에 기록되어 있고요. 이해되시나요?

그런데 NTFS 파일 시스템에서는 하나의 실제 파일에 각기 다른 경로와 이름으로 여러 개의 링크를 만드는 게 가능합니다. [다르게 표현하자면 여러 개의 다른 메타데이터를 하나의 실제 파일에 연결시키는 게 가능] 이렇게 처리가 되면 윈도우에서 보면 분명 별개의 서로 다른 파일인데, 실제론 이야기한 것과 같이 하나의 파일인 것이죠.

그러니까 만약에 $File.exe 라는 실제 파일이 있다면, 여기에 \Temp\CApple.exe 도 연결시키고, \Data\Test.exe 라는 파일도 연결시키는 겁니다. 즉, 우리가 윈도우에서 보기엔 \Temp\CApple.exe 와 \Data\Test.exe 라는 전혀 별개의 파일이지만, 실제로 디스크엔 $File.exe 하나만 존재하고 있는 겁니다. 이해 되시나요?


전통적이고 기본적인 단일 링크 파일 구조

$File.exe [디스크의 실제 파일]
\Temp\CApple.exe → $File.exe [하나의 실제 파일엔 하나의 파일 링크만 존재]

NTFS 파일 시스템에서 하드 링크로 처리된 다중 링크 파일 구조

$File.exe [디스크의 실제 파일]
\Temp\CApple.exe → $File.exe ← \Data\Test.exe [하나의 실제 파일에 여러 개의 파일 링크가 존재]

이게 바로 하드 링크입니다. 만약 $File.exe 의 용량이 100MB 이고, 여기에 두 개의 하드 링크가 존재한다면 윈도우 탐색기에서 살펴보면 200MB 로 표시되지만, 디스크 관리와 같은 디스크 유틸을 통해 디스크의 용량을 직접 살펴보면 100MB 라 나오게 됩니다. 이해하시겠죠? 이번 글의 WIM 이미지의 중복 파일 통합에서 하나의 파일에 여러 개의 메타데이터를 연결시켜서 파일을 통합했었죠. 그걸 NTFS 에선 파일 시스템 차원에서 지원을 합니다. NTFS 의 하드 링크나 WIM 포맷의 중복 파일 통합이나 어차피 같은 개념입니다.

그럼 여기에서 잠시 문제! 위의 설명에 등장한 \Temp\CApple.exe 와 \Data\Test.exe 중에서 어떤 게 원래 파일이고, 어떤 게 추가로 하드 링크된 파일일까요? 정답은 알 수 없습니다. ^^ 그리고 예전에 제가 파일 삭제 글에서 윈도우에서 파일을 삭제하는 것은 실제 파일은 그대로 두고 해당 파일과 연결된 파일 시스템상의 링크만 끊는다는 표현을 했죠? 그 링크가 이 링크이고 그게 메타데이터입니다.


그럼 다시 /Info 명령을 통해 살펴본 이미지의 정보로 이야기를 돌리도록 하겠습니다. TotalBytes 란 이러한 하드 링크로 존재하는 중복 파일 처리를 무시하고, 그냥 순수하게 모든 포함된 파일의 용량을 더한 값입니다. 즉, 하나의 실제 파일에 두 개의 하드 링크가 연결되어 있는 파일이 백업되어 있다면, TotalBytes 에서는 두 개 파일분의 용량을 모두 표시해주는 겁니다.

HardLinkBytes 는 전체 파일들 중에서 하드 링크된 파일들만의 총 용량을 의미합니다.

그래서 해당 이미지에 포함되어 있는 실제 파일의 총 용량은 [TotalBytes - HardLinkBytes] 가 됩니다. 실제로 해당 이미지를 드라이브에 해제해주면 [TotalBytes - HardLinkBytes] 만큼의 용량이 나오게 됩니다. 그럼 위의 윈도우 8 을 백업한 2 번 이미지의 TotalBytes 와 HardLinkBytes 를 살펴볼까요?

TotalBytes     : 10,764,952,431 Byte [10.02 GB]
HardLinkBytes  :  3,114,895,657 Byte  [2.90 GB]
실제 파일 용량 :  7,650,056,774 Byte  [7.12 GB]

정말로 그렇게 나올까요? 해당 이미지를 NTFS 로 포맷된 빈 드라이브에 풀어 보았습니다.

약간의 차이는 있지만 우리가 이미지 정보를 통해 계산한 값과 거의 비슷하게 나오죠? 참고로 계산한 용량보다 실제 용량이 조금 더 많이 나오는 것은, 일단 클러스터 크기에 따라 그보다 작은 파일들은, 디스크에서 실제 파일 용량보다 조금 더 많은 공간을 차지하죠. 여기에 더해 NTFS 의 MFT(메타데이터) 영역도 용량을 차지하죠. 이러한 추가적인 것들로 인해 우리가 ImageX 의 정보를 통해 계산한 실제 데이터의 용량보다는 원래 조금 더 나오게 되고 이게 정상입니다. 그 차이가 심각하게 크지만 않으면 됩니다.

그런데 윈도우에 의외로 하드 링크 처리된 파일이 많죠? 윈도우의 WinSxS 폴더에 대해서 검색해보세요. 해당 폴더는 윈도우의 시스템 파일들 중 하드 링크된 파일들을 모아놓은 폴더입니다. 윈도우 업데이트와 버전 관리에서 활용되죠. 그냥 참고하시라고요. 오늘 참 하나의 글에서 여러 가지 이야기를 하네요.


참고로 여기에서 추가로 알아두셔야 할 게 있습니다. WIM 포맷을 통한 백업과 복원의 장점 중에 하나가 바로 파일 시스템을 넘나들어 복원이 가능하다는 것이었죠. 그런데 하드 링크는 윈도우에서 사용하는 파일 시스템 중엔 NTFS 파일 시스템만 지원을 하는 기능입니다. FAT32 파일 시스템은 하드 링크를 지원하지 않습니다. 35년 전인 1977 년에 처음 공개되어 아직까지도 질기게 목숨을 연장하고 있는 FAT 기반 파일 시스템에 뭘 더 바라시나요? 아무튼, 그래서 이와 같은 하드 링크 데이터가 포함된 이미지는 FAT32 파일 시스템을 가진 드라이브에는 해제할 수 없습니다. 만약에 해제를 시도하면 아래와 같이 오류가 발생하게 됩니다.

이런 식으로의 시도는 잘 하지 않겠지만 그래도 알아두셔서 나쁠 것은 없죠. 이야기했던 WinSxS 폴더에서 오류가 났네요. 쓸데없는 것 같지만 그래도 주로 관련된 이야기로 주절거립니다.


C. 윈도우 버전 관련 정보

이것은 이미지에 윈도우가 포함되어 있을 때에만 출력되는 정보입니다.

BBCode	출력 결과
<EDITIONID>	포함된 윈도우의 에디션 아이디.
<VERSION>	포함된 윈도우의 버전 정보.

Version 항목에서는 메이저, 마이너, 빌드, 리비전을 모두 확인할 수 있습니다. 참고로 ImageX 가 윈도우 비스타의 AIK 부터 포함되어 나오긴 했지만 윈도우 XP 를 백업해도 마찬가지로 이러한 버전과 에디션 정보를 확인할 수 있습니다. 뭐 그냥 그렇다고요. 윈도우 버전에 대한 간략한 정보는 아래와 같으며 보다 자세한 내용은 링크 글에 설명되어 있습니다.

현재 사용 중인 윈도우의 버전 확인하기 - 윈도우 버전의 이해, 빌드 넘버 확인

6.2.9200.16384 = 메이저.마이너.빌드.리비전

5.0.xxxx : 윈도우 2000
5.1.xxxx : 윈도우 XP
5.2.xxxx : 윈도우 서버 2003
6.0.xxxx : 윈도우 비스타 (윈도우 서버 2008)
6.1.xxxx : 윈도우 7 (윈도우 서버 2008 R2)
6.2.xxxx : 윈도우 8 (윈도우 서버 2012)

D. 이미지 자체 정보

이것은 이미지 자체에 대한 정보입니다.

BBCode	출력 결과
<NAME>	이미지 이름. 백업(이미징) 당시 사용자가 지정한 값입니다.
<DESCRIPTION>	이미지 설명. 백업(이미징) 당시 사용자가 지정한 값입니다. 없을 수도 있습니다.

/Capture 와 /Append 에서 지겹게 이야기한 이미지 이름과 이미지 설명입니다. 여기에선 딱히 따로 더 설명드릴게 없네요.


WIM 에 포함된 이미지의 XML 데이터에 대해서는 대충 이정도만 알고 계시면 될 듯 합니다. 그 외의 정보들은 백업과 복원에서는 크게 의미가 없습니다. 다음으로 넘어 가죠.

WIM 파일에서 특정 이미지 삭제하기 및 추출을 통해 최적화하기 - /Delete /Export

1. WIM 파일에서 원하는 이미지를 선택하여 삭제하기

테스트용 이미지

/Append 명령을 통해 하나의 WIM 이미지에 여러 개의 이미지를 연속하여 저장하였습니다. 그런데 그 중에 어떠한 이미지는 더이상 필요치 않다면 /Delete 명령을 통해 원하는 이미지를 삭제할 수 있습니다. 보다 정확한 설명을 위해 E:\Backup.wim 파일에 한 번 더 백업을 진행하였습니다. 보시는 것과 같이 해당 파일에는 현재 총 세 개의 이미지가 존재하고 있죠.

그러면 이 중에서 두 번째 이미지를 삭제해보도록 하겠습니다. 명령은 아래와 같습니다.

imagex /Delete E:\Backup.wim 2

명령 자체에선 더이상 설명할 게 없습니다. 그런데 앞서 이미지 인덱스 번호에 대해서 이야기할 때 인덱스 번호는 고정된 값이 아니라고 했습니다. 인덱스 번호는 단순히 현재 WIM 파일에 존재하는 이미지들의 순서일 뿐이죠. 그래서 중간에 이미지를 삭제하게 되면 그 뒤의 이미지들은 자동적으로 인덱스 번호가 하나씩 당겨지게 됩니다. 아래와 같이 말이죠.

만약에 첫 번째 이미지를 삭제하면 모든 이미지의 인덱스 번호가 하나씩 당겨지겠죠? 뭐 그렇습니다. 간단하죠? 아~ 참고로 혹시나 하여 이야기하는데, 이번 글에서는 WIM 파일을 증분 백업의 백업 세트라는 개념으로 놓고 주로 설명을 했습니다. 그래서 혹시나 기준 백업에 해당하는 첫 번째 이미지를 삭제할 수 없는 것 아닌가 생각하실지 모를텐데요. 그것은 아닙니다.

제가 설명마다 항상 이야기했는데요. WIM 파일에서의 증분 백업 개념은 말 그대로 그냥 다른 시각에서 바라 본 논리적인 개념입니다. 실제로 WIM 이미지가 증분 백업을 하는 것은 아니고요. 중복 파일 통합 등의 결과를, 이제 논리적으로 다른 시각에서 보자면 마치 증분 백업과 비슷하다 것이죠. 그래서 여태 설명할 때 그런 효과를 얻을 수 있다는 표현을 사용한 겁니다.

첫 번째 이미지든 중간에 있는 이미지든 마지막 이미지든 /Delete 명령을 통해서 가리지 않고 삭제할 수 있습니다. 혹시나 지금까지의 제 설명을 곡해하여 이해하셨을까 봐 마지막으로 한 번 더 짚어 봤습니다. 아무튼, /Delete 명령에서 중요한 것은 이게 아닙니다.



2. /Export 추출 명령을 통해 WIM 파일 용량 최적화하기

글에서 계속 사용하고 있는 E:\Backup.wim 예제 파일에는 현재 두 개의 이미지가 남아 있습니다. 이제 여기에서 다시 한 번 마지막 이미지도 삭제하였습니다. [과정은 생략하겠습니다.] 그 결과 현재 이미지에는 최초에 작성했던 이미지 하나만 남아 있습니다. 그리고 해당 이미지의 크기는 약 500MB 정도입니다. 그렇다면 이제 WIM 파일에는 해당 이미지 하나밖에 존재하지 않기 때문에 해당 이미지의 용량대로 WIM 파일도 500MB 정도로 줄어들었을까요?

최초에 백업했던 하나의 이미지만 남겨 놓고 나머지 다른 이미지는 모두 삭제한 모습. WIM 파일의 용량은 줄어들지 않는다.

아뇨. /Delete 를 통해 이미지를 삭제하여도 WIM 파일의 용량은 줄어들지 않습니다. 즉, /Delete 명령은 단순히 이미지를 삭제만 할 뿐, WIM 파일의 용량을 최적화해주진 않습니다. 이게 WIM 포맷의 가장 큰 문제입니다. 그리고 이를 곧바로 최적화할 수 있는 명령도 존재하지 않습니다. 이것도 좀 문제죠.


하지만 그렇다고 최적화가 아예 불가능한 것은 아닙니다. ImageX 에는 /Export 라는 WIM 파일에서 원하는 이미지만 따로 다른 WIM 파일로 추출하여 저장할 수 있는 명령이 있습니다. 이를 통해 어떠한 WIM 파일의 이미지를 다른 WIM 파일로 옮길 수도 있고, 또는 원하는 이미지를 따로 하나의 WIM 파일로 빼내는 것도 가능합니다.

그럼 실제로 작업을 진행해보도록 하겠습니다. 다음은 /Export 명령을 통해 E:\Backup.wim 의 첫 번째 이미지를 따로 E:\Test.wim 라는 새로운 WIM 파일로 빼내는 작업입니다.

imagex /Export E:\Backup.wim 1 E:\Test.wim

그러면 이와 같이 해당 이미지만 따로 빼낸 새로운 WIM 파일이 생성됩니다. 이제 기존의 Backup.wim 파일은 지워버리고, 새로 생성한 Test.wim 파일은 그대로 사용하거나 또는 Backup.wim 파일로 바꿔서 사용하면 되겠죠? 참고로 /Export 의 대상으로 이미 존재하는 WIM 파일을 지정하게 되면 해당 WIM 파일에 새로 이미지를 추가하게 됩니다. 즉,

/Export 대상으로 새로운 WIM 파일 지정 : 해당 WIM 파일을 생성하고 해당 이미지를 추가, /Capture 와 동일
/Export 대상으로 기존의 WIM 파일 지정 : 기존 WIM 파일에 연속하여 해당 이미지를 추가, /Append 와 동일

이와 같은 것이죠. 간단하죠?

참고로 쓸데없는 이야기를 좀 더 하자면 통합 윈도우 설치 DVD 많이들 제작하죠? 통합 윈도우 설치 DVD 를 제작할 때는 이와 같이 /Export 로 원하는 윈도우 에디션 이미지들을 차례차례 새로운 Install.wim 로 추출하고, 이렇게 만든 Install.wim 파일로 윈도우 설치 DVD 의 Install.wim 파일을 교체해주는 게 기본입니다. 이제 여기에 더해 이번 글에서는 알아보지 않았지만 DisplayName 이라던지 DisplayDescription, Flag 등의 정보를 필요하다면 수정해주는 거죠. 그 외에도 몇 가지 내용을 더 알아야 하는 경우도 있지만 일단 통합 윈도우 설치 DVD 제작의 기본은 지금 알아 본 /Export 입니다. 참고하세요.

그럼 다음으로 넘어가도록 하죠.

이미지를 확인하거나 수정이 필요할 때 이미지를 폴더에 탑재하기 - /Mount /Mountrw

이건 정확하게 윈도우의 백업과 복원보다는 윈도우 PE 용 이미지 제작에서 주로 사용되는 기능입니다. 그래도 백업과 복원에서 따로 복원하지 않고 파일을 확인하거나 추출할 수도 있고, 간단한 파일들은 추가할 수도 있으니 알아보도록 하겠습니다.

참고로 지금 알아보려는 이미지 탑재 기능은 NTFS 파일 시스템에 위치한 폴더에만 탑재할 수 있으며, 윈도우 비스타, 7, 8 에서는 ImageX 만을 통해서도 가능하지만 윈도우 XP 에서는 반드시 WAIK 또는 WADK 를 설치해야만 사용할 수 있습니다.

[윈도우 XP] ImageX.exe - 마운트 관련 명령의 실패 원인


WIM 파일의 이미지는 읽기 전용 또는 읽기 쓰기 가능 중에 원하는 속성으로 탑재할 수 있습니다. 읽기 전용으로 탑재하려면 /Mount 를, 읽기 쓰기 가능으로 탑재하려면 /Mountrw 명령을 사용하면 됩니다. 단순히 파일을 확인하거나 추출하려면 /Mount 으로 탑재하고, 이미지에 어떠한 파일을 추가하거나 삭제하는 등의 수정 작업을 하려면 /Mountrw 로 탑재하면 됩니다. 참고로 둘의 명령 구성은 동일합니다. 즉, /Mount 냐 /Mountrw 냐의 차이만 있을 뿐 나머지 옵션은 모두 동일하다는 것이죠.

작업에 앞서 탑재 작업에선 해당 이미지를 탑재할 폴더를 지정해주게 되는데 이 때 해당 폴더는 반드시 비어 있어야 합니다. 그럼 실제로 이미지 탑재 작업을 해보죠. E:\Backup.wim 파일의 첫 번째 이미지를 E:\Mount 폴더에 읽기 쓰기 가능으로 탑재해보도록 하겠습니다. 읽기 쓰기 가능이기 때문에 /Mountrw 를 사용하며 명령은 아래와 같습니다.

imagex /Mountrw E:\Backup.wim 1 E:\Mount

탑재를 완료하면 지정한 폴더에서 해당 이미지에 포함된 파일들을 확인할 수 있으며, 일반적인 파일과 폴더들을 다루듯이 그대로 사용하시면 됩니다. 필요한 파일이 있다면 복사하시고, /Mountrw 로 탑재하였다면 파일을 추가로 저장하거나 삭제, 수정 등 일반적인 드라이브에서 하던 작업이 모두 가능합니다. 아무튼 알아서 지지고 볶으시고요.


이제 모든 작업을 마쳤으면 탑재된 이미지를 폴더에서 탑재 해제해야 합니다. 이미지의 탑재 해제는 /Unmount 명령이 담당합니다. 참고로 /Mountrw 로 탑재한 경우에는 두 가지 경우가 있습니다. 변경한 내용을 이미지에 적용(저장)할 것이라면 /Commit 옵션을 추가하고, 변경한 내용을 취소하고 이미지를 원래대로 되돌리려면 /Commit 옵션 없이 해제하면 됩니다. /Commit 없이 해제하면 모든 수정 작업이 취소되는 겁니다. /Mount 를 통해 읽기 전용으로 탑재했었다면 /Commit 없이 해제하시면 됩니다.

이미지 탑재 해제는 이미지 파일이 아닌 탑재했던 폴더를 대상으로 명령을 내려줍니다. 즉, E:\Mount 폴더에 탑재를 했으니 해당 폴더를 지정해주는 것이죠. 이 때 주의해야 할 것이 탑재 해제하려는 E:\Mount 폴더와 관련된 모든 윈도우 탐색기 및 연결된 프로그램은 탑재 해제 전 미리 종료를 하셔야 합니다. 안 그러면 탑재 명령이 실패하게 됩니다.

imagex /Unmount E:\Mount /Commit

이미지의 탑재 해제가 정상적으로 완료되면 위와 같이 탑재에 사용되었던 폴더가 원래의 빈 폴더로 되돌아가게 됩니다.

만약에 여기에 어떠한 파일이 남아 있다면 그건 이미지의 탑재 해제가 정상적으로 완료된 것이 아닙니다. 이는 해당 폴더와 관련된 윈도우 탐색기를 열어 두었거나 어떠한 파일을 열어둔 채로 탑재 해제하여 발생한 현상입니다. 이럴 땐 해당 윈도우 탐색기 및 열린 프로그램들을 모두 종료한 후 다시 /Unmount 명령을 내리면 됩니다. 단! 이 때는 /Commit 옵션 없이 작업해야 합니다.

이미지의 폴더 탑재와 탑재 해제는 이 정도면 될 것 같네요. 뭐 딱히 더 설명할 것도 사실 없고요. 그럼 다음으로 넘어가도록 하겠습니다. ^^

이미지에 포함된 파일 확인하기 - /Dir

/Dir 명령도 길게 설명할 건 없습니다. /Dir 명령은 명령 프롬프트의 Dir 명령과 동일하게 말 그대로 이미지에 포함된 파일의 목록을 확인하는 명령입니다. 근데 이건 이미지에 포함된 파일의 개수가 많은 경우엔 명령 프롬프트 내에서는 정확하게 파악하기가 힘이 듭니다. Dir 명령처럼 화면 단위로 끊어서 보여주는 옵션이 존재하지 않기 때문이죠.

그래서 /Dir 명령은 순수하게 해당 명령만 사용하는 게 아닌 파이프를 통해 More 와 결합하여 하나씩 확인하거나, 리디렉션을 통해 텍스트 파일로 저장하여 확인하는 것이 좋습니다.

imagex /Dir E:\Backup.wim 1 | more

imagex /Dir E:\Backup.wim 1 > E:\List.txt

또는 마찬가지로 파이프를 통해 Find, Findstr 과 결합하여 어떠한 파일이 존재하는지 확인하는 용도로 활용할 수도 있습니다. 이건 적절히 알아서 잘 사용하세요.

WIM 파일을 SWM 파일로 분할 저장하기 및 SWM 이미지로 복원하기 - /Split

1. /Split 명령을 통해 WIM 파일을 SWM 파일로 분할 저장하기

분할 저장시킬 WIM 파일.

이젠 이 글도 끝이 보이네요. SWM 은 WIM 포맷의 분할 저장 파일입니다. 이러한 SWM 분할 파일은 오직 WIM 파일을 분할하여 생성할 수 있습니다. /Cpature 와 같은 이미징 명령을 통해서는 SWM 파일을 생성할 수 없습니다. 그러니 이점 반드시 기억하셔서 삽질하지 마시고요.

다음으로 생성된 SWM 파일은 읽기 전용 속성을 가집니다. 즉, SWM 분할 파일은 이미지를 추가, 삭제하거나 편집할 수 없습니다. 심지어 /Mount 를 통해 탑재도 불가합니다. 이건 용량이 한정된 DVD 등에 나눠 담을 때의 용도로나 사용하는 겁니다.

그럼 실제로 WIM 파일을 분할하여 저장해보도록 하겠습니다. E:\Backup.wim 파일을 100MB 의 크기로 분할하여 E:\Backup.swm 분할 파일 세트로 저장하도록 하겠습니다. [SWM 분할 파일 세트의 이름은 원본 WIM 파일과 달라도 상관없습니다.]

imagex /Split E:\Backup.wim E:\Backup.swm 100

2. SWM 파일을 통해 드라이브 복원하기 - /Apply /Ref

SWM 파일의 이미징을 해제하는 것도 /Apply 명령이며, 기본적인 명령도 동일합니다. 단! SWM 파일로 복원을 진행할 땐 첫 번째 SWM 파일은 물론 /Ref 옵션을 통해 나머지 모든 분할 SWM 파일을 함께 지정해줘야 합니다. 그것은 /Apply 명령의 /Ref 옵션이 담당합니다.

매개 변수	설명
/Ref	SWM 분할 이미지 파일을 통해 이미지 해제 작업을 진행하는 경우 나머지 분할 이미지 파일들을 지정해주는 역할을 합니다. 와일드카드를 사용할 수 있습니다. ex) imagex /apply E:\Backup.swm 1 D: /ref E:\Backup*.swm

 
/Ref 옵션에선 와일드카드를 사용할 수 있기 때문에 와일드카드를 통해 분할 파일들을 한 번에 지정하면 됩니다. 포맷 과정은 포함시키지 않고, /Apply 명령만 보도록 하겠습니다.

imagex /Apply E:\Backup.swm 1 D: /Ref E:\Backup*.swm

간단하죠? SWM 분할 파일을 통해 복원하는 것을 정리하자면 아래와 같습니다.

imagex /Apply {첫 번째 SWM 파일} {이미지 인덱스 번호} {대상 드라이브} {/Ref 나머지 모든 SWM 파일}

이상입니다. 더 드릴 말은 없네요.

이제는 윈도우의 백업과 복원에 ImageX 를 사용해보자

크리스마스에 내놓으려고 했는데 이제서야 완성되었네요. 그동안 ImageX 에 대해서 참 하고 싶은 이야기가 많았었는데, 이번 글을 통해 어느 정도는 제가 하고 싶었던 이야기들을 한 것 같습니다. 참고로 윈도우 8 과 윈도우 PE 4.0 에 이르러서는 윈도우에 내장된 WIM 파일 관리 및 수정 도구인 DISM 도구가 이미지 캡쳐 기능까지 지원함에 따라, [윈도우 7 에 내장된 DISM 은 캡쳐 기능이 없었습니다.] 사실 윈도우 8 이나 윈도우 PE 4.0 에서는 굳이 ImageX 를 준비할 필요 없이 지금까지 설명한 모든 작업을 DISM 단독으로도 처리할 수 있게 바뀌었습니다.

하지만 일단 DISM 은 명령의 구조가 ImageX 에 비해 살벌하게 복잡하고, 윈도우 8 과 윈도우 PE 4.0 에서만 지원을 하는 관계로 일단은 설명하지 않도록 하겠습니다. 사실 원래는 DISM 도 이 글에서 함께 설명하려 했는데, 그러기엔 이미 ImageX 하나로 너무 먼 길을 온 것 같습니다. ^^; DISM 은 나중에 따로 다뤄보도록 하죠.

아무튼 ImageX 를 윈도우의 백업과 복원 프로그램으로 사용하려는 이유는 비단 무료이기 때문만은 아닙니다. 바로 이번 글에서 이야기한 것과 같이 WIM 파일의 구조와 특성이 윈도우의 백업과 복원에 꽤나 적합하다는 장점이 있기 때문입니다. 하기야 마이크로소프트가 윈도우를 배포하기 위한 용도로 만든 녀석인데 개판이라면 그건 또 그것 나름대로 문제겠네요. 아무튼 그래서 저도 고스트와 함께 ImageX 를 즐겨 애용합니다.

물론 ImageX 도 단점은 있습니다. 윈도우의 백업을 위해선 반드시 멀티 부팅 상태의 다른 윈도우나 윈도우 PE 로 부팅해야 한다는 것은 굉장히 불편한 단점임에 분명하니까요. 그래도 윈도우 PE WIM 이미지를 통해 디스크에서 부팅을 꾸미는 게 그리 어렵지 않기 때문에 이 문제도 쉽게 해결은 가능한 편 입니다. 분명 사용해볼만한 가치는 있는 것 같습니다.

그리고 이번 정리가 ImageX 만세! 나머지는 모두 거지! 와 같이 윈도우의 백업과 복원에 주로 사용되는 시만텍 고스트나, 노턴 고스트, 트루 이미지의 강력함과 편리함을 부정하려는 것은 아닙니다. 그저 해당 프로그램들 못지 않게 ImageX 도 백업과 복원 도구로써 충분한 감점이 있다는 것을 혹시나 모르고 계셨을 분들에게 알려드리고 싶었을 뿐입니다. [노턴 고스트와 트루 이미지도 언젠가 정리를 해야 할텐데 말이죠. ^^;] 아무튼, 이번 글에서는 여기까지만 이야기 하도록 하겠습니다. 다소 좀 길었죠? 재미도 없는 글을 끝까지 읽어주셔서 감사합니다.

다음 글에서는 이어서 ImageX 를 통해 실제로 윈도우를 백업하고 복원하는 것을 이야기하도록 하겠습니다. 여기까지입니다.

p.s 이 글은 가져가지 마시고 링크로 소개해주시길 부탁드립니다.

★ WIM 백업 : ImageX 를 드라이브 백업 복원 도구로 활용하기, 기초적인 ImageX 의 사용법
★ WIM 백업 : ImageX 를 통해 윈도우를 백업하고 복원하기
★ WIM 백업 : ImageX 를 통한 백업과 복원시 정션과 심볼 링크 자동 수정 방지하기