サポートと今すぐチャット
サポートとのチャット

vRanger 7.8 - User Guide

Introduction Configuring vRanger
Configuration overview Configuring vRanger through the Startup Wizard Configuring vRanger manually Supplemental instructions: additional repository types
Using vRanger Backup Restore Replicate VMs Reports Integrating and monitoring vRanger Using the vRanger Console vAPI Cmdlet details
Add-BackupGroupEntity Add-BackupJobTemplate Add-CIFSRepository Add-DdbReplicationRepository Add-DdbRepository Add-EsxHost Add-HypervCluster Add-HypervHost Add-HypervRestoreJobTemplate Add-NFSRepository Add-NVSDRepository Add-PhysicalMachine Add-RdaRepository Add-ReplicationJobTemplate Add-RestoreFromManifestJobTemplate Add-RestoreJobTemplate Add-VirtualAppforLinuxFLR Add-VirtualAppforLinuxFLRVA Add-VirtualCenter Disable-Job Dismount-LinuxVolume Enable-Job Get-AddressBook Get-BackupGroupEntity Get-CatalogSearchData Get-CatalogStatus Get-ConfigOption Get-Connection Get-CurrentTemplateVersionID Get-Datastore Get-GlobalTransportFailover Get-InventoryEntity Get-IsInventoryRefreshing Get-Job Get-JobTemplate Get-MonitorLog Get-Network Get-PhysicalMachineDiskMap Get-Repository Get-RepositoryJob Get-RepositorySavePoint Get-RestoreDiskMap Get-SavepointDisk Get-SavepointManifest Get-Savepoints Get-TransportFailover Get-VirtualApplianceConfig Get-VirtualApplianceDeploymentStatus Get-VirtualApplianceReconfigStatus Get-VirtualMachinesUnderInventory Get-VmDisk Get-VMDKVolume Install-VirtualAppliance Mount-LinuxVolume New-BackupFlag New-BackupGroupMember New-Daily Schedule New-EmailAddress New-IntervalSchedule New-MonthlySchedule New-ReplicationFlag New-RestoreFlag New-SMTPServer New-TransportConfiguration New-VirtualAppliance New-WeeklySchedule New-YearlySchedule Remove-AllMount Remove-BackupGroupEntity Remove-BackupGroupMember Remove-Catalog Remove-DdbStorageUnit Remove-JobTemplate Remove-LinuxVolume Remove-Repository Remove-SavePoint Remove-VirtualAppliance Remove-VirtualApplianceConfiguration Run-JobsNow Run-ReplicationFailover Run-ResumeReplicationFailover Run-TestReplicationFailover Set-Cataloging Set-CBTonVM Set-LinuxVolume Set-MountPath Set-Resources Stop-vRangerJob Update-BackupJobTemplate Update-GlobalTransportFailover Update-HypervRestoreJobTemplate Update-Inventory Update-ReplicationJobTemplate Update-RestoreJobTemplate Update-VirtualAppliance Update-VirtualApplianceConfiguration
About us

Determining application consistency

Previous Next


Backup > Determining application consistency

Application consistency for virtual backups

Previous Next


Backup > Determining application consistency > Application consistency for virtual backups

By default, vRanger does not provide quiescing during backups. When you enable the Enable Guest Quiescing option, quiescing in vRanger is provided by leveraging the VMware® Tools installed in the VM.
Crash consistent: A crash-consistent backup is analogous to pulling the plug on a server and then backing up the data. The state of the data that is being backed up with respect to the users of the data is indeterminate. Restoring a crash-consistent image is equivalent to rebooting a server after a hard shut-down.
File-system consistent: File-system consistency is achieved through standard quiescing by using the VMware Sync Driver, which ensures that no file-system writes are pending when the snapshot is taken. For normal VMs, file-system consistency is adequate, although it can cause corruption in database applications.
Application consistent: Consistency of VSS-compatible applications is achieved by freezing application I/Os prior to creating the VM snapshots. This option ensures that all application writes requests in the machines memory are committed to disk before the snapshot is taken.
The level of consistency provided by the Enable Guest Quiescing option depends on the version of VMware® ESXi™ — and the corresponding VMware Tools — and the guest operating system. The following table provides more detail on what is needed to achieve various levels of consistency:
vRanger can provide two levels of consistency for Hyper-V® VM backups: file-system consistency and application consistency.
Crash consistent: A crash-consistent backup is analogous to pulling the plug on a server and then backing up the data. The state of the data that is being backed up with respect to the users of the data is indeterminate. Restoring a crash-consistent image is equivalent to rebooting a server after a hard shut-down.
Application consistent: vRanger engages the Microsoft Volume Shadow Copy Services (VSS) to put supported applications into a consistent state during a backup. This option ensures that all application writes requests in the machines memory are committed to disk before the snapshot is taken, which means that the application and data can be reliably recovered from the backup archive.

Application consistency for physical backups

Previous Next


Backup > Determining application consistency > Application consistency for physical backups

File-system consistent: File-system consistency is achieved without any additional tools or configurations. File-system consistency ensures that no file system writes were lost during the backup process.
Application consistent: vRanger engages the Microsoft VSS to put supported applications into a consistent state during a backup. This option ensures that all application writes requests in the machines memory are committed to disk before the snapshot is taken, which means that the application and data can be reliably recovered from the backup archive.

Understanding retention policies and space-saving technologies

Previous Next


Backup > Understanding retention policies and space-saving technologies

Full backups: Each savepoint is a complete backup set. Deleting a savepoint has no bearing on the recoverability of any other full savepoint.
Incremental backups: Incremental backup jobs backup only the blocks that have changed since the last backup — full or incremental. Restoring an incremental savepoint requires the parent full and every incremental between the full and the selected incremental.
Differential backups: A differential backup contains the data that has changed since the last full backup. Each differential backup includes the contents of the previous differential, which in retention terms means that only the parent full and the most recent differential are required for a restore.
Day 1: A full backup is taken.
Day 2: A full backup is taken.
Day 3: A full backup is taken.
Day 4: A full backup is taken.
Day 5: A full backup is taken.
Day 6: A full backup is taken.
Day 7: A full backup is taken.
Day 8: A full backup is taken. The savepoint from Day 1 is removed.
Day 9: A full backup is taken. The savepoint from Day 2 is removed.
関連ドキュメント