rclone으로 Google Drive에 리눅스 서버 자동 백업하기 (GnuPG 암호화·복구까지)

오늘 서버가 뻗었습니다. 서버는 언제든 다시 접근하지 못할 수 있습니다. Google Drive, rclone, GnuPG를 이용해 비용 부담 없이 백업하고 안전하게 복구하는 방법을 정리했습니다.

오늘 바이브크루 서버가 두 시간쯤 죽어 있었습니다. 원인은 메모리 과부하였고, Cursor Remote가 순간적으로 자원을 크게 물고 늘어지면서 서버가 통째로 먹통이 됐습니다. 모니터링 알림은 제때 왔는데 정작 SSH가 안 붙었습니다. 알림을 보면서 아무것도 못 하는 시간이 제일 길게 느껴지더군요. 다행히 다시 살렸습니다.

그러고 나서 예전에 세팅해 둔 백업을 다시 열어봤습니다. Google Drive에 rclone으로 올리고, 올리기 전에 GnuPG로 암호화하는 구조인데, 한동안 로그만 보고 잘 돌아가려니 하고 지냈던 것들입니다. 오늘 서버가 뻗은 김에 처음부터 다시 훑어봤고, 그 과정에서 정리한 내용을 적어둡니다.

서버는 내가 잘못해서만 죽지 않습니다

제 실수로 죽는 경우는 사실 그나마 나은 편입니다. 원인을 알고 있으니까요. 그런데 하드웨어가 나가거나, 파일시스템이 깨지거나, 클라우드 계정이 정지되거나, 데이터센터 쪽에서 사고가 나는 건 제가 손쓸 수 있는 영역 밖입니다. 여기서 더 나가면 물리 인프라, 그러니까 전쟁 같은 얘기까지 가는데, 개인 서버 하나 굴리면서 전쟁 걱정하는 건 좀 오버일 수 있습니다. 그래도 방향은 같습니다. 내일 이 서버에 못 들어갈 수도 있다는 것.

그래서 백업을 같은 서버 /backup에만 두면 의미가 반쯤 사라집니다. 디스크가 깨지면 백업도 같이 깨지고, 계정이 날아가면 백업도 같이 날아가고, 실수로 지우면 백업도 같이 지워집니다.

상황	같은 서버 /backup	다른 곳
디스크·파일시스템 손상	원본과 백업이 같이 사라짐	남아 있음
실수로 삭제	같이 지워질 확률이 높음	남아 있음
계정 정지, 데이터센터 사고	서버째로 접근 불가	다른 곳에서 복구 가능

데이터가 수십에서 수백 GB쯤 되면 별도 백업 서버나 S3 쪽이 맞습니다. 다만 저처럼 작은 서비스를 돌리고, 매분 단위로 되돌아갈 필요는 없고, 최근 데이터만 살릴 수 있으면 되는 경우에는 Google Drive로도 충분합니다.

무료 15GB는 Drive만의 용량이 아닙니다. Gmail, Photos와 나눠 씁니다. 서버 전체를 넣기에는 작지만, DB 덤프와 설정, 꼭 필요한 파일만 올리면 생각보다 오래 갑니다. 압축한 덤프 하나가 100MB쯤이면 열 개를 둬도 1GB 근처입니다.

	대략
압축한 DB 덤프 1개	100MB
그 덤프 10개	1GB 근처
무료 계정	15GB, Gmail·Photos와 공유

rclone으로 Drive에 올리기

rclone은 클라우드용 rsync에 가깝습니다. Google Drive, S3, OneDrive, Dropbox를 같은 방식으로 다룹니다. 한번 붙여두면 로컬 파일을 옮기듯 씁니다.

rclone copy backup.tar.gz gdrive:backup/

뭐가 올라갔는지는 이렇게 봅니다.

rclone ls gdrive:

rclone lsd gdrive:

1. 설치

sudo -v
curl https://rclone.org/install.sh | sudo bash

설치됐는지 확인합니다.

rclone version

2. Drive 연결

rclone config

새 연결을 만들고, 이름은 gdrive, 종류는 drive로 잡으면 됩니다.

n
gdrive
drive

3. Google API Client ID

2026년 기준으로, 자동 백업을 오래 돌릴 생각이면 Client ID를 직접 만들어 쓰는 편이 안전합니다. Google Cloud Console에서 프로젝트를 만들고, APIs & Services에서 Google Drive API를 켠 다음, OAuth 동의 화면을 설정하고 Credentials에서 OAuth Client ID를 만듭니다. 나온 Client ID와 Secret을 rclone이 물어볼 때 넣으면 됩니다.

4. 브라우저가 없는 서버

서버에는 브라우저가 없으니 로그인 창을 띄울 수가 없습니다. Mac에서 인증을 끝내고, 설정 파일만 서버로 복사하면 됩니다.

brew install rclone

rclone config

인증이 끝나면 설정 파일 위치를 확인합니다. 보통 여기 있습니다.

rclone config file

~/.config/rclone/rclone.conf

서버 쪽에 받을 자리를 먼저 만들어 둡니다.

mkdir -p ~/.config/rclone
chmod 700 ~/.config/rclone

복사한 뒤 권한을 조입니다. 이 파일에는 토큰이 들어 있습니다.

scp ~/.config/rclone/rclone.conf web@SERVER:/home/web/.config/rclone/rclone.conf

chmod 600 ~/.config/rclone/rclone.conf

5. 연결 확인

서버에서 폴더가 보이는지 보고, 백업용 폴더를 만든 다음 작은 파일로 한번 올려봅니다.

rclone lsd gdrive:

rclone mkdir gdrive:server-backup

echo "hello backup" > test.txt

rclone copy test.txt gdrive:server-backup/

평문으로 올리면 백업이 아니라 유출 경로가 됩니다

DB 덤프를 그대로 Drive에 올리면, 구글 계정이 털리는 순간 DB도 같이 넘어갑니다. 그래서 올리기 전에 암호화합니다.

비밀번호로 잠그는 방법도 있는데, 매일 자동으로 돌리려면 그 비밀번호를 결국 서버 어딘가에 둬야 합니다. 그게 계속 찜찜해서 공개키와 개인키로 나눴습니다. 서버에는 공개키만 있어서 잠그기만 하고, 개인키는 서버 밖에 두었다가 복구할 때만 꺼냅니다.

	어디에 두나	무엇을 하나
공개키	백업하는 서버	암호화만
개인키	서버 밖	복구할 때 복호화

도구는 GnuPG입니다. GNU Privacy Guard의 줄임말이고, 명령어는 보통 gpg라고 부릅니다. Werner Koch가 1997년에 시작한 것으로, PGP 계열의 공개키 암호화와 서명을 오픈소스로 구현한 프로그램입니다.

6. 설치

Ubuntu, Debian이면 이렇습니다.

sudo apt update
sudo apt install -y gnupg

RHEL, Rocky, Alma, Oracle Linux면 이쪽입니다.

sudo dnf install -y gnupg2

gpg --version

7. 키 만들기

gpg --full-generate-key

만들 때 만료일이 붙을 수 있습니다. 만료돼도 이미 암호화해 둔 파일은 개인키로 풀립니다. 문제는 그다음입니다. 만료된 키로 새로 암호화하려 하면 자동 백업이 그 단계에서 실패할 수 있습니다.

gpg --list-keys

만료일을 고치려면 키를 열어서 expire를 치거나, 한 줄로 늘리면 됩니다.

gpg --edit-key KEY_ID

expire

gpg --quick-set-expire FINGERPRINT 2y

8. 키를 파일로 빼기

gpg --armor --export backup@example.com > backup-public.asc

gpg --armor --export-secret-keys backup@example.com > backup-private.asc

개인키는 백업 대상 서버에 두지 않습니다.

9. 서버에는 공개키만

gpg --import backup-public.asc

gpg --list-keys

gpg --list-secret-keys

10. 암호화해서 올리기

gpg   --output backup.tar.gz.gpg   --encrypt   --recipient backup@example.com   backup.tar.gz

Drive에는 이 파일만 올립니다.

rclone copy   backup.tar.gz.gpg   gdrive:server-backup/

11. 이걸 스크립트 하나로

매번 손으로 치면 언젠가 빼먹습니다. 덤프를 뜨고, 암호화하고, 평문을 지우고, 올리고, 서버에 남은 암호화 파일까지 지우는 순서를 backup.sh에 넣었습니다. 중간에 하나라도 실패하면 거기서 멈추게 set -euo pipefail을 걸어 뒀습니다. 실패했는데 마지막 줄만 성공으로 찍히면, 그게 제일 위험합니다.

nano ~/backup.sh

#!/usr/bin/env bash

set -euo pipefail

DATE=$(date +"%Y-%m-%d_%H-%M-%S")

BACKUP_DIR="$HOME/backups"
DB_NAME="myapp"
GPG_RECIPIENT="backup@example.com"
REMOTE="gdrive:server-backup"

mkdir -p "$BACKUP_DIR"

DUMP_FILE="$BACKUP_DIR/${DB_NAME}_${DATE}.dump"
ENC_FILE="${DUMP_FILE}.gpg"

echo "[1/5] PostgreSQL backup"

pg_dump   -Fc   "$DB_NAME"   -f "$DUMP_FILE"

echo "[2/5] Encrypt"

gpg   --batch   --yes   --trust-model always   --output "$ENC_FILE"   --encrypt   --recipient "$GPG_RECIPIENT"   "$DUMP_FILE"

echo "[3/5] Remove plaintext"

rm -f "$DUMP_FILE"

echo "[4/5] Upload to Google Drive"

rclone copy   "$ENC_FILE"   "$REMOTE"

echo "[5/5] Remove local encrypted copy"

rm -f "$ENC_FILE"

echo "Backup completed: ${DATE}"

chmod 700 ~/backup.sh
~/backup.sh

MariaDB, MySQL이면

흐름은 같습니다. 덤프를 만들고 같은 공개키로 잠그면 됩니다.

mysqldump DATABASE_NAME | gzip > database.sql.gz

gpg   --output database.sql.gz.gpg   --encrypt   --recipient backup@example.com   database.sql.gz

사이트 파일도 같이

tar -czf site.tar.gz /var/www/myapp

gpg   --output site.tar.gz.gpg   --encrypt   --recipient backup@example.com   site.tar.gz

12. 새벽에 돌리기

crontab -e

0 3 * * * /home/web/backup.sh >> /home/web/backup.log 2>&1

13. 오래된 파일은 지우기

안 지우면 15GB는 금방 찹니다. 예를 들어 14일이 지난 암호화 파일을 지우는 식으로 돌리면 됩니다. 서비스에 따라 7일, 30일, 주간이나 월간으로 따로 남겨도 됩니다.

rclone delete   gdrive:server-backup   --min-age 14d   --include "*.gpg"

최신 파일 하나만 고정된 이름으로 두고 싶으면 이렇게도 됩니다.

rclone copyto   latest.dump.gpg   gdrive:server-backup/latest.dump.gpg

이것만 쓰면 위험합니다. 데이터가 이미 깨진 상태에서 백업이 돌면, 그 깨진 덤프가 그 전 정상본을 덮어씁니다. 과거 몇 개는 남겨 두는 편이 안전합니다.

14. 복구 방법을 백업 옆에 두기

급할 때 글을 찾아다닐 여유가 없습니다. 백업 폴더 안에 복구 순서를 같이 넣어 둡니다.

server-backup/
├── myapp_2026-09-21.dump.gpg
├── myapp_2026-09-20.dump.gpg
└── README-RESTORE.txt

문서에는 이 정도만 적어도 됩니다.

rclone 설치
Google Drive 연결
GPG 개인키 import
백업 다운로드
복호화
DB restore

15. 실제로 되돌리는 명령

rclone copy   gdrive:server-backup/myapp_2026-09-21.dump.gpg   ./

gpg --import backup-private.asc

gpg   --output myapp.dump   --decrypt   myapp_2026-09-21.dump.gpg

PostgreSQL이면 빈 DB를 만들고 그 안으로 넣습니다.

createdb myapp

pg_restore   -d myapp   myapp.dump

여기서 하나 더 있습니다. 스크립트가 Backup completed를 찍었다고 끝이 아닙니다. 진짜 백업은 복구해 본 백업입니다. 파일을 내려받고, 풀고, 운영 DB가 아닌 다른 DB에 넣은 다음, 데이터가 맞는지 봐야 합니다. 한 번만 해봐도 문서에서 빠진 단계가 바로 나옵니다.

지금 돌아가고 있는 구조

오늘 새로 만든 게 아닙니다. 예전에 세팅해 두고, 오늘 다시 열어본 흐름입니다.

어디서	무엇을
서비스 서버	DB 덤프, 압축, 공개키 암호화, 평문 삭제
rclone	암호화된 파일만 Google Drive로
Google Drive	기간이 지난 파일은 삭제
서버 밖	개인키. 복구할 때만 사용

서버가 털리면 Drive 파일도 지울 수 있습니다

맞습니다. 서버에 rclone 토큰이 있으니, 서버가 완전히 털리면 Drive에 있는 백업까지 지워질 수 있습니다. 암호화돼서 내용을 못 보는 것과, 파일 자체가 사라지는 것은 다른 문제입니다.

서비스가 더 중요하면 백업 계정을 따로 두거나, Object Lock, Immutable Backup, S3, NAS, 다른 리전, 오프라인 사본까지 가는 게 맞습니다. 지금 규모에서는 여기까지입니다.

서버가 멀쩡할 때 해야 합니다

평소에는 백업이 계속 뒤로 밀립니다. 기능을 하나 더 붙이고 싶고, UI를 고치고 싶고, AI를 얹고 싶습니다. 백업은 화면에 나오지도 않고 재미도 없습니다. 그러다 장애가 나면 순위가 통째로 뒤집힙니다.

기준도 그때 바뀝니다. 파일이 어딘가 있느냐가 아니라, 서버를 통째로 잃어도 다시 살릴 수 있느냐입니다. 오늘 서버가 뻗고 나서야 예전에 해 둔 걸 다시 열어봤는데, 이런 건 서버가 잘 돌아갈 때 해둬야 합니다. 죽고 나서 시작하면 이미 늦습니다.