선택한 VM(소스 VM 또는 다른 물리적 호스트 또는 VM)에 연결된 새 디스크로 해당 데이터를 마운트합니다. VMware 이미지 마운트를 참고하세요.
이 데이터를 소스 VMware VM에 연결된 모든 디스크 또는 일부 디스크에 복원합니다. VMware VM 복원을 참고하세요.
이 데이터를 새 대상 VMware VM에 연결된 모든 디스크 또는 일부 디스크에 클론합니다. VMware VM 복원을 참고하세요.
백업 및 DR은 Cloud Storage에 백업을 쓰는 OnVault 또는 스냅샷을 두 번째 백업/복구 어플라이언스에 복사하는 StreamSnap을 사용하여 여러 위치에 각 스냅샷의 사본을 여러 개 저장하도록 구성할 수 있습니다.
백업 및 DR은 자동 체크섬을 사용하여 각 백업 작업이 완료된 후 데이터 무결성을 보장합니다.
작동 방식: VMware VM 스냅샷 백업 및 DR
VMware VM을 사용한 데이터 백업은 다음 단계를 따릅니다.
VMware VM의 첫 번째 스냅샷이 성공적으로 생성되면 각 가상 디스크 (VMDK)의 스냅샷이 생성됩니다. 디스크마다 가상 디스크의 모든 데이터가 포함된 전체 스냅샷입니다.
두 번째 스냅샷은 첫 번째 스냅샷 이후의 신규 데이터 또는 수정된 데이터만 포함합니다. 스냅샷 1 이후에 변경되지 않은 데이터는 포함되지 않습니다.
대신, 스냅샷 2는 스냅샷 1에서 변경되지 않은 데이터에 대한 참조를 포함합니다.
스냅샷 3은 스냅샷 2 이후의 신규 또는 변경된 데이터를 포함하지만 스냅샷 1 또는 2에서 변경되지 않은 데이터는 포함하지 않습니다. 대신, 스냅샷 3은 스냅샷 1과 스냅샷 2의 블록에서 변경되지 않은 데이터에 대한 참조를 포함합니다.
VMware VM의 모든 후속 스냅샷에 이와 같은 과정이 반복됩니다. 스냅샷은 항상 백업 및 DR에서 성공적으로 찍은 마지막 스냅샷을 기반으로 생성됩니다. VMware VM에 가상 디스크를 추가하면 이 디스크가 VM의 다음 스냅샷에 자동으로 포함됩니다. 포함 또는 제외 규칙을 사용하여 각 백업에 포함되는 가상 디스크를 제어할 수도 있습니다. 기본적으로 모든 가상 디스크가 볼륨 포함 규칙에 포함됩니다.
VMware VM 백업을 사용하여 데이터를 마운트하려면 다음 단계를 따르세요.
VMware VM과 작업할 시점을 선택합니다.
기존 호스트 또는 VM에 마운트할지, 새 VMware VM을 만들지 또는 소스 VMware VM의 디스크를 복원할지 선택합니다.
새 VMware VM을 만드는 경우 사용할 vCenter, ESX 호스트, 데이터 스토어와 같은 위치 변수를 선택합니다.
백업 및 DR은 스냅샷 기술을 사용하여 백업에서 새 가상 디스크를 만듭니다. 이러한 디스크는 생성 시 호스트 또는 새 VM 또는 기존 VMware VM에 연결됩니다. 이러한 가상 디스크는 쓸 수 있으며 VMware Storage VMotion 작업을 사용하여 물리적 디스크로 이전할 수 있습니다.
백업 저장용량 위치
백업 계획을 만들어 VMware VM에 적용하면 정책과 프로필에서 백업이 저장되는 위치를 지정합니다.
VMware VM 기반 백업 데이터는 백업 계획의 Direct to OnVault 템플릿을 사용하여 Google Cloud 스토리지에 직접 저장할 수 있습니다. 이 기능은 Google Cloud VMware Engine에서 작동하지만 이 기능을 사용하는 경우 충분한 대역폭이 있는지 확인하는 것이 좋습니다. 대역폭이 제한된 경우 사용자 정의 기간 동안 백업 데이터의 사본을 보관하는 로컬 스냅샷 정책을 사용하는 것이 좋습니다. 스냅샷 정책 외에도 OnVault 정책을 추가로 사용 설정하여 Google Cloud Storage 버킷에 더 오래 데이터를 저장할 수 있습니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[[["\u003cp\u003eBackup and DR Service utilizes VMware vSphere Storage APIs to create backups of VMware VMs, storing them in either the snapshot pool of the backup/recovery appliance, OnVault pools, or both.\u003c/p\u003e\n"],["\u003cp\u003eThe service uses snapshots to incrementally back up VMDK data at the VM level, where subsequent snapshots only contain new or modified data and reference unchanged data from previous snapshots.\u003c/p\u003e\n"],["\u003cp\u003eBacked up data can be mounted to create a new VMware VM or as new disks attached to a VM, restored to the source VMware VM, or cloned to a new target VMware VM.\u003c/p\u003e\n"],["\u003cp\u003eBackup data can be stored in Google Cloud Storage via OnVault policies, offering options for multi-regional, dual-region, or regional locations, and allowing up to four different OnVault policies per VM.\u003c/p\u003e\n"],["\u003cp\u003eWhen backing up older Windows Server OS versions in Google Cloud VMware Engine VMs, the system is supported, however the support team cannot assist with any OS related problems, that will require the OS vendor for support.\u003c/p\u003e\n"]]],[],null,["# Backup and DR Service for VMware VMs\n\nBackup and DR Service uses VMware vSphere Storage APIs - Data Protection to create\nbackups of VMware VMs, placing these backups either in the snapshot pool of the\nbackup/recovery appliance or in OnVault pools, or in both.\n| **Note:** Only backing up old Windows server OS versions inside the Google Cloud VMware Engine VM is supported. Installing a Backup and DR Service agent won't let you back up support team cannot assist with OS boot-up issues or other OS-related problems. In such cases, you must contact the OS vendor for support.\n\nBackup and DR uses snapshots to incrementally backup data from your VMDKs at\nthe VM level. After Backup and DR Service creates a backup of the current state of\nall VMDKs attached to an VM, you can use it to either:\n\n- Mount that data to create a new VMware VM. See\n [Mount a VMware image](/backup-disaster-recovery/docs/access-data/mount-vmware-image).\n\n- Mount that data as a new disk(s) attached to a selected VM (either the\n source VM or a different physical host or VM). See [Mount a VMware image](/backup-disaster-recovery/docs/access-data/mount-vmware-image).\n\n | **Note:** OnVault pools pointing to backup vaults don't support mount operations.\n- Restore that data to either all or selected disks attached to the source\n VMware VM. See [Restore a VMware VM](/backup-disaster-recovery/docs/restore-data/restore-vm).\n\n- Clone that data to either all or selected disks attached to a new target\n VMware VM. See [Restore a VMware VM](/backup-disaster-recovery/docs/access-data/clone-image-of-a-vm).\n\nBackup and DR can be configured to store multiple copies of each snapshot\nacross multiple locations using OnVault that writes backups to Cloud Storage,\nor StreamSnap that copies snapshots to a second backup/recovery appliance.\nBackup and DR uses automatic checksums to ensure the integrity of your data after each successful backup job.\n\nHow it works: Backup and DR VMware VM snapshots\n-----------------------------------------------\n\nData backup with VMware VMs follows these steps:\n\n1. The first successful snapshot of a VMware VM creates a snapshot of each\n virtual disk (VMDK). For each disk this is a full snapshot that contains all\n of the data on the virtual disk.\n\n2. The second snapshot only contains any new data or modified data since the\n first snapshot. Data that hasn't changed since snapshot 1 isn't included.\n Instead, snapshot 2 contains references to snapshot 1 for any unchanged data.\n\n3. Snapshot 3 contains any new or changed data since snapshot 2 but won't\n contain any unchanged data from snapshot 1 or 2. Instead, snapshot 3 contains\n references to blocks in snapshot 1 and snapshot 2 for any unchanged data.\n\nThis repeats for all subsequent snapshots of the VMware VM. Snapshots are\nalways created based on the last successful snapshot taken by Backup and DR.\nIf an additional virtual disk is added to the VMware VM, this disk is\nautomatically included in the next snapshot of the VM. You can also use\ninclude or exclude rules to control which virtual disks are included in each\nbackup. By default, all virtual disks are included in the Volume Inclusion Rule.\n\nData mount with VMware VM backups follows these steps:\n\n1. Select the VMware VM and point in time that they want to work with.\n\n2. Select if you want to mount to an existing host or VM, create a new\n VMware VM or restore the disks of the source VMware VM.\n\n3. If creating a new VMware VM, select the location variables such as which\n vCenter, ESX host and datastore to be used.\n\n4. Backup and DR uses snapshot technology to create new virtual disks from\n the backups. When these disks are created they are attached to the host or to\n the new or existing VMware VM. These virtual disks are writable, and can be\n migrated to physical disks using a VMware Storage VMotion task.\n\nBackup storage location\n-----------------------\n\nWhen you create a backup plan and apply it to a VMware VM, the policies and\nprofile specify where the backup is stored.\n\nVMware VM-based backup data can be stored directly into Google Cloud Storage,\nusing a Direct to OnVault template in the backup plan. This works for\nGoogle Cloud VMware Engine, though it is recommended to ensure\nsufficient bandwidth exists if you are using this feature. If bandwidth is\nlimited, then a local snapshot policy is recommended, which retains a copy of\nthe backup data for a user defined period of time, and in addition to the snapshot\npolicy, additional OnVault policies can be enabled to store data for longer\nperiods of time in Google Cloud Storage bucket(s).\n\nOnVault backups can be stored in a\n[Cloud Storage multi-regional location](/storage/docs/locations#location-mr),\na [Cloud Storage dual-region location](/storage/docs/locations#location-dr),\nor a [Cloud Storage regional location](/storage/docs/locations#location-r).\n\nEach VM can have up to four OnVault policies, each specifying different\nGoogle Cloud Storage buckets, which could be different storage classes and\ndifferent location types.\n\nA multi-regional storage location provides the highest availability and\nresilience. A regional storage location gives you more control over the\nphysical location of your data because you specify a single region.\n\nThe VMware administrator's guide\n--------------------------------\n\n- [Backup and DR for VMware VMs](/backup-disaster-recovery/docs/concepts/vmware-intro)\n\n- [Configure Google Cloud VMware Engine for Backup and DR protection](/backup-disaster-recovery/docs/configuration/prepare-vmware)\n\n- [Add vCenter and ESX server hosts to the management console](/backup-disaster-recovery/docs/configuration/add-vcenter-host)\n\n- [Discover and protect VMware VMs](/backup-disaster-recovery/docs/configuration/discover-and-protect-vms)\n\n- [Apply a backup template to protect a VM](/backup-disaster-recovery/docs/create-plan/apply-backup-template-to-manage-a-VM)\n\n- [Configure application settings for VMware VMs](/backup-disaster-recovery/docs/backup/configure-application-settings-for-vmware-vm)\n\n- [Restore a VMware VM](/backup-disaster-recovery/docs/restore-data/restore-vm)\n\n- [Mount a VMware image](/backup-disaster-recovery/docs/access-data/mount-vmware-image)\n\n- [Clone an image of a VMware VM](/backup-disaster-recovery/docs/access-data/clone-image-of-a-vm)\n\n- [Create LiveClone workflows](/backup-disaster-recovery/docs/access-data/create-liveclone-workflows)\n\n- [Move VM management between two backup/recovery appliances](/backup-disaster-recovery/docs/configuration/supported-vmware)"]]