Skip to main content
본 한국어 번역은 사용자 편의를 위해 제공되는 기계 번역입니다. 영어 버전과 한국어 버전이 서로 어긋나는 경우에는 언제나 영어 버전이 우선합니다.

Trident Protect를 사용하여 애플리케이션 보호

기여자 netapp-aruldeepa
PDF

Trident Protect에서 관리하는 모든 앱은 자동화된 보호 정책이나 임시 기반으로 스냅샷과 백업을 찍어 보호할 수 있습니다.

참고 데이터 보호 작업 중에 파일 시스템을 동결 및 동결 해제하도록 Trident Protect를 구성할 수 있습니다. "Trident Protect를 사용하여 파일 시스템 동결을 구성하는 방법에 대해 자세히 알아보세요.".

주문형 스냅샷 만들기

언제든지 주문형 스냅샷을 만들 수 있습니다.

참고 클러스터 범위 리소스는 애플리케이션 정의에서 명시적으로 참조되거나 애플리케이션 네임스페이스에 대한 참조가 있는 경우 백업, 스냅샷 또는 복제본에 포함됩니다.
CR을 사용하여 스냅샷을 만듭니다.
단계

  1. 사용자 정의 리소스(CR) 파일을 만들고 이름을 지정합니다. trident-protect-snapshot-cr.yaml .

  2. 생성한 파일에서 다음 속성을 구성합니다.

    • metadata.name: (필수) 이 사용자 지정 리소스의 이름입니다. 사용자 환경에 맞게 고유하고 적절한 이름을 선택하세요.

    • spec.applicationRef: 스냅샷을 생성할 애플리케이션의 Kubernetes 이름입니다.

    • spec.appVaultRef: (필수) 스냅샷 콘텐츠(메타데이터)를 저장해야 하는 AppVault의 이름입니다.

    • spec.reclaimPolicy: (선택 사항) 스냅샷 CR이 삭제될 때 스냅샷의 AppArchive에 어떤 일이 일어나는지 정의합니다. 이는 설정된 경우에도 다음을 의미합니다. Retain , 스냅샷이 삭제됩니다. 유효한 옵션:

      • Retain(기본)

      • Delete

        ---
apiVersion: protect.trident.netapp.io/v1
kind: Snapshot
metadata:
  namespace: my-app-namespace
  name: my-cr-name
spec:
  applicationRef: my-application
  appVaultRef: appvault-name
  reclaimPolicy: Delete

  3. 다음을 채운 후 trident-protect-snapshot-cr.yaml 올바른 값으로 파일을 만들고 CR을 적용하세요.

    kubectl apply -f trident-protect-snapshot-cr.yaml
CLI를 사용하여 스냅샷을 만듭니다.
단계

  1. 괄호 안의 값을 사용자 환경의 정보로 바꿔 스냅샷을 만듭니다. 예를 들어:

    tridentctl-protect create snapshot <my_snapshot_name> --appvault <my_appvault_name> --app <name_of_app_to_snapshot> -n <application_namespace>

주문형 백업 만들기

언제든지 앱을 백업할 수 있습니다.

참고 클러스터 범위 리소스는 애플리케이션 정의에서 명시적으로 참조되거나 애플리케이션 네임스페이스에 대한 참조가 있는 경우 백업, 스냅샷 또는 복제본에 포함됩니다.
시작하기 전에

장기 실행 S3 백업 작업에 대해 AWS 세션 토큰 만료 기간이 충분한지 확인하세요. 백업 작업 중에 토큰이 만료되면 작업이 실패할 수 있습니다.

  • 를 참조하세요 "AWS API 문서" 현재 세션 토큰 만료일을 확인하는 방법에 대한 자세한 내용은 다음을 참조하세요.

  • 를 참조하세요 "AWS IAM 문서" AWS 리소스에 대한 자격 증명에 대한 자세한 내용은 다음을 참조하세요.

CR을 사용하여 백업을 만듭니다.
단계

  1. 사용자 정의 리소스(CR) 파일을 만들고 이름을 지정합니다. trident-protect-backup-cr.yaml .

  2. 생성한 파일에서 다음 속성을 구성합니다.

    • metadata.name: (필수) 이 사용자 지정 리소스의 이름입니다. 사용자 환경에 맞게 고유하고 적절한 이름을 선택하세요.

    • spec.applicationRef: (필수) 백업할 애플리케이션의 Kubernetes 이름입니다.

    • spec.appVaultRef: (필수) 백업 내용을 저장해야 하는 AppVault의 이름입니다.

    • spec.dataMover: (선택 사항) 백업 작업에 사용할 백업 도구를 나타내는 문자열입니다. 가능한 값(대소문자 구분):

      • Restic

      • Kopia(기본)

    • spec.reclaimPolicy: (선택 사항) 백업이 클레임에서 해제될 때 발생하는 작업을 정의합니다. 가능한 값:

      • Delete

      • Retain(기본)

    • spec.snapshotRef: (선택 사항): 백업 소스로 사용할 스냅샷의 이름입니다. 제공되지 않으면 임시 스냅샷이 생성되어 백업됩니다.

    • metadata.annotations.protect.trident.netapp.io/full-backup : (선택 사항) 이 주석은 백업이 증분 방식이 아니어야 하는지 여부를 지정하는 데 사용됩니다. 기본적으로 모든 백업은 증분 백업입니다. 그러나 이 주석이 설정된 경우 true , 백업이 비증분 백업으로 전환됩니다. 지정하지 않으면 백업은 기본 증분 백업 설정을 따릅니다. 복원과 관련된 위험을 최소화하려면 주기적으로 전체 백업을 수행한 다음 전체 백업 사이에 증분 백업을 수행하는 것이 가장 좋습니다.

      YAML 예시:

    ---
apiVersion: protect.trident.netapp.io/v1
kind: Backup
metadata:
  namespace: my-app-namespace
  name: my-cr-name
  annotations:
    protect.trident.netapp.io/full-backup: "true"
spec:
  applicationRef: my-application
  appVaultRef: appvault-name
  dataMover: Kopia

  3. 다음을 채운 후 trident-protect-backup-cr.yaml 올바른 값으로 파일을 만들고 CR을 적용하세요.

    kubectl apply -f trident-protect-backup-cr.yaml
CLI를 사용하여 백업을 만듭니다.
단계

  1. 괄호 안의 값을 사용자 환경의 정보로 바꿔 백업을 만듭니다. 예를 들어:

    tridentctl-protect create backup <my_backup_name> --appvault <my-vault-name> --app <name_of_app_to_back_up> --data-mover <Kopia_or_Restic> -n <application_namespace>

    선택적으로 사용할 수 있습니다 --full-backup 백업이 증분되지 않아야 하는지 여부를 지정하는 플래그입니다. 기본적으로 모든 백업은 증분 백업입니다. 이 플래그를 사용하면 백업이 비증분 방식으로 진행됩니다. 복원과 관련된 위험을 최소화하려면 주기적으로 전체 백업을 수행하고 전체 백업 사이에 증분 백업을 수행하는 것이 가장 좋습니다.

데이터 보호 일정을 만듭니다

보호 정책은 정의된 일정에 따라 스냅샷, 백업 또는 둘 다를 생성하여 앱을 보호합니다. 매시간, 매일, 매주, 매월 스냅샷과 백업을 만들도록 선택할 수 있으며, 보관할 복사본 수를 지정할 수 있습니다. full-backup-rule 주석을 사용하여 비증분 전체 백업을 예약할 수 있습니다. 기본적으로 모든 백업은 증분 백업입니다. 주기적으로 전체 백업을 수행하고 그 사이에 증분 백업을 수행하면 복원과 관련된 위험을 줄이는 데 도움이 됩니다.

참고

  • 스냅샷에 대한 일정은 다음을 설정하여 생성할 수 있습니다. backupRetention 0으로 그리고 snapshotRetention 0보다 큰 값으로. 환경 snapshotRetention 0으로 설정하면 예약된 백업은 여전히 스냅샷을 생성하지만, 이는 일시적이며 백업이 완료되면 즉시 삭제됩니다.

  • 클러스터 범위 리소스는 애플리케이션 정의에서 명시적으로 참조되거나 애플리케이션 네임스페이스에 대한 참조가 있는 경우 백업, 스냅샷 또는 복제본에 포함됩니다.
CR을 사용하여 일정을 만듭니다.
단계

  1. 사용자 정의 리소스(CR) 파일을 만들고 이름을 지정합니다. trident-protect-schedule-cr.yaml .

  2. 생성한 파일에서 다음 속성을 구성합니다.

    • metadata.name: (필수) 이 사용자 지정 리소스의 이름입니다. 사용자 환경에 맞게 고유하고 적절한 이름을 선택하세요.

    • spec.dataMover: (선택 사항) 백업 작업에 사용할 백업 도구를 나타내는 문자열입니다. 가능한 값(대소문자 구분):

      • Restic

      • Kopia(기본)

    • spec.applicationRef: 백업할 애플리케이션의 Kubernetes 이름입니다.

    • spec.appVaultRef: (필수) 백업 내용을 저장해야 하는 AppVault의 이름입니다.

    • spec.backupRetention: 보관할 백업 수. 0은 백업을 생성하지 않음을 나타냅니다(스냅샷만 생성).

    • spec.snapshotRetention: 보관할 스냅샷 수. 0은 스냅샷을 생성하지 않음을 나타냅니다.

    • spec.granularity: 일정을 실행해야 하는 빈도입니다. 가능한 값과 필수 연관 필드는 다음과 같습니다.

      • Hourly(지정해야 함) spec.minute )

      • Daily(지정해야 함) spec.minute 그리고 spec.hour )

      • Weekly(지정해야 함) spec.minute, spec.hour , 그리고 spec.dayOfWeek )

      • Monthly(지정해야 함) spec.minute, spec.hour , 그리고 spec.dayOfMonth )

      • Custom

    • spec.dayOfMonth: (선택 사항) 일정을 실행해야 하는 날짜(1~31)입니다. 이 필드는 세분성이 설정된 경우 필수입니다. Monthly . 값은 문자열로 제공되어야 합니다.

    • spec.dayOfWeek: (선택 사항) 일정을 실행해야 하는 요일(0~7). 0 또는 7의 값은 일요일을 나타냅니다. 이 필드는 세분성이 설정된 경우 필수입니다. Weekly . 값은 문자열로 제공되어야 합니다.

    • spec.hour: (선택 사항) 일정을 실행해야 하는 시간(0~23)입니다. 이 필드는 세분성이 설정된 경우 필수입니다. Daily , Weekly , 또는 Monthly . 값은 문자열로 제공되어야 합니다.

    • spec.minute: (선택 사항) 일정을 실행해야 하는 분(0~59)입니다. 이 필드는 세분성이 설정된 경우 필수입니다. Hourly , Daily , Weekly , 또는 Monthly . 값은 문자열로 제공되어야 합니다.

    • metadata.annotations.protect.trident.netapp.io/full-backup-rule: (선택 사항) 이 주석은 전체 백업을 예약하기 위한 규칙을 지정하는 데 사용됩니다. 설정할 수 있습니다 always 지속적인 전체 백업을 위해 사용하거나 요구 사항에 맞게 사용자 정의할 수 있습니다. 예를 들어, 일별 단위를 선택하면 전체 백업을 수행할 요일을 지정할 수 있습니다.

      백업 및 스냅샷 일정에 대한 YAML 예:

      ---
apiVersion: protect.trident.netapp.io/v1
kind: Schedule
metadata:
  namespace: my-app-namespace
  name: my-cr-name
  annotations:
    protect.trident.netapp.io/full-backup-rule: "Monday,Thursday"
spec:
  dataMover: Kopia
  applicationRef: my-application
  appVaultRef: appvault-name
  backupRetention: "15"
  snapshotRetention: "15"
  granularity: Daily
  hour: "0"
  minute: "0"

      스냅샷 전용 일정에 대한 YAML 예:

    ---
apiVersion: protect.trident.netapp.io/v1
kind: Schedule
metadata:
  namespace: my-app-namespace
  name: my-snapshot-schedule
spec:
  applicationRef: my-application
  appVaultRef: appvault-name
  backupRetention: "0"
  snapshotRetention: "15"
  granularity: Daily
  hour: "2"
  minute: "0"

  3. 다음을 채운 후 trident-protect-schedule-cr.yaml 올바른 값으로 파일을 만들고 CR을 적용하세요.

    kubectl apply -f trident-protect-schedule-cr.yaml
CLI를 사용하여 일정을 만듭니다.
단계

  1. 보호 일정을 만들고 괄호 안의 값을 사용자 환경의 정보로 바꿉니다. 예를 들어:

    참고 사용할 수 있습니다 tridentctl-protect create schedule --help 이 명령에 대한 자세한 도움말 정보를 보려면. 
    tridentctl-protect create schedule <my_schedule_name> --appvault <my_appvault_name> --app <name_of_app_to_snapshot> --backup-retention <how_many_backups_to_retain> --data-mover <Kopia_or_Restic> --day-of-month <day_of_month_to_run_schedule> --day-of-week <day_of_month_to_run_schedule> --granularity <frequency_to_run> --hour <hour_of_day_to_run> --minute <minute_of_hour_to_run> --recurrence-rule <recurrence> --snapshot-retention <how_many_snapshots_to_retain> -n <application_namespace> --full-backup-rule <string>

    설정할 수 있습니다 --full-backup-rule 플래그를 always 지속적인 전체 백업을 위해 사용하거나 요구 사항에 맞게 사용자 정의할 수 있습니다. 예를 들어, 일 단위를 선택하면 전체 백업을 수행할 요일을 지정할 수 있습니다. 예를 들어, 사용 --full-backup-rule "Monday,Thursday" 월요일과 목요일에 전체 백업을 예약합니다.

    스냅샷 전용 일정의 경우 다음을 설정합니다. --backup-retention 0 0보다 큰 값을 지정합니다. --snapshot-retention .

스냅샷 삭제

더 이상 필요하지 않은 예약된 스냅샷이나 주문형 스냅샷을 삭제합니다.

단계

  1. 스냅샷과 연관된 스냅샷 CR을 제거합니다.

    kubectl delete snapshot <snapshot_name> -n my-app-namespace

백업 삭제

더 이상 필요하지 않은 예약된 백업이나 주문형 백업을 삭제합니다.

참고 회수 정책이 설정되어 있는지 확인하십시오. Delete 개체 스토리지에서 모든 백업 데이터를 제거합니다. 정책의 기본 설정은 다음과 같습니다. Retain 실수로 데이터가 손실되는 것을 방지합니다. 정책이 변경되지 않으면 Delete 백업 데이터는 개체 스토리지에 남아 있으므로 수동으로 삭제해야 합니다.
단계

  1. 백업과 관련된 백업 CR을 제거합니다.

    kubectl delete backup <backup_name> -n my-app-namespace

백업 작업 상태 확인

명령줄을 사용하여 진행 중인 백업 작업, 완료된 백업 작업 또는 실패한 백업 작업의 상태를 확인할 수 있습니다.

단계

  1. 다음 명령을 사용하여 백업 작업의 상태를 검색하고, 괄호 안의 값을 사용자 환경의 정보로 바꿉니다.

    kubectl get backup -n <namespace_name> <my_backup_cr_name> -o jsonpath='{.status}'

azure-netapp-files(ANF) 작업에 대한 백업 및 복원 활성화

Trident Protect를 설치한 경우 azure-netapp-files 스토리지 클래스를 사용하고 Trident 24.06 이전에 생성된 스토리지 백엔드에 대해 공간 효율적인 백업 및 복원 기능을 활성화할 수 있습니다. 이 기능은 NFSv4 볼륨에서 작동하며 용량 풀에서 추가 공간을 소모하지 않습니다.

시작하기 전에

다음 사항을 확인하세요.

  • Trident Protect를 설치했습니다.

  • Trident Protect에서 애플리케이션을 정의했습니다. 이 절차를 완료하기 전까지 이 애플리케이션의 보호 기능은 제한됩니다.

  • 당신은 가지고있다 azure-netapp-files 스토리지 백엔드의 기본 스토리지 클래스로 선택되었습니다.

구성 단계를 확장하세요

  1. Trident 24.10으로 업그레이드하기 전에 ANF 볼륨이 생성된 경우 Trident 에서 다음을 수행하세요.

    1. azure-netapp-files 기반이며 애플리케이션과 연결된 각 PV에 대해 스냅샷 디렉토리를 활성화합니다.

      tridentctl update volume <pv name> --snapshot-dir=true -n trident

    2. 연관된 각 PV에 대해 스냅샷 디렉토리가 활성화되었는지 확인하세요.

      tridentctl get volume <pv name> -n trident -o yaml | grep snapshotDir

      응답:

    snapshotDirectory: "true"

    +
    스냅샷 디렉토리가 활성화되지 않은 경우 Trident Protect는 정기 백업 기능을 선택합니다. 이 기능은 백업 프로세스 중에 용량 풀의 공간을 일시적으로 사용합니다. 이 경우 백업되는 볼륨 크기의 임시 볼륨을 생성할 수 있는 충분한 공간이 용량 풀에 있는지 확인하세요.

결과

이 애플리케이션은 Trident Protect를 사용하여 백업하고 복원할 준비가 되었습니다. 각 PVC는 다른 애플리케이션에서 백업 및 복원을 위해 사용할 수도 있습니다.