나는 메일을 거의 지우지 않는 편인데 지금까지 7년이 넘는 기간 동안 연구실 메일 서버를 통해서 주고 받은 메일을 거의 대부분 가지고 있다. 양이 엄청나기 때문에 연도별로 별도의 폴더에 넣고 보관을 한다. 한 해 동안의 메일은 적으면 1800건, 많으면 3000건 정도 된다. 그런데 그 동안 컴퓨터를 몇 번 바꾸기도 하였고 폴더 보관 방식을 바꾸기도 해서 thunderbird의 폴더 데이터에 거품이 많이 끼었다. 거품 청소를 해야 하는데 청소하기 전의 총 데이터양이 10GB 가까이 되었다. 청소하고 나니 약 7GB 정도로 줄었다. 3GB는 이익을 본 셈이다.

우선 사용한 기능들을 보면 Thunderbird 자체의 압축(compress가 아니라 compact이다.) 기능과 Remove Duplicate Messages (Alternate) 0.3.1이라는 Thunderbird add-on의 기능이다. 그리고 거품 청소를 해야겠다고 마음먹게 만든 글은 [Thunderbird] Uses LOTS of disk space - can't clean up이라는 글이다.

모든 폴더를 정리했는데 스크린샷을 남기기 위해 archive04라는 폴더를 정리하는 것을 보도록 한다.

일단 thunderbird가 저장하고 있는 공간을 보면 archive04에 1.2GB 정도를 사용하고 있다. 백업했다가 다시 데이터를 살리는 경우에 이미 지운 메일을 thunderbird가 다시 복구해버리는 경우가 있어서 중복된 메일들이 꽤 있다. 그래서 일단 중복된 메일을 지우는 작업을 한다.

폴더에 오른쪽 클릭을 하고 Remove Duplicates...를 선택하면 중복된 메일들을 검색한다. 이 기능은 앞에서 말한 add-on에서 제공하는 기능이다. 간혹 사람이 보기에는 중복된 메일을 그냥 두는 경우가 있는데 add-on의 설정에서 어느 속성들을 비교할 것인지를 변경해 보면 된다. 아마 message ID를 끄고 To와 CC 항목을 체크하는 것이 사람 눈으로 비교하는 것과 같은 효과를 가져올 것이다.

중복된 메일을 찾으면 그 중에서 어느것을 남길 것인지를 물어본다. 어차피 중복된 것이니 그냥 첫번째 copy를 남기기로 한다. 확인을 누르면 중복된 메일들을 지운 편지함으로 옮긴다.

다 끝나면 Thunderbird가 표시하는 메일 수는 줄었지만 실제 디스크 공간은 그대로일 것이다. 이제 압축을 한다.

여기서 압축이란 zip 같은 것을 쓰는 compression이 아니다. 앞에 링크한 글에도 나오지만 지운 메일은 실제로 디스크에서 지워지는 게 아니고 지웠다고 표시만 하고 데이터는 그대로 있다. 단지 Thunderbird가 표시하지 않을 뿐이다. 이런 방식은 한 폴더의 메일들을 전부 하나의 텍스트 파일에 저장하기 때문인데 이렇게 하는 것이 효율 면에서는 좋다. 그리고 메일 수가 많지 않고 빈번하게 접근하거나 다른 곳으로 데이터를 옮기거나 백업하거나 하는 것이 없다면 그냥 둬도 괜찮다. 큰 텍스트 파일에서 일부분을 지우거나 수정하는 것이 사실 만만치 않게 로드가 많이 걸리는 작업이다. 텍스트 에디터로 보면 어려울 게 없는 것 같지만, 글자 하나가 지워지거나 삽입되면 그 뒤에 있는 모든 글자의 위치가 변하기 때문에 이것을 모두 기록해야 한다. 뒤에 덧붙여 쓰는 작업 같은 것과는 비교가 안된다. Thunderbird에서 말하는 압축이란 지워졌다고 표시된 메일들을 실제로 디스크에서 없애는 작업이다. (compact하게 만든다.) 폴더에 메일이 많으면 당연히 오래 걸린다. 인내심을 갖아야 한다.

압축까지 하고 나면 디스크 사용량이 많이 줄어든 것을 볼 수 있다.

폴더 하나에서 500메가 정도가 풀려났다.

그동안 vim하고만 친했었는지라 emacs와도 한번 알고 지내고 싶었는데, 대략 한시간 만에 포기.

이유는 폰트 -.-;

요즘 세상이라는 게, 기능이야 어쨌든 뭐든지 일단 보기가 좋아야 하는데, emacs 쪽은 gvim 같은 쪽과는 다르게 폰트 설정하는 것이 뭔가가 상당히 복잡하고 사람들도 불평 불만이 많은 것 같다. 예전에 윈도우즈에서 emacs에서 돌아가는 무슨 소프트웨어(이름 까먹음)를 돌릴 때는 이렇게 눈을 괴롭히지 않았던 것 같은데... 하긴 윈도우즈야 모든 사람들이 거의 같은 설정을 쓰는 데다가 한글 폰트 같은 경우는 "한글 폰트 = 굴림" 같은 식이었으니 폰트 문제는 상대적으로 적었던 건지도 모르겠다.

일단 심심해서 죽을 지경이 되지 않는 한 emacs와는 계속 소원한 상태로 지내야겠다는 생각이 든다.

안녕 emacs.

(EDIT 2009.03.13 windows에서 rsync server를 사용하는 것은 포기했음. 자세한 사정은 이 글 끝의 덧..들을 참고. 아래는 그냥 기록상 남겨둠. 다른 사람에게는 도움이 될 지도 모르니...)

서설

노트북에서 작업을 하다가 갑자기 비교적 대량의 데이터를 백업해야 할 일이 생겼는데 FTP로 옮기고 있자니 짜증이 났다. 뭔가 일이 자동으로 일어났으면 좋겠는데... 그런 생각을 하다가 노트북 데이터의 자동 백업 방법을 생각해 보니 제일 바람직한 것은 rsync를 사용하는 것이었다. 버젼 컨트롤이 필요한 것들은 lab 한 구석에 돌리는 debian 서버에 subversion(옛날 것들)과 git(요즘 것들)을 혼합하여 저장하지만, 특별히 버젼 컨트롤은 필요 없이 단순히 동기화만 필요한 것들에는 굳이 subversion이나 git을 사용할 필요가 없어 보였기 때문이다. 버젼 컨트롤에는 아무래도 이러저러한 추가 정보들이 필요하다 보니 단순히 동기화를 위해서 버젼 컨트롤 소프트웨어를 사용하는 것도 낭비라고 여겨졌다. 그래서 lab에서 사용하는 windows 데스크탑이 HDD도 넉넉하니 단순 무식하게 rsync로 자동으로 동기화가 되도록만 해 놓고 싶었다.

이 글은 linux client(ubuntu 사용)와 windows server(win xp 사용) 사이에 rsync 설정을 한 삽질기이다.

서버

일단 windows가 서버가 되어야 하니 rsync server를 설치해야 하는데 찾아 보니 이런 것들이 있다.

• DeltaCopy
  
• cwRsync
  

DeltaCopy는 rsync server이긴 한데 이 글을 읽어보면 domain controller하고 얽혀서 별로 좋지가 않다고 한다. 서버가 windows xp인데다가 우리 랩도 windows domain controller하고는 담 쌓고 지낸지가 몇년이 됐으니 DeltaCopy는 나도 패스다.

cwRsync는 특별히 새로 나온 소프트웨어라기보다는 기존에 cygwin과 rsync를 직접 설치하던 것을 cygwin에서 필요한 부분만을 가져오고 rsync를 그 위에 설치해 주고 rsync 서버를 daemon mode로 (그러니까 윈도우즈 서비스로) 설정하는 것까지를 편하게 해 준다. cygwin에서 뭘 가져올지를 시간들여 생각할 필요가 없다. 그러니 나를 위해서도 이것이 좋은 선택이다.

cwRsync는 위 홈페이지에서 링크를 따라가면 sourceforge에서 다운로드할 수 있는데, client는 필요 없으니 서버만 다운로드한다. (cwRsyncServer_3.0.1_Installer.zip) 설치는 간단하다. 특별히 신경 써서 뭘 할 필요도 없다. 단, 설명을 읽어보면 서비스 시작 형태가 수동으로 설정된다고 하는데, 관리도구->서비스 에서 rsync server를 찾아서 자동으로 시작하도록 해 준다. (시작은 좀 있다가 한다.) 그리고 실제의 서버 설정을 하는데, 시작메뉴에서 cwRsync를 찾아서 rsyncd.conf를 누르면 설정파일 내용이 메모장에 뜬다.

rsync는 기본적으로 module 단위로 동작한다. 서버의 설정 파일에 모듈들을 지정하면 외부에서는 서버이름과 그 서버에 있는 모듈들이 보이는 식이다. 서버이름/모듈이름 의 형식으로 접근하게 된다. 설정파일에서 기본적인 것은 그냥 있는 것(test라는 모듈이 이미 하나 정의돼 있을 거다.)을 대충 고쳐서 써도 되는데 중요한 것은 charset을 처리하도록 손을 봐 줘야 한다는 거다. 일단 upload할 모듈의 끄트머리에 charset = utf-8을 적어준다. 한글 파일 이름만을 위해서는 윈도우즈 기본 charset인 cp949나 euc-kr을 써도 되는데 유럽쪽 글자들이 들어 있는 파일 이름을 위해서는 아무래도 유니코드가 좋다. 여기에서 utf-8로 정해줬다고 바로 그대로 동작하는 건 아니다. 이 글이나 이 글을 읽어 보면 cwRsync에 딸려 오는 cygwin이 유니코드를 사용하도록 돼 있지 않다고 한다. 그 글들에서 따라가 보면 어떤 일본어로 된 utf8-cygwin이라는 페이지가 뜨는데 거기에서 cygwin1-dll-20-11-18.tar.bz2을 다운로드한다. 압축파일을 열면 cygwin1.dll이라는 파일이 나오는데 그걸 C:\Program Files\ICW\Bin 아래에 덮어 씌운다.

그럼 그 다음에 rsync 서비스를 시작해 준다. 이 이후에 중간 중간 설정 파일을 바꾸면서 시험해 볼 때는 매번 서비스를 중지하고 다시 시작해야 할 필요는 없다. 설정파일을 바꾸면 바로 적용되는 듯하다.

클라이언트

클라이언트는 뭐 특별히 설명할 것이 없다. 한가지만 언급하자면 rsync 프로그램에 먹일 옵션으로는 -ausx --iconv=utf-8 정도가 좋은 것 같다. 물론 리눅스 클라이언트에서 사용하는 charset이 utf-8일 때 얘기고 옛날 식 euc-kr을 쓴다면 -ausx --iconv=euc-kr로 하면 될 것이다.

자동화

자동화는 클라이언트가 리눅스이니 cron 같은 것을 쓰면 된다. 이것도 여기서 특별히 설명할 것은 없네. 다른 데 더 좋은 설명이 많을 테니까.

어째 용두사미 격의 삽질기네. 뭐, 삽질에 시간이 제일 많이 걸린 부분이 저 위에 utf-8 관련한 정보를 찾는 시간이었으니 오히려 이런 식이 제 격인 것 같기도 하고. ㅋㅋ

그 날 이후

덧. 2009. 03. 12 컴퓨터를 갈아 엎고 나서 위에 기록한 거 대로 다시 설치했는데 이게 제대로 안된다. 문제는 아직 뭔지 모르겠다. cygrunsrv.exe를 실행하면 error 1053을 내고 서비스가 시작되지 않는다.

덧. 2009. 03. 13 cwRsync도 어차피 cygwin과 rsync를 설치하기 쉽게 패키징 한 것이다. 그래서 cygwin을 사용하지 않는 것을 찾아보았는데 Unison이라는 것을 찾았다. 그런데 이것도 문제가 있다. windows에 server로 설치하기 위해서는 socket method와 remote shell method를 선택할 수 있는데 socket method는 보안을 구현하기 거시기하다. 그런데 remote shell method로서 추천하고 있는 것이 결국 cygwin + ssh을 설치하는 것이다. 이래서는 어차피 다시 cygwin으로 돌아온 것이다. 그럴 바에는 그냥 cygwin + ssh + rsync로 가는 것이 훨씬 나을 것 같다. 그런데 다시 cygwin + ssh + rsync로 한다고 해도 앞에 덧. 03.12에서처럼 cwRsync에서의 알 수 없는 문제가 또 생길지도 모르겠다.

덧. 2009. 03. 13 cygwin을 직접 설치하고 rsync를 setup하려고 해도 같은 문제가 생긴다. cygwin 설치와 관련된 것은 아닌 것 같다. 그보다는 win xp에서의 permission setting 같은 것과 관련이 있는 것으로 보인다. 이것을 해결하기 위해서는 cygrunsrv.exe 프로그램에 관계된 자세한 문서를 찾아봐야 할 것 같은데 잘 못찾겠다. 정 안되면 소스를 분석해봐야겠다. 근데 그러려면 일이 커질 확률이 꽤 있다.

또 다른 해결책으로는 windows 머신에 virtualbox 같은 가상 머신을 설치하고 windows 방화벽에서 port forwarding을 할 수 있다. 그런데 이렇게 하는 것은 문제 해결 자체보다 해야 할 것이 많아서(가상 머신 설치와 설정 등) 별로 내키지 않는다. 그래도 이 방법에 대해서는 내가 잘 알고 있기 때문에 cygrunsrv.exe를 분석하는 것 보다는 빨리 해결할 수 있을 것 같다.

덧. 2009. 03. 13 이것 저것 살펴 보고 나서 내가 cygrunsrv.exe의 문제를 해결할 수 없을 것이라고 판단했다. 물론 시간을 들이면 못 하지는 않을 것 같지만 들이는 시간에 비해서 얻는 것이 미약하다. 당분간은 rsync 없이 ftp로 살아야겠다. 어차피 데이터는 한쪽으로만 흐르고 지워지는 데이터는 거의 없고 주로 교내 네트웍에서 자료를 옮기기 때문에 네트웍 대역폭을 신경 쓸 필요가 없고 공용 서버들도 아니고 critical service를 돌리는 컴퓨터들도 아니기 때문에 시스템 load에도 신경 쓸 필요가 없다.

고로... 그냥 ftp만 이용하다가 여름 정도 도면 cygwin과 cygrunsrv.exe에 중요한 변화가 있는지 체크해 보는 것이 좋을 것 같다.