똘똘한 전화기 Android를 처음 쓰기 시작했던 7년 전부터, 유닉스/리눅스 세상의 만능 복사기인 rsync를 이용하여 내 폰의 데이터를 백업해왔다. 그러나 처음에는 간단하게 되던 것이 Jelly Bean기반의 갤럭시S3로 갈아타면서, 그리고 이번엔 Nougat 기반의 갤럭시A5로 갈아타면서 꽤나 성가시게 됐다. 이 글에서는 이 성가셨던 내용과 내가 rsync로 데이터를 백업하기 위해 고민했던 내용과 결과를 기록한다.

스마트폰 데이터의 백업

• 스마트폰 데이터의 백업
  • 나는 어떻게 백업을 하나?
• 갤럭시A5 Nougat 환경의 Rsync 백업
  • 이 방식을 선택한 이유
  • 백업 환경의 구성
• TL;DR 백업 대란 이야기
  • 흐린 기억 속의 1차 백업 대란
  • 바로 어제 겪은 2차 백업 대란
• 실전! Rsync로 백업하기
  • MTP 연결을 활용한 Rsync 백업
  • Wifi 연결을 경유한 Rsync 백업
  • 보너스: 오래된 앱의 외장 SD Card 접근

통화만 되면 그만이던 그 시절에는 혹시 휴대전화가 고장나거나 잃어버렸을 때, 그 속에 저장되어 있는 전화번호부까지 함께 잃어버려서 뜻하지 않게 사회로부터 고립되는 것이 가장 큰 위협이었다. 조금 더 나아가면 기억하고 싶은 40자 짜리 문자메시지 몇 십 개가 더 있을 수 있겠다.

그러나 똘똘한 전화기, 스마트폰은 그 선조처럼 전화번호부와 문자메시지만 가지고 있는 녀석이 아니다. 심지어 가끔, 무의식 중에 “카메라 어디다 뒀지?” 라면서 스마트폰을 찾는 사람이 있을 정도로, 오히려 누군가에겐 전화기 이상의 가치를 갖게 하기도 한다.

나는 어떻게 백업을 하나?

일반적으로는 다음과 같은 방법으로 연락처 등 기본 데이터와 추가로 스마트폰에 저장된 사진, 다운로드한 파일, 앱의 데이터 등을 백업할 수 있다.

• Google 계정 연동을 통한 연락처, 일정 동기화 (모든 Android 폰 기본 지원)
• Google 계정 연동을 통한 앱 데이터 동기화 (모든 Android 폰 기본 지원)
• 통신사 서비스를 이용한 동기화/백업 (통신사업자가 서비스를 제공할 때)
• 제조사 서비스를 이용한 동기화/백업 (스마트폰 제조사가 서비스를 제공할 때)
• Dropbox, Box.com, OneDrive 등의 클라우드 스토리지 서비스 활용

연락처와 일정 등은 Gmail, Google Calendar 등을 사용하는 내게는 Google의 동기화 서비스가 가장 확실하고 편리한 방법이다. (물론, 나는 인터넷 서비스를 100% 신뢰하지는 않기 때문에 이따금 해당 서비스에서 제공하는 Local 백업 서비스를 이용하여 다시 2차 백업을 받기도 한다.)

그런데 기타 데이터에 대해서는, 나는 다음과 같은 이유로 앞서 열거했던 서비스를 이용하지 않는다.

• 통신사나 제조사에 얽메이고 싶지 않다. (폰이나 가입망을 바꿀 수 있다.)
• 제3자 서비스의 경우, 무료 제공량의 한계가 있다. 많이야 10GB 수준?
• 그리고, 어떤 형태로든 내 손에 닿는 곳에 데이터를 두고 싶다.

그래서 내가 오래 전부터 선택했던 방식은 스마트폰을 내 Ubuntu 데스크톱에 연결하여 리눅스계의 만능 복사기 rsync로 복제를 하는 방식이다. 그런데 스마트폰을 갤럭시S에서 갤럭시S3로 바꾸고, 이제 다시 갤럭시A5로 갈아타면서, 그에 따라 Android가 Gingerbread에서 Jelly Bean으로, 그리고 다시 Nougat로 올라가면서 이 rsync를 사용하여 백업을 하는 방법에 문제가 생겼다!
(어떤 문제가 생겼는지는 TL;DR 백업 대란 이야기에서 계속하고, 일단 어떻게 풀었는지, 결론을 보자.)

갤럭시A5 Nougat 환경의 Rsync 백업

rsync를 사용한 백업의 편리함과 확실함을 유지하게 위해, 그리고 2차에 걸친 백업 대란 이후 몇 가지 시도를 거친 끝에 내 스마트폰의 백업에 적용한 방식은 Wifi 연결을 통한 rsync 백업환경이다.

이 방식을 선택한 이유

결국, 백업대란의 내용에 대한 해법이겠지만, 결과적으로 다음과 같은 내용이 내 결정을 유도했다.

USB Cable의 연결 제거

과거에 내가 썼던 백업방식은 USB Cable로 스마트폰을 랩탑에 연결한 후에, 랩탑에 USB Mass Storage로 연결된 스마트폰의 외장디스크를 rsync 명령을 활용하여 백업하는 것이었다. Jelly Bean 버전을 탑재한 갤럭시S3부터는 USB 연결모드 중 Mass Storage 모드를 지원하지 않았기 때문에 Rooting을 한 후에 제3자 앱을 설치하여 Mass Storage 모드를 활성화해야 했었다.

Wifi를 사용하게 되면, 이렇게 변칙적으로 Mass Storage Mode를 적용하기 위해 Rooting을 할 필요가 없으며, 케이블 연결 과정에서 발생하는 귀찮음과 물리적 복잡성을 제거할 수 있다.

MTP의 한계 극복

USB Mass Storage를 대신하여 제공되는 MTP와 PTP 방식의 연결은 미디어파일 또는 사진파일의 전송을 목적으로 만들어진 규약으로, MP3나 카메라의 연결을 위해 특화된 방식이다. (사진파일만 지원하는 PTP와는 달리, 다행히 MTP는 파일의 확장자와 무관하게 파일을 전송할 수는 있다.)

스마트폰을 MTP 방식으로 Ubuntu 데스크톱에 연결하게 되면, Gnome GVFS 등을 통한 파일 접근이 가능해지지만 GVFS의 특성에 의하여 접근 방식이 제한적이고, 숨김폴더(‘.’으로 시작하는 폴더) 등을 보여주지 않는 등, 몇 가지 치명적인 한계를 가지고 있다. SSH 연결을 이용한 이 방식을 사용하면, 저장소에 존재하는 모든 파일을 제한 없이 전송할 수 있다.

여전히, PC에서 제어권 유지

꼭 rsync가 아니더라도, 단지 Wifi만 놓고 보면 스마트폰 백업용의 다양한 유료 또는 무료 앱을 찾아볼 수 있다. 아마, 컴퓨터를 전문적으로 사용하지 않는다면 휠씬 수월한 방법일 것이다. 하지만 이런 방식은 백업 후 변경된 파일의 무결성 검토라든지, 지워진 파일의 아카이빙 등 내가 필요로 하는 세밀한 제어권을 크게 떨어뜨리게 되어 맘이 편하지 않다.

이 방식을 사용하면, 여전히 rsync의 멋진 동기화 기능을 활용할 수 있고, 백업 이후의 작업에 대한 나의 권한을 데스크톱의 자유도 내에서 유지하여 보다 확실하게 백업을 수행할 수 있다.

백업 환경의 구성

환경의 구성은 그리 복잡하지는 않다. 간단히 말하면, 스마트폰에 Android에서 동작하는 rsync를 지원하는 sshd 서버를 구성해주는 것이 거의 전부다.

Android 폰의 구성

Android 상에서 rsync를 지원해줄 수 있는 앱을 찾던 끝에, rsync4android, Rsync Wrapper 등의 능동적으로 백업을 수행할 수 있는 클라이언트 모드의 앱과, 서버 모드로 동작하면서 외부로부터의 rsync 연결을 받아주는 SSHelper라는 앱을 찾을 수 있었다. 그리고 최종적으로 데스크톱 자유도를 보장해줄 SSHelper를 선택했다.

Google Play를 통해 설치할 수 있는 이 앱은, 사용자의 스마트폰에 rsync 지원을 위해 필요한 sshd를 비롯한 일부 필요한 기능을 설치해주는데, 아래와 같은 인터페이스를 통해 접속 Port를 비롯하여 이 앱이 지원하는 다양한 설정을 할 수 있다. (현재버전에서 제공하는 전체 설정은 아래 SSHelper의 전체 메뉴에서 볼 수 있다.)

위의 화면을 보면, 제목 부분에 녹색의 “Server” 문구를 볼 수 있는데, 이건 sshd 서버가 동작중임을 표시하는 것이며, 적색의 “Network” 부분은 폰이 현재 네트워크로부터 분리되었음을 표시한다. 이는, 편의 상 Data Network을 끄고 시험을 했기 때문에 이렇게 표시되는 것이며, 현재 이 폰은 Wifi Hotspot 모드로 나의 랩탑에게 연결을 제공하고 있는 중이다.

같은 시점에 알림창을 보면, 먼저 SSHelper가 2222번 포트에 귀를 기울이고 있다는 알림이 나와 있고, Wifi Hotspot에 하나의 장치(내 랩탑)가 연결되어 있다는 알림이 그 아래 떠 있다.

만약, Data Network이 켜진 상태라면 SSHelper의 접속 IP 부분이 다르게 보일 수 있다.
이제 데스크톱으로 가보자.

데스크톱의 구성

데스크톱의 경우는 딱히 “구성”이라고 할만한 것은 없다. 단지, 위와 같이 새롭게 구성된 sshd 기반의 rsync 서버를 목적지 또는 출발지로 한 명령을 내려주면 그만이다. 단 아래와 같이, 몇 가지 주의해야 할 옵션이 있다.

기존에 사용했던 옵션을 참고로 살펴보면 다음과 같다.

• -avub: 기본적으로 -a 옵션을 사용하여 아카이브 모드로 설정했다. 아카이브 모드는 -rlptgoD와 같은데, 퍼미션과 변경시간, 소유자 등의 값을 모두 원본과 동일하게 보존하도록 하는 옵션이다.
• --backup-dir=$ROOT/backups/$DATE: -b 옵션으로 변경된 파일의 기존 버전에 대한 백업을 만들 때, 기본적으로는 해당 파일의 원래 위치에 백업을 만들지만, 이 옵션을 추가로 주면 백업파일을 별도의 위치에 둘 수 있다. 이를 통하여, 변경된 파일과 지워질 파일을 따로 검토하기 편리하도록 했다.
• --log-file=logs/$DATE.log: 이 옵션은 동기화에 대한 세부 기록을 남기는 설정이다. 어떤 파일이 언제 등장했는지 등을 추적하기 위함이지만, 실제로는 잘 활용하지 않고 있다.
• --exclude-from .exclude-files: Cache 파일 등, 동기화가 필요없는 파일은 이 옵션에서 지시하고 있는 .exclude-files 파일에 열거함으로써 복제를 막을 수 있다.
• 선택적으로 --delete --delete-excluded 옵션을 사용하여 +/- 없는 완전히 동일한 복제본임을 확인하기도 한다.

아래 내용은, Wifi를 통한 원격 백업을 위해 변경하거나 추가한 옵션이다.

먼저, 기존에는 동기화의 소스 지정이 /media/sio4/789A-A012와 같은 모양으로, 로컬에 마운트된 형태를 사용했다. 이제는 저장장치의 마운트를 하지 않고 원격지 접속을 사용하기 때문에 192.168.43.1:/storage/789A-A012/와 같은 형태로 바뀌게 된다.

이렇게 원격지로 지정된 경로에 접속하기 위해서, rsync는 내부적으로 ssh 연결을 사용한다. 그러나 앞서 설정한 SSHelper가 ssh 표준 포트인 22번을 쓰지 않고 사용자 프로세스로 동작하기 위해 2222번 포트를 쓰도록 설정한 상태이니, 이를 rsync에게 알려줘야 한다. 물론 ~/.ssh/config 파일에 해당 항목을 추가할 수도 있는데, 이 연결을 백업 이외의 용도로 사용하지 않을테니 안 그래도 붐비는 config를 건드리지 않고 아예 명령행에 옵션으로 넣어줬다. 이제 -e 'ssh -p 2222' 옵션을 통하여, rsync는 어떤 명령을 써야 할 지 알게 된다.

다음은 소유권과 퍼미션에 대한 부분이다. 사실, 가져오는 백업만 할 경우엔 문제가 되지 않을 부분이긴 한데, 이미 Jelly Bean 시대부터 Android는 일부 파일시스템에 대한 Modification Time 값을 사용자가 바꿀 수 없게 되었다.

무슨 말이냐면, rsync는 아카이빙 모드로 동기화를 하면서 파일의 소유자, 권한, 날짜속성 등을 원본의 것과 동일하게 맞추게 되며, 다시 동기화가 될 경우에 이 속성들의 변경에 대해서도 반응(다시 동기화)을 하게 된다. 그러나 Android가 날짜변경 등을 허용하지 않기 때문에 잘못하면 동일한 파일을 매번 다시 쓰는 상황이 발생할 수 있다는 뜻이다.

그래서, 혹시 데스크톱에서 스마트폰으로의 동기화도 필요하다면, 다음 옵션을 선택적으로 활용할 필요가 있다.

• --no-times: 시간정보는 동기화하지 않음
• --omit-dir-times: 폴더의 시간정보는 동기화하지 않음
• --no-perms: 권한 정보는 동기화하지 않음
• --no-owner: 소유권 정보는 동기화하지 않음

아무튼, 내 목적에서 선택한 최종 옵션은 다음과 같다.

$ rsync -avub \
	--backup-dir=$ROOT/backups/20171023.182335 \
	--log-file=logs/20171023.182335.log \
	--exclude-from .exclude-files \
	-e 'ssh -p 2222' \
	192.168.43.1:/storage/789A-A012/ $ROOT/_card/
<...>
sent 2,149 bytes  received 1,061,740,605 bytes  5,754,703.27 bytes/sec
total size is 1,061,470,794  speedup is 1.00
$ 

해보니까, 약 44 Mbps 정도의 속도로 백업이 잘 된다!

TL;DR 백업 대란 이야기

내 첫 스마트폰인 갤럭시S는 Android Eclair로 시작하여 Froyo, Gingerbread 등의 버전을 사용했었다. 뒤돌아보면 UI나 성능 등은 많이 떨어졌지만, 자유도 면에서는 정말 편리했다. 이 시절에는 단지 USB Cable로 스마트폰을 데스크톱에 연결만 하면, 외장 메모리가 USB Mass Storage로 잡혔기 때문에 간단하게 rsync 명령을 통해서 백업이 가능했다.

$ rsync -av /media/smartphone/ /backups/smartphone/
<...>
$ 

뭐 이런 식이었다.
그렇게 말도 많고 탈도 많았던 갤럭시S를 2년 반 쯤 사용하다가, 끝물 세일에 들어간 갤럭시S3로 갈아탄 순간 일이 터졌다!

흐린 기억 속의 1차 백업 대란

버벅거리던 갤럭시S에서 벗어나 갤럭시S3의 부드러움(그땐 그랬지)을 느끼는 기쁨도 잠시, 이 새로운 스마트폰은 그 속의 Jelly Bean 버전의 Android와 콜라보레이션을 하면서 내게 백업의 고통을 줬다. 요약하면 다음과 같다.

• USB Mass Storage 미지원 - 기존에는 간단히 외장하드디스크처럼 인식되던 스마트폰의 저장공간이, 이때부터 MTP와 PTP만 지원하기 시작했다!
• 64GB 이상의 SDXC 카드는 extFAT을 사용 - 그런데 이때만 해도 리눅스에서 extFAT을 사용하는 것은 추가 작업이 필요했고, 안정적인 느낌도 없었다. 그나마, 별도의 패키지 설치로 해결할 수 있었으니 다행.
• 내장 메모리의 Modification Time 변경 불가 - 가끔 사진 파일 등의 mtime을 되돌리는 작업을 하는 내게는 비극! Android는 SDCard를 더 이상 물리적으로 쪼개어 사용자 공간을 제공하지 않고 추상화된 Filesystem을 통해 내부/외부 공간을 제어한다고 한다. 그런데 이 추상화 레이어가 mtime 변경 Call을 제공하지 않는다! 역시 그나마, 외장 메모리는 mtime 변경이 허용되어 다행.

결국, 내 선택은 Rooting이었다. Rooting을 하게 되면 별도의 앱을 이용하여 이제는 기본적으로 제공되지 않는 USB Mass Storage를 선택적으로 활성화할 수 있게 되기 때문. 사실, 정말 번거로운 일이었다. 특히, 잘 동작하지도 않으면서 MTP 파일시스템이 자꾸 자동으로 마운트되는 바람에 성가신 적이 한 두 번이 아니다. 아무튼, 돌아보니 이만하면 다행.

바로 어제 겪은 2차 백업 대란

그나마 갤럭시S3 + Jelly Bean은 양반이었다. 그 뒤를 잇는 Kitkat, Lollipop 등에서는 점차 보안 관련 기능들이 강화되기 시작을 하더니, 와… 갤럭시A5 + Nougat는 제약이 왜 이리도 많은지! 요약해보면 다음과 같다.

• USB Mass Storage로 데스크톱과 연결하는 것은 여전히 지원하지 않는다. :-(
• 이제는 내장 SDCard 뿐만 아니라 외장 SDCard에서도 Modification Time을 바꿀 수가 없다. :-(
• 앱이 외장 SDCard에 접속하려면 별도의 권한 요청이 필수적으로 필요하다. 그래서 원하지 않는 앱이 나도 모르게 뭔가 하는 것을 막을 수 있다! :-)
• 저장공간에 대한 권한을 준다고 해도, 자신의 패키지명에 기반한 지정된 경로에 한하여 외장 SDCard에 접속할 수 있다. :-/ 그래서 특정 앱이 사용한 공간이 확실하게 파악이 되는 반면에, 앱을 지우면 모든 저장해둔 것들도 함께 날라간다!
• 어느 버전부터인지 모르지만, 접근 영역을 넓히는 요청/설정이 가능해서, Total Commander 같은 전체 접근이 필요한 앱에게 추가 권한을 줄 수 있다.
• 그럼에도 불구하고, JVM 상에서 동작하지 않는, NDK로 컴파일된 것들은 외장 공간 접근 기능을 활용할 수 없다고 한다. :-(
• 조금 다른 얘긴데, 외장 SDCard를 넣고 빼기가 더 힘들어졌다. :-(

그래서 뭐라는 거냐고!?

보안이 강화되어 안전해진 부분도 있지만 백업하기가 더 힘들어졌다는 뜻이지 뭐.

위의 갤럭시A5 Nougat 환경의 Rsync 백업은 결국, 이런 제한점을 극복하기 위한 시도의 결과이다.

다음 내용은, 최종적으로 선택하지 않았지만, 시도되었던 내용들 중에서 나름 의미가 있었던 부분을 혹시 다른 시점에는 참조가 될 수도 있을 것 같아서, 그리고 기록하는 의미에서 정리하였다.

실전! Rsync로 백업하기

Rooting을 하지 않고 어떻게든 백업을 해보려고, MTP를 활용하는 방법과 Wifi를 활용하는 방법 등을 중심으로 몇 가지 시도를 해봤다.

MTP 연결을 활용한 Rsync 백업

MTP도 FTP처럼 일종의 파일에 대한 전송 규약이며, 대부분의 파일 전송 규약을 리눅스에서는 가상의 파일시스템으로 잡을 수 있는 방식을 지원한다. 예전에 Gnome의 파일매니져인 Nautilus가, 스마트폰 연결 시 자동으로 그것을 연결하는 것을 봤지만, 그 때 mount나 df 등의 명령을 내려보면 마운트된 흔적을 찾을 수 없었다. 그러나 하겠지. 할거야. 그래서 조금 더 봤다.

GVFS로 MTP 연결

GVFS는 Gnome에서 사용하는 사용자 영역의 가상파일시스템이라고 한다. (헉! “라고 한다”라니… 그래도 한 때는 Gnome 전체 패키지를 쫙 꿰고 있었던 난데… 이제 완전 남의 얘기구나. ㅎ) Gnome 데스크톱 사용자가 다양한 종류의 파일저장소를 쉽게 데스크톱에 붙여 사용할 수 있도록 도와주는 FUSE 기반 기능이다. 뒤져보니, 스마트폰은 다음 경로에 붙어있었다.

$ ls -d /run/user/1000/gvfs/*/*
/run/user/1000/gvfs/mtp:host=<...>/Card
/run/user/1000/gvfs/mtp:host=<...>/Phone
$ 

아! 쉽네! 답이 딱 나왔다. 기존에 쓰던 백업용 makefile의 SRC를 기존의 /media/sio4/0000-0000/ 식의 경로에서 /run/user/1000/gvfs/*/Card/로 바꾸면 끝이네! 그래서 해당 경로 내에서 파일 목록 등을 보니 아주 잘 보인다. 해서, makefile을 수정하고 rsync를 돌렸는데…

하/나/도/ 백/업/이/ 되/지/ 않/았/다/

뭐냐… 자세히 보지는 않았지만, gvfs의 설명을 gvfs의 Github 저장소에서 봤더니 이게 glib 기반의, gio라는 방식으로 동작하도록 설계된 것이라고 한다. 아… 그냥 POSIX를 지원하여 아무 프로그램으로나 접근할 수 있는 것이 아니란 말인가 보다. 다른 길은 없나?

GPhotoFS로 MTP 연결

아마, 이름만 봤으면 이 방식은 시도해보지 않았을 것 같다. 이름만 보면, 사진 전송을 목적으로 하는 PTP를 위한 것으로 보이고, 이 PTP는 전체 파일에 대한 백업을 원하는 나의 용도와 맞지 않는다. 그러나 알고 보니 그렇지가 않다!

먼저 다음과 같이, 해당 패키지를 설치해준다.

$ sudo apt-get install gphotofs
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
  gphotofs
0 upgraded, 1 newly installed, 0 to remove and 2 not upgraded.
Need to get 14.4 kB of archives.
After this operation, 67.6 kB of additional disk space will be used.
<...>
$ 

설치가 끝났다면, 스마트폰이 연결된 상태에서 이미 사용중인 gvfs 마운트를 해제한 후에 다음과 같이 명령을 내려준다.

$ mkdir ~/mt
$ gphotofs ~/mt
$ ls ~/mt
store_00010001  store_00020002
$ fusermount -u ~/mt
$ 

위와 같이, 두 개의 하위경로가 들어있는데, 각각 내부메모리와 외장 SD이다. 그리고 이렇게 했더니 일반적인 cp, vi 등의 방식으로 파일을 읽을 수 있다!

그런데 역시 gphotofs의 Github 저장소에 가보니 난감한 문구가 몇 개 있다. 파일 변경에는 문제가 있다라든지, 이름변경을 할 수 없다라든지… 그리고 연결을 끊었다가 다시 붙였을 때의 문제 등이 설명되어 있다.

아무튼, 원본을 유지한 채 진행하는 백업 용도로는 쓸 수 있을 것 같다!

추가: GVFS 자동 연결 방지

아, 그런데 일단 스마트폰을 연결하면 자동으로 GVFS가 MTP 연결을 잡아버린다! 이것을 막아야, 보다 안정적으로 GPhotoFS를 쓸 수 있을 것 같다. 그래서 좀 찾아보니, 다음과 같은 방식으로 이것을 막을 수 있다. (분명 사용자 레벨의 설정도 있을 것 같은데… 찾아보지 않았다)

장치가 연결되었을 때, 자동화를 돕는 모니터 설정인데, 아래와 같이 IsNative 값을 true로 해주면 gvfs에 의한 자동 마운트가 활성화되지 않는다.

--- /usr/share/gvfs/remote-volume-monitors/mtp.monitor.orig	2017-10-21 00:58:29.063369949 +0900
+++ /usr/share/gvfs/remote-volume-monitors/mtp.monitor	2017-10-21 00:50:04.803710311 +0900
@@ -1,4 +1,4 @@
 [RemoteVolumeMonitor]
 Name=GProxyVolumeMonitorMTP
 DBusName=org.gtk.Private.MTPVolumeMonitor
-IsNative=false
+IsNative=true

MTP 연결을 활용한 백업의 한계

앞서 언급한 내용이긴 한데, 이건 MTP의 한계라기 보다는 Android가 SD Card의 파일시스템을 다루는 방식의 한계다. 위의 방식으로 스마트폰을 마운트하고 최초 복원을 위해(폰을 바꾼 거니까) 백업했던 파일을 밀어 넣었더니, 모든 파일의 Timestamp가 “지금”으로 바뀌어 버린다! 이건 정말 용납할 수 없는 일 아니냐?

결국, 최초의 복원을 위한 동기화는… 아래처럼, SD Card를 어렵게 분리하고, USB 2.0 Card Reader를 하나 구해서… 진행할 수 밖에 없었다. 응, 날짜를 구하기 위해서…

Wifi 연결을 경유한 Rsync 백업

기존의 환경에서도, 백업을 할 때 마다 USB를 연결해야 했던 것이 꽤 부담스러운 일이었다. 특히, 이 갤럭시S3는(다른 녀석들도 그런지는 모르겠는데) 자꾸 붙었다 떨어졌다를 반복하는 현상까지 보였기 때문에 정말 여간 성가신 일이 아니었다.

그런데 만약, Wifi Network을 통해 백업할 수 있다면… 물리적 연결의 귀찮음이 줄어들 것이라는 기대를 할 수 있다. 물론, 전송속도가 USB Cable에 비해 빠르지 않을 수도 있다. 그러니 대용량의 전송 시 시간이 더 걸릴 수도 있을 것이다. 반대로, 절차가 단순해지면 백업의 횟수를 늘릴 수 있을테니, 전체 백업시간은 늘어나더라도 1회 백업시간을 줄어들 수도 있겠다.

Active 또는 Passive

USB Mass Storage를 통한 백업은 한 쪽은 컴퓨터이고 다른 한 쪽은 저장장치라서 이런 방향성에 대한 고민이 필요없다. 그런데 양쪽이 모두 컴퓨터인 상태에서 원격 백업을 하는 상황이 된다면, 어떤 쪽이 능동적으로 제어를 가져가고, 누가 그냥 받아주는 역할을 할 것인지 결정할 필요가 있다.

스마트폰이 제어권을 갖는다면 다음과 같은 특징을 얻을 수 있다.

• 장점:
  • NAS나 Cloud 저장소 등, 저장소가 바뀌거나 제어권을 얻을 수 없더라도 쉽게 적용할 수 있다.
• 단점:
  • 조금 더 무거운 앱을 깔아야 하고,
  • 그 앱의 허용범위가 내가 할 수 있는 일의 한계이다.
  • 백업 기록 등이 데스크톱이 아닌 스마트폰에 남는다.
• 관련 앱: Rsync Wrapper

반대로, 데스크톱을 중심으로 백업을 진행한다면 다음과 같은 상태가 된다.

• 장점:
  • 데스크톱에서 모든 제어를 편리하게 할 수 있다. (자유도 향상)
  • 스마트폰에 구성해야 할 내용이 상대적으로 적다.
• 단점:
  • 데스크톱을 켜지 않고서는 구동이 불가능하다.
• 관련 앱: SSHelper

요즘, 향후에 개인용 NAS를 사용할까 고민하고 있는 상태기 때문에 스마트폰이 능동적으로 백업을 하는 모드에세 대해서도 고민을 해봤다.

SSHelper의 전체 메뉴

앞서 설명했던 SSHelper의 전체 메뉴는 다음과 같이 생겼다. (사실, 설정이나 별도의 메뉴가 없고, 시작페이지가 설정페이지이다.)

보너스: 오래된 앱의 외장 SD Card 접근

그 동안 폰을 바꿀 계획이 없었기 때문에 주의깊게 보지 않았었다. 아무튼, Kitkat 부터인지 Lollipop 부터인지 일반 앱의 외장 SD Card 접근은 원칙적으로 금지되었고, 별도의 권한 허용을 통해서 접근이 가능하다. 그리고 접근을 하더라도 패키지명을 기반으로 정해진 경로에만 접근이 되는데…

최근의 앱이 그런 건지 정확히는 모르겠는데, 해당 경로가 생성되지 않으면 그나마 쓸 수가 없다. 아마도, 일부 오래된 앱은 이 부분에 대한 고려가 되어있지 않은 것 같은데, 그렇다고 Total Commander 같은 파일매니져에서 마음대로 그 경로를 만들어 준다고 한들 먹히지 않는다. (만들 때 소유권과 권한이 붙어버리기 때문인 것 같다.)

그런데 보자, 원래 SD Card의 파일시스템은 유닉스 방식이 아니라서 권한, 소유권의 개념 자체가 없지 않은가? 그래서… 미리 밖에서, 데스크톱 등에 연결해서, 그 경로를 만들어준 다음에 스마트폰에 꽂으면 그 경로를 자동으로 인식한다.

그래서, 아래와 같이 해봤다.

• 외장 메로리에 저장하고 싶지만 할 수가 없었던 앱을 하나 고른다.
• 외장 메모리를 데스크톱에 연결한다.
• 외장 메모리의 앱별 폴거가 위치한 /Android/data 로 이동한다.
• 이 경로 내에 패키지명을 이용해서 폴더를 하나 만든다.
  • org.uguess.android.sysinfo.pro
• 이제 다시 외장 메모리를 스마트폰에 꽂아준다.

아래 그림은, 이렇게 손으로 만든 경로를 Android가 인식한 결과이다.

이제, 위와 같이, 원래는 외장 SDCard에 대한 고려가 없는 것 같았던 Quick System Info PRO에게 외장 SD 내에 접근할 수 있는 경로를 만들어줬다. 그래서 이제, 이 앱의 설정에서 다음과 같이 이 경로를 사용하도록 설정해주면…

ㅋㅋㅋ 원래는 이게 안 되건 건데, 이제 된다. (백업은 외장이지…)