4.7. OADP 복원
4.7.1. 애플리케이션 복원
Restore
CR(사용자 정의 리소스)을 생성하여 애플리케이션 백업을 복원합니다. Restore CR 생성을 참조하십시오.
복원(CR)을 편집하여 애플리케이션을 복원하는 동안 Pod의 컨테이너에서 명령을 실행하기 위해 복원 후크를 생성할 수 있습니다. 복원 후크 생성참조
4.7.1.1. Restore CR 생성
Restore CR을 생성하여 Backup
CR(사용자 정의 리소스)을 복원
합니다.
사전 요구 사항
- OpenShift API for Data Protection(OADP) Operator를 설치해야 합니다.
-
DataProtectionApplication
CR은Ready
상태에 있어야 합니다. -
Velero
Backup
CR이 있어야 합니다. - PV(영구 볼륨) 용량이 백업 시 요청된 크기와 일치하도록 요청된 크기를 조정합니다.
절차
다음 예와 같이
Restore
CR을 생성합니다.apiVersion: velero.io/v1 kind: Restore metadata: name: <restore> namespace: openshift-adp spec: backupName: <backup> 1 includedResources: [] 2 excludedResources: - nodes - events - events.events.k8s.io - backups.velero.io - restores.velero.io - resticrepositories.velero.io restorePVs: true 3
다음 명령을 입력하여
Restore
CR의 상태가Completed
인지 확인합니다.$ oc get restore -n openshift-adp <restore> -o jsonpath='{.status.phase}'
다음 명령을 입력하여 백업 리소스가 복원되었는지 확인합니다.
$ oc get all -n <namespace> 1
- 1
- 백업한 네임스페이스입니다.
Restic을 사용하여
DeploymentConfig
오브젝트를 복원하거나 post-restore 후크를 사용하는 경우 다음 명령을 입력하여dc-restic-post-restore.sh
cleanup 스크립트를 실행합니다.$ bash dc-restic-post-restore.sh <restore-name>
참고복원 프로세스 과정에서 OADP Velero 플러그인은
DeploymentConfig
오브젝트를 축소하고 Pod를 독립 실행형 Pod로 복원하여 클러스터가 복원 시 복원된DeploymentConfig
Pod를 즉시 삭제하지 못하도록 하고 Restic 및 post-restore 후크를 허용하여 복원된 Pod에서 작업을 완료할 수 있습니다. cleanup 스크립트는 이러한 연결이 끊긴 Pod를 제거하고DeploymentConfig
오브젝트를 적절한 복제본 수로 백업합니다.예 4.1.
dc-restic-post-restore.sh
cleanup script#!/bin/bash set -e # if sha256sum exists, use it to check the integrity of the file if command -v sha256sum >/dev/null 2>&1; then CHECKSUM_CMD="sha256sum" else CHECKSUM_CMD="shasum -a 256" fi label_name () { if [ "${#1}" -le "63" ]; then echo $1 return fi sha=$(echo -n $1|$CHECKSUM_CMD) echo "${1:0:57}${sha:0:6}" } OADP_NAMESPACE=${OADP_NAMESPACE:=openshift-adp} if [[ $# -ne 1 ]]; then echo "usage: ${BASH_SOURCE} restore-name" exit 1 fi echo using OADP Namespace $OADP_NAMESPACE echo restore: $1 label=$(label_name $1) echo label: $label echo Deleting disconnected restore pods oc delete pods -l oadp.openshift.io/disconnected-from-dc=$label for dc in $(oc get dc --all-namespaces -l oadp.openshift.io/replicas-modified=$label -o jsonpath='{range .items[*]}{.metadata.namespace}{","}{.metadata.name}{","}{.metadata.annotations.oadp\.openshift\.io/original-replicas}{","}{.metadata.annotations.oadp\.openshift\.io/original-paused}{"\n"}') do IFS=',' read -ra dc_arr <<< "$dc" if [ ${#dc_arr[0]} -gt 0 ]; then echo Found deployment ${dc_arr[0]}/${dc_arr[1]}, setting replicas: ${dc_arr[2]}, paused: ${dc_arr[3]} cat <<EOF | oc patch dc -n ${dc_arr[0]} ${dc_arr[1]} --patch-file /dev/stdin spec: replicas: ${dc_arr[2]} paused: ${dc_arr[3]} EOF fi done
4.7.1.2. 복원 후크 생성
Restore
CR(사용자 정의 리소스)을 편집하여 애플리케이션을 복원하는 동안 Pod의 컨테이너에서 명령을 실행하도록 복원 후크를 생성합니다.
두 가지 유형의 복원 후크를 생성할 수 있습니다.
init
후크는 애플리케이션 컨테이너가 시작되기 전에 설정 작업을 수행하는 Pod에 init 컨테이너를 추가합니다.Restic 백업을 복원하면 복구 후크 init 컨테이너보다 먼저
restic-wait
init 컨테이너가 추가됩니다.-
exec
후크는 복원된 Pod의 컨테이너에서 명령 또는 스크립트를 실행합니다.
절차
다음 예와 같이
Restore
CR의spec.hooks
블록에 후크를 추가합니다.apiVersion: velero.io/v1 kind: Restore metadata: name: <restore> namespace: openshift-adp spec: hooks: resources: - name: <hook_name> includedNamespaces: - <namespace> 1 excludedNamespaces: - <namespace> includedResources: - pods 2 excludedResources: [] labelSelector: 3 matchLabels: app: velero component: server postHooks: - init: initContainers: - name: restore-hook-init image: alpine:latest volumeMounts: - mountPath: /restores/pvc1-vm name: pvc1-vm command: - /bin/ash - -c timeout: 4 - exec: container: <container> 5 command: - /bin/bash 6 - -c - "psql < /backup/backup.sql" waitTimeout: 5m 7 execTimeout: 1m 8 onError: Continue 9
- 1
- 선택사항: 후크가 적용되는 네임스페이스의 배열입니다. 이 값을 지정하지 않으면 후크가 모든 네임스페이스에 적용됩니다.
- 2
- 현재 Pod는 후크를 적용할 수 있는 유일한 지원 리소스입니다.
- 3
- 선택 사항: 이 후크는 라벨 선택기와 일치하는 오브젝트에만 적용됩니다.
- 4
- 선택 사항: Timeout은 Velero가
initContainers
가 완료될 때까지의 최대 시간을 지정합니다. - 5
- 선택 사항: 컨테이너를 지정하지 않으면 Pod의 첫 번째 컨테이너에서 명령이 실행됩니다.
- 6
- 이는 추가되는 init 컨테이너의 진입점입니다.
- 7
- 선택 사항: 컨테이너가 준비될 때까지 대기하는 시간입니다. 컨테이너가 시작되고 동일한 컨테이너의 이전 후크가 완료될 때까지 충분히 길어야 합니다. 설정되지 않은 경우 복원 프로세스는 무기한 대기합니다.
- 8
- 선택 사항: 명령을 실행할 때까지 대기하는 시간입니다. 기본값은
30s
입니다. - 9
- 오류 처리에 허용되는 값은
Fail
및Continue
:-
계속
: 명령 실패만 기록됩니다. -
fail
: 모든 Pod의 컨테이너에서 더 이상 복원 후크가 실행되지 않습니다.Restore
CR의 상태는PartiallyFailed
가 됩니다.
-