Obsidian 백업을 Google Drive로 하루 2번. Mac rsync와 일본어 파일명의 함정

안녕하세요. まさきん입니다.

Obsidian 노트 전체를 Google Drive로 매일 백업하도록 해 두었습니다. Mac 기본 rsync로 복사하기만 하면 될 줄 알았는데, 긴 일본어 파일명 때문에 한 번 실패했습니다. 같은 곳에서 멈추는 분이 있을 것 같아서, 순서와 회피책을 메모해 둡니다.

※ 글을 공개한 시점의 정보입니다. 최신 조건은 공식 사이트에서 확인해 주세요.

왜 백업처를 하나 더 늘렸나

Obsidian의 노트 전체는 ‘볼트’라고 부릅니다. 제 볼트는 지금까지 GitHub에 백업하고 있었습니다. 다만 백업처가 하나뿐인 것은 조금 불안하다고 느끼고 있었습니다.

그래서 또 하나의 보관 장소로 Google Drive를 골랐습니다. 데스크톱용 Google Drive의 내 드라이브 아래에 폴더를 하나 준비합니다. 거기에 rsync로 증분을 복사하는 형태입니다.

얼마 전에 Obsidian Sync를 해지한 이야기를 썼습니다. 메모의 원본은 Notion으로 옮겼지만, 볼트의 파일 자체는 로컬에 남아 있습니다. 동기화를 그만둔 만큼, 백업은 스스로 갖고 있고 싶다고 생각했습니다.

볼트는 그냥 폴더

Obsidian 공식 도움말에는 노트가 Markdown 형식의 텍스트 파일로 저장된다고 나와 있습니다. 볼트는 로컬 파일 시스템상의 폴더입니다. 하위 폴더도 포함됩니다.

설정은 볼트 바로 아래의 .obsidian 폴더에 들어갑니다. 단축키나 테마 등이 여기에 놓인다는 설명입니다.

즉, 백업에 특별한 도구는 필요 없습니다. 폴더를 다른 장소로 복사하면 그것이 백업이 됩니다. rsync를 쓸 수 있는 것은 이 구조 덕분이네요.

동기화와 백업은 다른 것

Obsidian 공식 도움말은 동기화와 백업을 나눠서 설명합니다. 동기화는 노트를 최신 상태로 유지합니다. 다만 데이터 손실로부터는 지켜 주지 않는다는 안내입니다.

이번에 하는 것은 오른쪽의 백업입니다. Google Drive의 폴더를 Obsidian으로 여는 일은 하지 않습니다. 어디까지나 복사해 둔 곳으로만 둡니다.

공식 도움말에는 같은 볼트를 여러 서비스로 동기화하지 말라는 주의도 있습니다. 데이터의 충돌과 손상을 피하기 위해서입니다. 백업처를 직접 편집하지 않는 것은 이 주의와도 맞는 형태라고 생각합니다.

전체 구성

구조는 부품 세 개뿐입니다.

1. 볼트 폴더(예: ~/Notes)
2. Google Drive의 내 드라이브 아래에 있는 백업 폴더
3. rsync를 부르는 셸 스크립트와, 그것을 정시에 돌리는 launchd

rsync가 로컬 폴더로 복사합니다. 거기서부터의 업로드는 데스크톱용 Google Drive의 일입니다. 스크립트는 클라우드 API를 부르지 않습니다.

미러링과 스트리밍의 차이

데스크톱용 Google Drive에는 내 드라이브를 다루는 방식이 두 가지 있습니다. 공식 도움말의 설명을 표로 정리했습니다.

macOS의 스트리밍은 Finder 사이드바의 ‘위치’에 표시됩니다. 기본 위치는 ~/Library/CloudStorage 이고, 변경할 수 없다고 합니다.

rsync의 복사 대상으로 생각하면 이렇게 정리될 것 같습니다. 미러링은 복사한 결과가 로컬에도 통째로 남습니다. 그만큼 볼트와 백업이 이중으로 용량을 씁니다. 스트리밍은 용량을 아낄 수 있지만, 파일의 실체는 주로 클라우드 쪽입니다.

어느 쪽이 정답인지는 디스크 여유 공간에 달렸다고 생각합니다. 수 GB 규모라면 미러링의 부담은 작을지도 모릅니다. 참고로 Obsidian 공식 도움말에는 Google Drive에 두는 볼트에 대한 안내가 있습니다. 오프라인에서 쓸 수 있는 설정으로 하라는 내용입니다. 이것은 동기화 용도의 이야기이지만, 사고방식은 참고가 될 것 같습니다.

rsync 기본 명령

뼈대는 이 정도입니다. 경로는 일반화한 예시로 했습니다.

#!/bin/bash
SRC="$HOME/Notes/"
DEST="$HOME/GoogleDrive/vault-backup/"

rsync -a --inplace \
  --exclude '.venv/' \
  --exclude 'node_modules/' \
  --exclude '.cache/' \
  --exclude 'tmp/' \
  --exclude '.env' \
  --exclude '*.token' \
  "$SRC" "$DEST"
rc=$?
echo "$(date '+%F %T') rc=$rc" >> "$HOME/Library/Logs/vaultbackup.log"
exit $rc

DEST 는 본인의 내 드라이브 아래 실제 경로로 바꿉니다. 스트리밍이라면 ~/Library/CloudStorage 아래가 됩니다.

쓰는 옵션은 적은 편입니다.

--delete 를 붙이면 원본에서 지운 파일이 백업처에서도 지워집니다. 동작은 동기화에 가까워집니다. 실수로 지운 노트를 남기고 싶다면 붙이지 않는 선택도 있다고 생각합니다.

원본 경로 끝의 슬래시에도 주의가 필요합니다. 붙이면 ‘폴더의 내용물’을 복사합니다. 붙이지 않으면 폴더째로 한 단계 더 깊이 들어갑니다.

백업에서 뺄 것의 기준

볼트 안에는 노트 이외의 것도 섞이기 쉽습니다. 저는 다음 네 종류를 대상에서 뺐습니다.

판단의 축은 두 가지라고 생각합니다. 다시 만들 수 있는 것은 뺀다. 새면 곤란한 것도 뺀다. 이 두 가지입니다.

비밀 정보는 백업처가 늘수록 놓이는 장소도 늘어납니다. 그래서 처음부터 대상에 넣지 않는 형태로 했습니다. 비밀 정보를 찾는 방법은 gitleaks에서 ‘no leaks’였는데도 샌 2건의 이야기에도 썼습니다.

제외 지정은 -n 을 붙인 시험 실행으로 확인할 수 있습니다. -v 도 더하면 복사할 예정인 파일이 목록으로 나옵니다. 비밀 파일명이 나오지 않는지 봐 두면 안심이지요.

걸림돌: 긴 일본어 파일명에서 실패했다

첫 실행은 도중에 멈췄습니다. 원인은 긴 일본어 파일명을 가진 파일입니다.

오류에 나온 것은 mkstempat 이라는 함수명이었습니다. 임시 파일 생성에 실패했다는 내용입니다. 임시 파일의 이름이 255바이트를 넘은 것이 원인이었습니다.

구조는 이렇습니다. rsync는 보통 복사 대상에 임시 파일을 만듭니다. 전송이 끝나면 원래 이름으로 옮깁니다. samba.org의 rsync man 페이지에도 이 기본 동작이 적혀 있습니다.

임시 파일의 이름은 원래 이름보다 길어집니다. 원래 이름이 아슬아슬하게 들어가는 길이여도, 임시 파일의 이름은 상한을 넘는 경우가 있는 것입니다.

255바이트는 일본어로 몇 글자인가

macOS의 헤더에서는 NAME_MAX 가 255로 정의되어 있습니다. 주석은 ‘파일명의 최대 바이트 수’입니다.

여기부터는 계산입니다. 일본어의 많은 글자는 UTF-8에서 1글자 3바이트가 됩니다. 255를 3으로 나누면 85입니다. 즉, 일본어만으로 된 이름이라면 약 85글자가 기준이 됩니다. 확장자나 반각 문자가 섞이면 숫자는 조금 달라집니다.

한편 이야기는 조금 복잡합니다. Apple 개발자 포럼에서는 Apple의 지원 담당자가 다른 설명도 하고 있습니다. APFS 자체의 상한은 255글자이고, NAME_MAX 와는 맞지 않는다는 내용입니다. 상한은 볼륨의 형식에 따라 달라진다고도 적혀 있었습니다.

그래서 저는 ‘약 85글자’를 안전한 쪽의 기준으로 다루고 있습니다. 복사 대상 폴더가 어떤 구조 위에 있느냐에 따라 적용되는 상한은 달라질 수 있습니다.

회피책은 —inplace

대처는 옵션을 하나 더하는 것뿐이었습니다. --inplace 입니다.

openrsync의 man 페이지에서는 임시 파일을 만들지 않고 복사 대상의 파일을 직접 조작한다고 설명합니다. 임시 파일을 만들지 않으니 이름이 길어지는 문제도 생기지 않습니다. 제 환경에서는 이것으로 끝까지 통과했습니다.

다만 대가로 치르는 것도 있습니다. samba.org의 man 페이지가 드는 주의점은 이런 것들입니다.

• 전송 중에는 복사 대상의 파일이 어중간한 상태가 된다
• 도중에 멈추면 그 어중간한 상태가 남을 수 있다
• 다른 사람이 열고 있는 파일의 갱신에는 쓰지 않는다

이번 복사 대상은 아무도 열지 않는 백업 폴더입니다. 멈추더라도 다음 실행에서 다시 복사됩니다. 그래서 이 용도라면 받아들일 수 있는 대가라고 판단했습니다.

파일명 쪽을 짧게 하는 방법도 있습니다. 그렇다고는 해도 약 2만 개 파일의 이름을 고치는 것은 현실적이지 않았습니다.

macOS의 rsync는 openrsync

애초에 Mac의 rsync는 예전과 내용물이 다릅니다. 최근의 macOS에서는 기본 rsync가 openrsync라는 구현으로 되어 있습니다.

Apple은 rsync의 소스를 공개하고 있습니다. 그 저장소에는 openrsync 디렉터리가 포함되어 있습니다. man 페이지의 이름도 ‘openrsync’입니다. samba.org판의 프로토콜 27〜29와 호환된다고 설명되어 있습니다.

바뀐 시기는 macOS Sequoia 15.4 전후라고 합니다. 다만 Apple의 공식 릴리스 노트에서는 확인하지 못했습니다. 그래서 여기는 ‘라고 합니다’에 그치겠습니다.

실무상의 주의는 하나입니다. 인터넷에서 찾은 rsync 예시가 그대로 동작한다고는 할 수 없습니다. 쓸 옵션은 로컬에서 man rsync 를 찾아보고 확인하는 것이 좋겠습니다.

launchd로 하루 2번 실행하기

정시 실행은 launchd에 맡겼습니다. Apple의 개발자용 문서에서는 cron을 아직 쓸 수는 있지만 권장하지 않습니다. launchd를 쓰라고 안내합니다.

시각 지정은 StartCalendarInterval 이라는 키입니다. plist의 뼈대는 이렇게 됩니다. 작업 이름과 시각은 예시입니다.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
  "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>com.example.vaultbackup</string>
  <key>ProgramArguments</key>
  <array>
    <string>/bin/bash</string>
    <string>/Users/yourname/bin/vaultbackup.sh</string>
  </array>
  <key>StartCalendarInterval</key>
  <array>
    <dict>
      <key>Hour</key><integer>3</integer>
      <key>Minute</key><integer>30</integer>
    </dict>
    <dict>
      <key>Hour</key><integer>13</integer>
      <key>Minute</key><integer>30</integer>
    </dict>
  </array>
  <key>StandardOutPath</key>
  <string>/tmp/vaultbackup.out.log</string>
  <key>StandardErrorPath</key>
  <string>/tmp/vaultbackup.err.log</string>
</dict>
</plist>

launchd.plist 의 man 페이지에 따르면 시각의 딕셔너리는 여러 개 나열할 수 있습니다. 하루 2번이라면 딕셔너리를 2개 쓰는 형태입니다. 쓰지 않은 항목은 ‘전부’로 취급됩니다.

저는 새벽과 이른 오후의 2번으로 했습니다. 새벽은 전날 분을 건지는 역할입니다. 이른 오후는 오전 작업을 건지는 역할이 됩니다.

잠자기 중의 취급은 cron과 다릅니다. Apple의 문서에는 예정 시각에 잠자기 상태였던 경우 깨어났을 때 실행된다고 나와 있습니다.

cron 작성법에 익숙한 분은 cron의 일과 요일의 함정을 다룬 글도 함께 보세요. 정시 실행은 써 놓은 뒤의 검산이 중요하다고 생각합니다.

첫 실행과 정시 실행의 결과

첫 실행은 약 2만 개 파일·수 GB 규모였습니다. --inplace 를 붙인 뒤의 첫 실행은 정상적으로 끝났습니다. 종료 코드는 0이었습니다.

launchd에서의 정시 실행도 마찬가지로 0으로 끝났습니다. 손으로 돌렸을 때와 정시에 돌았을 때. 양쪽을 확인한 것은 동작하는 환경이 조금 다르기 때문입니다.

다만 이것은 ‘로컬의 백업 폴더로 복사했다’는 의미입니다. 클라우드로의 업로드는 다른 이야기입니다. 첫 업로드는 시간이 걸리고 있습니다. 이 글을 쓰는 시점에는 완료를 아직 확인하지 못했습니다. 그래서 그 결과는 쓰지 않습니다.

클라우드 쪽 확인은 주 1회

rsync의 종료 코드가 0이어도 클라우드에 도착했다고는 할 수 없습니다. 그래서 도착했는지의 확인을 따로 두었습니다. 빈도는 주 1회뿐입니다.

보는 것은 두 가지입니다.

1. 새로움: 클라우드 쪽 파일이 최근 날짜로 되어 있는가
2. 내용: 파일을 실제로 열어서 읽을 수 있는가

날짜만이라면 망가진 파일도 새것으로 보입니다. 열어서 읽는 데까지 해야 비로소 ‘되돌릴 수 있는 백업’이라고 할 수 있지 않을까요.

매일 하지 않는 것은 오래 못 가기 때문입니다. 여기는 주간으로 충분하다고 생각했습니다.

실패 알림은 스크립트에 맡기지 않는다

실패했을 때의 알림은 스크립트에서 보내지 않습니다. 이미 있는 감시 체계에 맡기는 설계로 했습니다.

스크립트의 역할은 두 가지뿐입니다. 복사하는 것. 종료 코드를 로그에 남기는 것. 이 두 가지입니다.

알림까지 넣으면 알림처 설정이나 비밀 정보가 스크립트에 섞여 듭니다. 감시를 한곳에 모아 두면 작업이 늘어도 고칠 곳은 하나입니다.

Time Machine을 보류한 이유

Mac이라면 Time Machine도 후보가 됩니다. Obsidian 공식 도움말도 OS의 도구로 들고 있습니다.

다만 제 Mac에서는 저장 위치가 설정되어 있지 않았습니다. 그대로는 쓸 수 없습니다. Apple의 지원 페이지에 따르면 외장 저장 장치가 필요합니다. 용량은 Mac의 2배 이상이 기준이라고 합니다.

이번에는 거기까지 준비하지 않고 보류했습니다. Time Machine은 Mac 전체를 지키는 도구입니다. 볼트만 다른 장소로 피신시키는 이번 목적과는 역할이 조금 다를지도 모릅니다.

흔한 실수와 함정

구성해 보면서 걸려 넘어지기 쉽다고 느낀 점을 나열합니다.

• 긴 일본어 파일명에서 임시 파일을 만들지 못해 실패한다
• 인터넷의 rsync 예시를 openrsync에서 그대로 쓰려고 한다
• 원본 경로 끝의 슬래시를 빠뜨려서 한 단계 깊이 복사해 버린다
• .env 나 토큰을 제외하지 않고 클라우드에 올려 버린다
• 종료 코드 0을 보고 클라우드에도 도착했다고 믿어 버린다
• 백업처 폴더를 Obsidian으로 열어서 편집해 버린다

제가 실제로 밟은 것은 첫 번째입니다. 다섯 번째는 주 1회 확인으로 막을 생각입니다.

시작하기 전에 확인할 것

자주 묻는 질문

Q. Obsidian 백업은 Google Drive만으로 충분한가요?

한 곳뿐이면 거기를 쓸 수 없을 때 곤란합니다. Obsidian 공식 도움말도 클라우드는 물리적 저장의 대안이자 보완이기도 하다고 설명합니다. 저는 GitHub와 함께 두 곳으로 했습니다.

Q. Google Drive에 둔 볼트를 직접 열어도 되나요?

Obsidian 공식 도움말에서는 Google Drive를 통한 동기화가 공식적으로는 지원되지 않는다고 합니다. 이번 구성에서도 백업처는 열지 않는 것이 전제입니다. 편집은 원본 볼트에서만 하는 것이 안전하다고 생각합니다.

Q. --inplace 는 항상 붙여도 되나요?

용도에 따라 다릅니다. 전송 중에는 복사 대상이 어중간한 상태가 된다는 주의가 man 페이지에 있습니다. 아무도 열지 않는 백업처라면 영향은 작다고 할 수 있을 것 같습니다.

Q. Homebrew의 rsync를 설치하는 방법은 어떤가요?

samba.org판 rsync를 따로 설치하는 방법도 있습니다. 다만 저는 시도해 보지 않았습니다. 이번에는 --inplace 를 더하는 형태로 대처했습니다.

Q. 하루 2번은 너무 많지 않나요?

rsync는 차분만 복사합니다. 변경이 없으면 거의 아무것도 하지 않고 끝납니다. 횟수를 늘려도 부담은 작으니, 잃어도 괜찮은 시간의 폭으로 정하는 것이 좋을지도 모릅니다.

Q. Mac이 잠자기 상태였으면 어떻게 되나요?

Apple의 문서에서는 잠자기 중에 시각이 지난 작업은 깨어났을 때 실행됩니다. 전원이 꺼져 있었던 경우의 취급은 따로 확인이 필요합니다.

Q. 원본에서 노트를 지우면 백업처에서도 지워지나요?

--delete 를 붙이지 않았다면 백업처에는 남습니다. 붙이면 원본에 없는 파일은 백업처에서도 지워집니다. 어느 쪽으로 할지는 백업에 무엇을 기대하느냐로 정해집니다.

Q. 업로드가 끝났는지는 어디에서 보나요?

데스크톱용 Google Drive 앱에서 동기화 상황을 확인할 수 있습니다. 저는 첫 업로드의 완료를 아직 확인하지 못했습니다. 주 1회 확인에서, 열어서 읽을 수 있는 데까지 볼 예정입니다.

참고한 공식 정보

• How Obsidian stores data(Obsidian Help)
• Back up your Obsidian files(Obsidian Help)
• Sync your notes across devices(Obsidian Help)
• 데스크톱용 Drive 사용하기(Google Drive 고객센터)
• 파일 스트리밍과 미러링(Google Drive 고객센터)
• macOS에서 데스크톱용 Drive 사용하기(Google Drive 고객센터)
• rsync(1) man 페이지(samba.org)
• rsync 소스(Apple OSS Distributions)
• Scheduling Timed Jobs(Apple Developer)
• How to query APFS file name size limit?(Apple Developer Forums)
• Time Machine으로 Mac 백업하기(Apple 지원)

정리

Obsidian의 볼트는 그냥 폴더입니다. 그래서 rsync와 launchd만으로 매일의 백업을 구성할 수 있었습니다.

걸려 넘어진 곳은 긴 일본어 파일명이었습니다. --inplace 를 하나 더하면 통과하지만, 대가가 있다는 것은 알아 두고 싶은 부분입니다.

클라우드에 도착했는지의 확인은 이제부터입니다. 우선 -n 시험 실행부터, 가지고 계신 볼트로 시도해 보면 어떨까요.

백업 같은 ‘매달의 체계’를 정비했다면, 매달의 통신비도 같은 눈으로 점검할 수 있을지도 모릅니다.

이 글에는 제휴 광고가 포함되어 있습니다. 이 사이트의 링크를 통해 상품·서비스에 신청하시면 제휴사로부터 보상을 받을 수 있습니다. 또한 운영자는 라쿠텐 그룹 소속 직원으로, 사원 추천 프로그램을 통해 보상을 받는 경우가 있습니다. 기사 내용과 평가는 광고 유무와 관계없이 운영자의 실제 경험과 조사를 바탕으로 작성했지만, 위 관계를 이해하신 후 읽어 주시기 바랍니다. 자세한 내용은 면책조항·제휴 링크 안내를 참고해 주세요. 면책조항·제휴 링크 안내

이 글에는 기계 번역이 포함되어 있습니다. 정확한 조건은 라쿠텐 모바일 공식 사이트의 다국어 페이지에서 확인해 주세요.

라쿠텐 모바일의 통신 지역·전파 상황이 궁금하신 분은, 공식 전파 개선·조사 요청 양식 을 통해 문의하실 수 있습니다.