오라클 클라우드에 도커로 워드프레스 구축하고 백업하기

728x90

개요

1년도 더 전에 오라클 프리티어 A1을 만들어두고 구글 드라이브 무제한과 연동한 노하드 Plex 라이브러리를 구축하려 했으나, 구글의 통수를 씨게 얻어맞은 후로, 오라클 프리티어를 마땅히 굴릴 구석 없이 썩히고만 있었습니다.

그러던 중, 블로그를 해보고 싶은 생각에 티스토리를 아주 잠깐 시도했는데, 글 4개 정도 쓰자마자 내 블로그임에도 불구하고 멋대로 광고를 넣어버리기 시작하는 만행에 분노하며 구축형 블로그에 눈길을 돌리게 됩니다.

구축형 블로그에 대해 알아보며 다양한 선택지를 알게 되었는데, 그 중 워드프레스를, 그것도 도커로 선택한 이유는 아래와 같습니다.

Reference가 아주 많아야 함(직접 구축하고 호스팅하고 관리를 해야 하는데, 나는 초보니까)
구축이 쉬워야 함(맨 처음 워드프레스 설치방법을 검색해보다가 바로 카페24호스팅을 보고 있었음… 그러다가 이거저거 굴려보면서 좀 친숙해진 도커를 이용해 구축하기로 결정)
글을 쓰면 바로 반영이 되어야 함(노션으로 만드는 블로그는 github에 여러 가지 솔루션이 있었으나, 그 중 일부는 글 작성/수정 내용이 즉각 반영이 되지 않거나, deploy를 해야만 반영이 되었음. 혹은 우피라는, 비교적 요금부담이 큰 서비스를 이용해야 했음)

~~이런 이유로, 이 블로그는 오라클 프리티어 A1에서, 도커로 돌아가는 중입니다.~~(현재는 아님)

돌리고 나서 보니, 홈서버와 마찬가지로 백업과 복원까지 스스로 알아서 해야 했고(유료 호스팅은 대체로 지원되는 곳이 많음),
이런 문제들에 대해 웹 서칭, GPT갈구기 등을 통해 나름의 답을 찾은 후 내용을 남기기 위해 글을 써 봅니다.

워드프레스 도커로 설치

Docker-compose 이용하기

이 부분은 docker-compose를 이용해서 진행했습니다. 저는 오라클에 Portainer를 올려두고 컨테이너 관리는 이 쪽에서 하고 있으므로, Portainer에서 Stack으로 관리합니다.

services:
  db:
    image: mariadb:latest
    command: '--default-authentication-plugin=mysql_native_password'
    container_name: mariadb
    volumes:
      - /docker/wordpress/db:/var/lib/mysql
    restart: always
    environment:
      - MYSQL_ROOT_PASSWORD=
      - MYSQL_DATABASE=
      - MYSQL_USER=
      - MYSQL_PASSWORD=
    labels:
      - "com.centurylinklabs.watchtower.enable=false"
    expose:
      - 3306
      - 33060
      
  wordpress:
    image: wordpress:latest
    container_name: wordpress
    ports:
      - 80:80
    volumes:
      - /docker/wordpress/www:/var/www/html
    restart: always
    environment:
      - WORDPRESS_DB_HOST=db
      - WORDPRESS_DB_USER=
      - WORDPRESS_DB_PASSWORD=
      - WORDPRESS_DB_NAME=
    labels:
      - "com.centurylinklabs.watchtower.enable=false"

강조 표시 된 부분만 각자의 환경에서 사용할 값을 넣어주면 됩니다.

워드프레스 초기 세팅

도커가 구동된 것을 확인하면 해당 주소로 접근해 줍니다. 오라클일 경우 공인IP 혹은 미리 연결해놓은 도메인으로 접근할 수 있고, 저는 블로그를 작성하기 위해 별도의 VM에 새로 설치한 워드프레스로 접속했습니다.

접속하면, 아래와 같은 언어 설정창이 반겨줍니다. 언어를 선택한 뒤 기본적인 사이트 설정에 필요한 값들을 입력하고 워드프레스 설치를 클릭하시면 곧바로 워드프레스를 사용할 수 있습니다.

글 작성, 카테고리, 메뉴, 테마 등, 워드프레스 운영과 관련된 내용을 위한 글은 아니므로, 백업과 복원에 관한 내용으로 넘어가겠습니다.

워드프레스 백업하기

백업의 필요성

생각보다 간편하게 워드프레스를 설치한 뒤, 티스토리에 있던 몇 개 안되는 글을 옮겨놓고 나서, 가장 먼저 들었던 생각은

글 쓰는 도중에 페이지를 잘못 이동해 쓰던 글을 날리기만 해도 화가 나는데, 블로그를 통째로 잃어버리면 얼마나 화가 날까..?

였습니다.. =ㅅ=

이 블로그는 언제 잃어버릴지 모르는 오라클 프리티어 위에서 돌아가고 있기 때문에, 자고 일어나면 VM을 잃어버릴 수도 있고, 그럴 경우 (아마도) 데이터 디스크에 접근할 수가 없으니, 블로그 데이터 일체를 잃어버릴 가능성이 매우 높습니다.

그건 안될 말이지!!!!!!!!!!!!!!!!!!

백업 수단 정하기

백업 및 복원에 대해 여러가지를 찾아본 결과 대체로 플러그인을 활용한 방법들이었는데, 유료결제 없이는 원활한 복원이 어려워보여 배제하기로 했습니다.

헤놀로지의 Active backup을 사용하는 방법도 생각해봤지만, 리눅스 kernel버전에 영향을 많이 받는다(카더라)고 알고 있어 이것도 배제했습니다. 무엇보다, 헤놀로지를 운용하면서 세 번 정도 데이터가 박살난 경험이 있다 보니, 믿음이 가질 않았습니다.

그러던 중, 넷마블 기술 블로그에서 쉘 스크립트로 백업과 복원 하는 글을 찾게 됩니다. 해당 블로그는 도커로 구축한 블로그는 아니지만, 방식은 동일하게 적용할 수 있었기에 이 방법을 따라가기로 결정합니다.

또한, 스냅샷 마냥 코어, 테마, 플러그인 업데이트를 미리 돌려보고 결과가 이상할 경우 바로바로 롤백을 할 수 있는 테스트 환경이 필요하다고 생각하던 참에, 해당 블로그의 글이 이 내용까지 설명해주고 있어, 잘 따라갈 수 있었습니다.

단, 해당 블로그는 DB를 직접 밀어넣어 복원하지만, 이 글에선 모두 압축으로 진행합니다.

백업 구조

백업의 가장 큰 목적이, 오라클 프리티어 증발에 대비하기 위함이기 때문에, 백업파일을 생성하고 그대로 오라클에 올려두는 것은 어불성설입니다. 맨 처음에는 생성된 백업파일을 바로 홈서버 스토리지에 저장하는 방향이었는데, 2차 백업이 필요하다는 생각이 들어 구글 드라이브를 경유하기로 했습니다.

따라서 구조는, 오라클 → 구글 드라이브 → 홈서버 로 결정됩니다.

백업파일 생성하기

위 docker-compose를 보면, 워드프레스와 MariaDB의 데이터가 각각

워드프레스 : /docker/wordpress/www
MariaDB : /docker/wordpress/db

이렇게 위치해 있습니다.

그러니, /docker/wordpress 경로를 tar로 묶어 일괄처리하려고 합니다.
DB는 보통 분리되어 있는 DB서버에서 관리되기 때문에, 따로 백업을 하는 것이 정석이지만, 제 환경은 오라클 클라우드 위에 DB컨테이너와 워드프레스 컨테이너를 같이 구동 중이고, 이 DB는 워드프레스에서만 사용하고 있어 이와 같이 진행합니다.

tar -zcf /data/wpbackup/backup.tar.gz /docker/wordpress -P

이제 이걸, 구글 드라이브에 업로드 해야 하는데.. 리눅스, 구글 드라이브 하면 Rclone이죠.
Rclone에 구글 드라이브를 연동해준 뒤, 명령어 한 줄만 입력해주면 업로드할 수 있습니다.

rclone copy /data/wpbackup gd: --metadata --verbose

이제 이 단순한 과정을 스크립트로 만들어 봅시다.

이 때, 동일한 작업을 여러번 해야 하므로, 파일 이름엔 날짜와 시간을 넣고, 워드프레스 데이터 경로와 백업 파일 저장 경로 등을 변수로 지정해 추후 폴더 경로 변경을 대비하는 것이 좋겠죠.

또, 구글 드라이브 용량은 한정되어 있기 때문에, 무한정 백업을 쌓을 순 없습니다. 그래서 구글 드라이브에 저장해두는 백업파일은 최대 30일까지만 유지하려고 합니다. 구글 드라이브에 모두 올렸다가 지우는 것보단, 올리는 원본부터 관리하면 편하겠죠? 그래서 스크립트 내에서 30일 지난 백업파일은 제거하도록 했습니다.

그렇게 아래와 같은 스크립트를 작성했습니다(gd는 rclone에 등록한 구글 드라이브입니다).

#!/bin/bash

# 백업 디렉토리 설정
backup_dir="/data/wpbackup"

# 워드프레스 설치 디렉토리 설정
wordpress_dir="/docker/wordpress"

# 백업 파일 이름 생성
wordpress_file="wordpress_$(date +%Y%m%d_%H%M%S).tar.gz"

# 백업 파일을 저장할 서버 정보
backup_server_host="gd:"

# 백업함수
backup_wp() {
echo "Job start!"
sudo tar -zcf "$backup_dir/$wordpress_file" "$wordpress_dir/" -P
}

# 30일 경과 파일삭제 함수
backup_del_30() {
echo "Removing backup files > 30 days"
sudo find "$backup_dir" -name "wordpress_*" -mtime +30 -exec rm {} \;
}

# 구글 드라이브 동기화함수
backup_web_sync() {
echo "Syncing Google drive"
rclone sync "$backup_dir" "$backup_server_host" --metadata --verbose
}

# 함수 호출
run_backup() {
backup_wp
backup_del_30
backup_web_sync
}

run_backup

이제 이걸 crontab에 등록해 반복작업을 시켜줍니다.

매일 23:50에 백업을 진행하고 결과를 같은 폴더 내에 log로 저장하겠습니다.

crontab -e
50 23 * * * /home/script/wpbackup.sh >> /home/script/wpbackup.sh.log 2>&1

여기까지 진행했다면, 아래처럼 백업파일을 구글 드라이브에서 직접 확인하실 수 있습니다.

백업파일 2차 저장

매일매일 규칙적으로 백업 및 구글 드라이브 업로드까지 이루어지지만, 이것만으론 테스트 환경을 만들 수 없습니다. 거기다, ‘클라우드에 올라간 자료는 내 것이 아니다’ 라는 말이 있는 만큼, 생성된 백업파일들을 별도의 스토리지 서버에 저장하겠습니다.

이 과정은 별로 어려울 것이 없습니다.

저는 스토리지 서버로 TrueNAS를 사용 중이고, TrueNAS는 Rclone을 문제 없이 설치 및 구동할 수 있기 때문에, 딱 한 줄의 스크립트만 작성해주면 됩니다.

#!/bin/bash

#구글 드라이브 파일 내려받기
rclone copy gd: /mnt/fenta-pbs/wordpress --metadata --verbose

각자의 저장소 환경에 맞춰 /mnt/fenta-pbs/wordpress 부분만 수정하면 됩니다.

이 때, 오라클 → 구글 드라이브로 업로드할 때는 sync를 사용했지만, 스토리지에 저장할 때는 copy를 사용한 이유는

30일 경과한 파일을 오라클 클라우드에서도 제거하고, 구글 드라이브에서도 찾아 지우는 것은 비효율적이므로, 스크립트를 통해 30일 이내 버전을 관리하고 있는 폴더를 그대로 구글 드라이브와 동기화 시켜 구글 드라이브도 자동적으로 파일 관리를 하기 위함입니다. 반대로 스토리지에 다운로드 받을 때는, 만들어졌던 백업파일을 모두 저장하기 위함입니다.

이제, 이 스크립트를 다시 crontab에 등록해주면 됩니다.

오라클에서 백업작업을 시작하는 시간은 23:50이고, 현재는 블로그 데이터가 많지 않아(파일 한개당 500MB 미만) 아래처럼 업로드 시간이 1분이 채 걸리지 않지만

용량이 커졌을 때를 대비해 시간 여유를 좀 두어서 새벽 2시에 작업이 이루어지도록 하겠습니다.

0 2 * * * /mnt/fenta-pbs/wpdownload.sh >> /mnt/fenta-pbs/wpdownload.sh.log 2>&1

이후 로그를 확인하면 아래처럼 매일매일 파일을 다운로드 하는 것을 확인할 수 있습니다.

테스트 블로그 만들기(1)

이제, 내려받은 백업파일을 활용해, 홈서버 내에 똑같은 블로그를 하나 더 생성해 보겠습니다. 매일 자정 가까운 시간에 생성된 백업파일을 활용해 스냅샷 느낌처럼 일자별로 블로그를 돌려가며 생성해낼 수 있고, 코어와 테마, 플러그인 등을 테스트 업데이트 해보면서 원본 블로그의 업데이트 시기를 정할 수도 있습니다.

저는 이 작업을 위해 Proxmox 내에 우분투 VM을 하나 생성하여 이용하겠습니다.

먼저, TrueNAS의 백업파일 저장소를 NFS로 마운트하겠습니다.

nano /etc/fstab
10.20.10.203:/mnt/fenta-pbs/wordpress   /mnt/wordpress    nfs4    defaults,_netdev        0       2

/mnt/fenta-pbs/wordpress와 /mnt/wordpress의 경로는 개인 환경에 맞게 수정하시면 됩니다.

이후, mount -a를 입력해 정상적으로 마운트를 진행합니다.

이제, 다운로드 받은 압축파일을 해제합니다.

tar -zxf /mnt/wordpress -C /

그러면 오라클 환경과 동일하게 /docker/wordpress 아래에 해제된 db, www 폴더를 확인할 수 있습니다.

ls -lah /docker/wordpress/
total 0
drwxr-xr-x 1 root     root      10 Feb 20 14:46 .
drwxr-xr-x 1 root     root     160 Mar  6 15:00 ..
drwxr-xr-x 1 lxd      docker   456 Mar  6 15:00 db
drwxr-xr-x 1 www-data www-data 602 Mar  4 13:40 www

이 파일들을 활용해 원본과 동일한 컨테이너를 올리면 됩니다.

services:
  db:
    image: mariadb:latest
    command: '--default-authentication-plugin=mysql_native_password'
    container_name: mariadb
    volumes:
      - /docker/wordpress/db:/var/lib/mysql
    restart: always
    environment:
      - MYSQL_ROOT_PASSWORD=
      - MYSQL_DATABASE=
      - MYSQL_USER=
      - MYSQL_PASSWORD=
    labels:
      - "com.centurylinklabs.watchtower.enable=false"
    expose:
      - 3306
      - 33060
      
  wordpress:
    image: wordpress:latest
    container_name: wordpress
    ports:
      - 80:80
    volumes:
      - /docker/wordpress/www:/var/www/html
    restart: always
    environment:
      - WORDPRESS_DB_HOST=db
      - WORDPRESS_DB_USER=
      - WORDPRESS_DB_PASSWORD=
      - WORDPRESS_DB_NAME=
    labels:
      - "com.centurylinklabs.watchtower.enable=false"

실 환경에선 Portainer를 이용했지만, 테스트 환경에서는 수시로 도커를 내렸다 올렸다 할 예정이기 때문에, CLI에서 접근하기 편한 docker-compose를 활용하려고 합니다. 저는 이 파일을 /docker 폴더 아래에 docker-compose-wordpress.yml 로 저장했습니다.

ls -lah /docker
total 24K
drwxr-xr-x 1 root root 160 Mar  6 15:00 .
drwxr-xr-x 1 root root 174 Feb 29 16:48 ..
-rw-r--r-- 1 root root 970 Mar  4 14:37 docker-compose-wordpress.yml

이제 간단하게 docker-compose up 해봅시다.

docker-compose -f /docker/docker-compose-wordpress.yml up -d

테스트용의 VM IP는 10.20.10.210입니다. 브라우저로 접속해 보겠습니다.

겉보기에는, 실 환경과 동일한 블로그가 생성되었습니다..만, 아직 완벽하지 않습니다.

관리자 페이지를 접속하려 하면 아래와 같이 접속이 거부됩니다.

DB주소가 실 환경의 10.20.10.210를 따라가기 때문입니다. 이걸 수정해 보겠습니다.

테스트 블로그 만들기(2)

위의 docker-compose를 그대로 사용했다면 컨테이너명은 mariadb입니다. 해당 컨테이너에 접근합니다.

docker exec -it mariadb /bin/bash

그러면, 도커 내부로 접근할 수 있습니다.

이제 DB내부의 주소를 변경하는데,

mariadb -uroot -p'password' -e "update $table.wp_posts set post_content = replace(post_content, '$preurl', '$posturl') where post_content like '%$preurl%'; update $table.wp_posts set guid = replace(guid, '$preurl', '$posturl') where guid like '%$preurl%'; update $table.wp_postmeta set meta_value = replace(meta_value, '$preurl', '$posturl') where meta_value like '%$preurl%'; UPDATE $table.wp_options SET option_value='http://$posturl' WHERE option_name='siteurl'; UPDATE $table.wp_options SET option_value='http://$posturl' WHERE option_name='home';"

docker-compose구문에서 mariadb컨테이너 environment값이 몇 개 필요합니다.

MYSQL_ROOT_PASSWORD, MYSQL_DATABASE 이 두 가지와, 기존 블로그 웹 주소, 새로 만든 VM의 웹 주소가 필요합니다. 이 중, 새로 만든 VM의 웹 주소는 실제로는 내부IP가 될 것이고, 별도의 셋팅을 통해서 다른 도메인을 연결해두었다면, 그 도메인이 되겠습니다.

하단의 표를 참고하여 각각의 환경에 맞는 값을 입력해 줍니다.

메모장에 복사해두고 찾아 바꾸기로 수정하시면 편합니다.

추가적으로, posturl에 SSL인증서가 연동된다면, “http”를 “https”로 수정하셔야 합니다.

특별한 반응은 없지만, 입력을 제대로 했다면 잘 변경됩니다.

값을 반영하기 위해 컨테이너에서 빠져나와 도커를 재시작 해줍니다.

docker-compose -f /docker/docker-compose-wordpress.yml down
docker-compose -f /docker/docker-compose-wordpress.yml up -d

이제 테스트 블로그에서도 wp-admin에 접속할 수 있고, 썸네일 등도 모두 제대로 연결됩니다.

반복작업을 위한 스크립트 작성하기

업데이트에 실패하거나, 플러그인에서 필요한 기능을 시험해보거나 기타 등등의 이유로 테스트블로그를 계속 원복시켜야 할 때마다, 위 과정을 반복해야 하는데, 조금 귀찮습니다. 그래서 이것도 스크립트로 만들어 보겠습니다. 스크립트로 만들어 간편하게 블로그를 롤백할 수 있게 됩니다.

#!/bin/bash

#변수 및 파일 경로 지정
c1="mariadb" #db 컨테이너명
cf="/docker/docker-compose-wordpress.yml" #docker-compose 파일위치
c1u="root" #MariaDB root계정
c1p="" #MariaDB root계정 패스워드
table="wordpress" #DB테이블명
preurl="10.20.10.210" #수정 전 주소
posturl="10.20.10.210" #수정 후 주소
wp_path="/docker/wordpress" #Wordpress, MariaDB 컨테이너 경로
backup_path="/mnt/wordpress" #백업파일 경로
backup_files=($backup_path/*.tar.gz)  # 백업파일 목록을 배열에 저장

# 백업 파일 목록을 수정 시간 기준으로 정렬
sorted_backup_files=($(for file in "${backup_files[@]}"; do echo "$file"; done | xargs -r ls -t))

#도커 중지 및 compose파일 위치 지정
echo "Stopping containers"
docker-compose -f $cf down
echo "Containers are stopped"

#워드프레스 도커 설치 경로 점검
if [ -d "$wp_path" ]; then
    echo "Deleting $wp_path"
    rm -rf "$wp_path"
    echo "Directory deleted."
else
    echo "$wp_path doesn't exist. Skipping."
fi

# 정렬된 백업 파일 목록 출력
echo "Sorted backup files available:"
for i in "${!sorted_backup_files[@]}"; do
    echo "$((i+1)). ${sorted_backup_files[i]}"
done

# 사용자에게 백업 파일 순번 입력 받기
read -p "Enter the number of the backup file you want to restore: " selected_number

# 입력된 순번에 해당하는 백업 파일 선택
selected_index=$((selected_number-1))
selected_backup="${sorted_backup_files[selected_index]}"

# 선택된 백업 파일 출력
echo "Selected backup file: $selected_backup"

#찾은 파일 압축 풀기
echo "Extracting..."
tar -zxf $selected_backup -C / -P
echo "Extracting finished"

#docker-compose 실행
echo "docker-compose up..."
docker-compose -f $cf up -d

#db 내부 주소 바꾸기
echo "Waiting 10 seconds"
sleep 10
echo "Modifying values..."
docker exec $c1 mariadb -u$c1u -p"$c1p" -e "update $table.wp_posts set post_content = replace(post_content, '$preurl', '$posturl') where post_content like '%$preurl%'; update $table.wp_posts set guid = replace(guid, '$preurl', '$posturl') where guid like '%$preurl%'; update $table.wp_postmeta set meta_value = replace(meta_value, '$preurl', '$posturl') where meta_value like '%$preurl%'; UPDATE $table.wp_options SET option_value='http://$posturl' WHERE option_name='siteurl'; UPDATE $table.wp_options SET option_value='http://$posturl' WHERE option_name='home';"

#docker 내렸다 올리기
echo "Restarting your WordPress..."
docker-compose -f $cf down
docker-compose -f $cf up -d
echo "All job done"

스크립트 첫 문단의 “#변수 및 파일 경로 지정” 부분의 하이라이트 된 부분을 아래 표를 참조하여 수정하시면 됩니다.

wp_path의 경우 특별히 설정을 다르게 하지 않았다면, 오라클 클라우드에서 압축할 때의 원본 경로와 같아야 하지만,

압축 풀 경로(tar -zxf $selected_backup -C /)를 다르게 설정하고자 한다면, 이 부분도 동일하게 변경해야 합니다.

또한, 매일 백업파일이 생성되는 만큼, 어떤 파일을 사용할 것인지를 정하는 과정이 필요하기 때문에 파일을 선택하는 과정을 추가했습니다. 스크립트를 실행하면, 아래와 같이, backup_path상에 있는 tar.gz파일을 시간 역순으로 정렬해 보여주고, 사용자가 번호를 입력해 파일을 선택하도록 되어 있습니다.

이제 스크립트 하나로 원하는 시점의 데이터로 테스트 블로그를 띄울 수 있게 되었습니다. crontab에 등록해둔다면, 극한의 귀차니즘으로 인해 이것저것 건드리다가 그대로 버려두어도 알아서 원복되는 환경도 만들 수 있겠죠.

그런데, crontab으로 자동화하기에는, 번호를 입력받는 과정이 방해가 됩니다.

그래서 아래와 같이 수정하여, 10초간 기다린 후 입력이 없으면 알아서 가장 최근 파일을 사용하도록 수정했습니다.

#!/bin/bash

#변수 및 파일 경로 지정
c1="mariadb" #db 컨테이너명
cf="/docker/docker-compose-wordpress.yml" #docker-compose 파일위치
c1u="root" #MariaDB root계정
c1p="" #MariaDB root계정 패스워드
table="wordpress" #DB테이블명
preurl="10.20.10.210" #수정 전 주소
posturl="10.20.10.210" #수정 후 주소
wp_path="/docker/wordpress" #Wordpress, MariaDB 컨테이너 경로
backup_path="/mnt/wordpress" #백업파일 경로
backup_files=($backup_path/*.tar.gz)  # 백업파일 목록을 배열에 저장

# 백업 파일 목록을 수정 시간 기준으로 정렬
sorted_backup_files=($(for file in "${backup_files[@]}"; do echo "$file"; done | xargs -r ls -t))

#도커 중지 및 compose파일 위치 지정
echo "Stopping containers"
docker-compose -f $cf down
echo "Containers are stopped"

#워드프레스 도커 설치 경로 점검
if [ -d "$wp_path" ]; then
    echo "Deleting $wp_path"
    rm -rf "$wp_path"
    echo "Directory deleted."
else
    echo "$wp_path doesn't exist. Skipping."
fi

# 정렬된 백업 파일 목록 출력
echo "Sorted backup files available:"
for i in "${!sorted_backup_files[@]}"; do
    echo "$((i+1)). ${sorted_backup_files[i]}"
done

# 사용자에게 백업 파일 순번 입력 받기
read -t 10 -p "Enter the number of the backup file you want to restore[default is 1]: " selected_number

# 입력된 순번에 해당하는 백업 파일 선택
selected_index=$((selected_number-1))
if [ -z "$selected_number" ]; then
    selected_index=0  # 입력이 없을 경우 디폴트로 1번 파일 선택
fi
selected_backup="${sorted_backup_files[selected_index]}"

#selected_index=$((selected_number-1))
#selected_backup="${sorted_backup_files[selected_index]}"

# 선택된 백업 파일 출력
echo "Selected backup file: $selected_backup"

#찾은 파일 압축 풀기
echo "Extracting..."
tar -zxf $selected_backup -C / -P
echo "Extracting finished"

#docker-compose 실행
echo "docker-compose up..."
docker-compose -f $cf up -d

#db 내부 주소 바꾸기
echo "Waiting 10 seconds"
sleep 10
echo "Modifying values..."
docker exec $c1 mariadb -u$c1u -p"$c1p" -e "update $table.wp_posts set post_content = replace(post_content, '$preurl', '$posturl') where post_content like '%$preurl%'; update $table.wp_posts set guid = replace(guid, '$preurl', '$posturl') where guid like '%$preurl%'; update $table.wp_postmeta set meta_value = replace(meta_value, '$preurl', '$posturl') where meta_value like '%$preurl%'; UPDATE $table.wp_options SET option_value='http://$posturl' WHERE option_name='siteurl'; UPDATE $table.wp_options SET option_value='http://$posturl' WHERE option_name='home';"

#docker 내렸다 올리기
echo "Restarting your WordPress..."
docker-compose -f $cf down
docker-compose -f $cf up -d
echo "All job done"

이제 이 스크립트를 crontab에 등록해두면, 알아서 가장 최근 백업파일을 이용해 블로그를 띄워 놓도록 할 수 있습니다.

저는 매일 6시에 이 스크립트를 등록해두고, 회사에 출근해 테스트 블로그를 확인합니다.

0 6 * * * /home/script/wprestore.sh >> /home/script/wprestore.sh.log 2>&1

이렇게 해서, 단순한 백업&복원 뿐만이 아니라, 오라클 클라우드가 증발했을 때에도, 셀프 호스팅으로 블로그를 다시 살려낼 수 있게 되었습니다.

문제 해결(wp-config.php)

제가 참조했던 원문은 wp-config.php에 아래와 같이 WP_HOME과 WP_SITEURL을 수정하는 과정이 있었습니다.

sed -i "s|define('WP_HOME','https://10.20.10.210');|define('WP_HOME','10.20.10.210');|g" /docker/wordpress/www/wp-config.php
sed -i "s|define('WP_SITEURL','https://10.20.10.210');|define('WP_SITEURL','10.20.10.210');|g" /docekr/wordpress/www/wp-config.php

이 과정은 변경된 접속 주소를 직접 wp-config.php에 반영하는 방법으로, 아래와 같이 웹 설정 페이지의 ‘워드프레스 주소’와 ‘사이트 주소’를 고정시켜 줍니다.

그런데, 도커로 설치한 제 환경에는 해당 구문이 아예 없어 적용되지 않아, 아래와 같이 수정해서 실행했습니다.

echo -e "define('WP_HOME', '10.20.10.210');\ndefine('WP_SITEURL', '10.20.10.210');" >> /docker/wordpress/www/wp-config.php

그러자, 아래와 같이 /wp-admin 으로 접근 시 리다이렉트에서 문제가 발생했습니다.

알고 보니, “http://”를 추가하지 않아 발생한 문제로, 이 과정을 제대로 수행하려면,

echo -e "define('WP_HOME', 'http://10.20.10.210');\ndefine('WP_SITEURL', 'http://10.20.10.210');" >> /docker/wordpress/www/wp-config.php

가 되어야 했습니다. 제대로 적용하면 웹 설정 페이지에서도 아래와 같이 http://가 포함되어 표기됩니다.

워드프레스 도커 이미지 속 wp-config.php에는 이 구문이 없기도 하고, 이 과정을 거치지 않아도, 테스트 환경 접속에 문제는 없었기에 저는 아예 제외해 버렸습니다.

2025.01.23 - [Apps] - 고스트로 블로그 구축하고 워드프레스 마이그레이션하기

고스트로 블로그 구축하고 워드프레스 마이그레이션하기

개요워드프레스 사용 중 불편함을 느껴 블로그를 고스트로 이전했습니다. 마이그레이션 과정을 가이드 형식으로 작성해 보겠습니다.고스트 공식 가이드에서는 뚝딱 하면 순식간에 이루어지는

worklazy.net

2025.01.23 - [Apps] - 워드프레스 이미지 클릭 시 확대 기능 자동활성화하기

워드프레스 이미지 클릭 시 확대 기능 자동활성화하기

개요워드프레스로 글을 작성할 때, 이미지를 삽입하게 되는데, 해당 이미지의 속성에서 Expand on Click이 있습니다. 해당 속성을 활성화해주지 않으면, 글을 읽는 사람은 이미지가 작아 클릭해 확

worklazy.net

출처

1. 넷마블 기술 블로그

워드프레스 백업과 복원은 웹 파일과 DB를 한 쌍으로 맺어야 한다 - 넷마블 기술 블로그

1년에 4번 정도 마주치는 워드프레스 업데이트 테스트 상황에 조금 더 편하게 대응하고 있습니다. 다만, 편하게 만나는 환경에 직면한 작업자는 저를 포함해 극소수밖에 되지 않아, 단순히 시

netmarble.engineering

728x90

오라클 클라우드에 도커로 워드프레스 구축하고 백업하기

개요

워드프레스 도커로 설치

Docker-compose 이용하기

워드프레스 초기 세팅

워드프레스 백업하기

백업의 필요성

백업 수단 정하기

백업 구조

백업파일 생성하기

백업파일 2차 저장

테스트 블로그 만들기(1)

테스트 블로그 만들기(2)

반복작업을 위한 스크립트 작성하기

문제 해결(wp-config.php)

관련 글

출처

티스토리툴바