大多数应用都是通过备份和灾难恢复代理或通过备份和灾难恢复内置的 API 发现的。通用应用是指您通过指向要保护的一组 LVM 卷来定义的应用。
备份数据库日志
您可以在“快照”政策的“高级选项”中启用数据库日志备份。它支持使用单个快照政策来备份 Microsoft SQL Server 数据库、Oracle 数据库以及包含 Microsoft SQL Server 数据库或 Oracle 数据库的一致性组的日志。数据库日志的备份频率与数据库的备份频率是分开定义的。例如，您可以每天备份数据库，并每小时备份其日志。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-08-18。"],[[["\u003cp\u003eBackup and DR creates backups of applications by taking snapshot images of source data and storing them in targeted storage pools according to a defined backup plan schedule.\u003c/p\u003e\n"],["\u003cp\u003eThe system utilizes various change tracking mechanisms, including agent-based tracking, Compute Engine APIs, and VMware APIs, to enable efficient incremental backups.\u003c/p\u003e\n"],["\u003cp\u003eBackup plans can be changed at any time, with future backups adhering to the new settings while existing backups remain under the original plan's parameters.\u003c/p\u003e\n"],["\u003cp\u003eBackup and DR offers diverse backup options, including agent-based backups, consistency groups, generic application backups (LVM), database log backups, Compute Engine instance backups, and VMware VM backups.\u003c/p\u003e\n"],["\u003cp\u003eThe first backup of an application is a full snapshot, with subsequent backups being incremental, containing only new or modified data and referencing previous snapshots for unchanged data.\u003c/p\u003e\n"]]],[],null,["# How is a backup image created?\n\nThis page explains the stages in creating a backup and the available backup\noptions for supported [application types](/backup-disaster-recovery/docs/supportmatrix-backupdr).\n\nStages in creating a backup\n---------------------------\n\nTo create backups of supported applications such as databases, filesystems,\nand VMs, you assign a backup plan to run on a schedule, then:\n\n1. According to the [backup plan](/backup-disaster-recovery/docs/concepts/backup-plan) settings, Backup and DR takes a snapshot image\n of the source data and saves it in the targeted storage pools.\n\n2. (optional) Either immediately or at a later time according to the backup\n plan, Backup and DR copies the image from the targeted pool to an alternate\n storage pool to generate a second copy. Commonly this is from the snapshot\n pool to an OnVault pool.\n\n### When application protection takes effect\n\nApplying a backup plan does not immediately protect an application. Protection\njobs run on a schedule, according to resource availability. You can also run the\njob immediately.\n\n- The backup plan includes a schedule of when to run the protection job for\n this application, such as daily between 18:00 and 06:00 UTC, every four\n hours. If you apply protection to an application at 13:00 UTC today, then\n the first protection operation will be scheduled for 18:00 UTC.\n\n- At the scheduled time, the job is assigned a **job slot** , which may be\n available when the job is scheduled, but not always. Job slots are\n detailed in [About job slots](/backup-disaster-recovery/docs/monitor-reports/monitor-jobs).\n\n### Change backup plan\n\nYou can change an application's backup plan at any time. Future backups\noccur based on the new template. Existing backups are retained according\nto the template in use when they were created.\n\n### Change tracking mechanisms\n\nA backup/recovery appliance backs up data by making an initial full copy of the\ndata, then making copies of incremental changes. This capability requires the\nability to track and backup the changes that occur between backup operations.\nTo track those changes the backup/recovery appliance uses either\nCompute Engine APIs, the [Backup and DR agent](#agent) or\n[Backup VMware VMs](#vms).\n\nBackup and DR uses multiple methods to track changes in source data that include:\n\n- Agent based change block tracking for SQL Server\n- Agent based change tracking for Linux Logical Volumes (LVM)\n- Compute Engine snapshot change tracking\n- Oracle Block Change tracking\n- VMware based change tracking\n\n#### Agent change tracking driver\n\nThe Backup and DR agent with its change tracking driver (sometimes called the\nfilter driver) enables efficient incremental backups by tracking changes from\nthe host side. After the first complete backup of a database, the\nbackup/recovery appliance performs incremental backups by default. If your\nbackups are still always full backups, then check for the following:\n\n- The change tracking driver is stopped. In this case, restart the change\n tracking driver service.\n\n- The Windows change tracking driver is not installed. In this case,\n uninstall and then make a full install of the Windows Backup and DR\n agent.\n\n- For Linux OS, the kernel version is not supported by the installed agent.\n See [Support matrix](/backup-disaster-recovery/docs/supportmatrix-backupdr) for the supported Linux OS versions.\n\n### Full and incremental snapshots\n\nA full snapshot backs up up all the required data in the application. Full\nsnapshots, also called full backups, are taken the first time an application\nis backed up and in some uncommon situations. After the first full snapshot,\nBackup and DR takes incremental snapshots, which are much faster.\n\nIncremental snapshots work as follows:\n\n1. The first full snapshot contains all the source data.\n\n2. The second and subsequent snapshots only contain new data or modified data.\n Data that hasn't changed since the full snapshot isn't included.\n Instead, the subsequent incremental snapshots contain references to the full\n snapshot image for the unchanged data from the original snapshot.\n\n3. The next snapshot contains any new or changed data since the second snapshot\n but no unchanged data from the earlier snapshots. Instead, this snapshot\n contains references to blocks in earlier snapshots for any unchanged data.\n\nBackup options\n--------------\n\nBackup and DR lets you:\n\n- [Agent based backup](#agent)\n\n- [Backup application data in consistency groups](#app-data)\n\n- [Backup generic applications (LVM)](#generic)\n\n- [Backup database logs](#capture-logs)\n\n- [Backup Compute Engine instances](#compute)\n\n- [Backup VMware VMs](#vms)\n\n### Agent based backup\n\nThe Backup and DR agent is used to backup individual applications and groups\nof applications on virtual servers. Backup and DR agent is a small-footprint,\noperating system specific, lightweight service that can be installed on\nVMware VMs or Compute Engine instances. The Backup and DR agent provides a\nmore granular data backup capability than what is provided by VMware API calls.\nIt lets you:\n\n- Discover applications\n- Quiesce applications, for application consistency during backup\n- Enables change block tracking for incremental forever backup strategy\n- A single policy template can be applied to multiple applications that are resident on a server.\n- Avoids VMware VMs \"stun\" issues\n\nInstalling the Backup and DR agent on a physical server or VM lets you\ncreate a single policy template to backup all applications on the server\nor several policy templates to backup groups of applications.\n\n### Back up application data in consistency groups\n\nA consistency group is enabled by the Backup and DR agent. As the name implies,\nconsistency groups ensure consistent point-in-time backup and recovery across\nmultiple applications on the same host. To achieve application consistency,\nmembers of a consistency group are quiesced and backed up together using a\nsingle policy template.\n\nIf Backup and DR's database log backup option is enabled in a snapshot policy,\nthen all databases backed up by the policy template in which the snapshot policy\nresides can be recovered to the same point-in-time. Recovery and rolling forward\nof the logs (for databases) in a group is performed using the management console\nwith a single action.\n\nIn addition to making backup and recovery operations fast, consistency\ngroups consume fewer system resources (VDisks).\n\n### Back up generic applications (LVM)\n\nMost applications are discovered through the Backup and DR agent or through\nAPIs built into Backup and DR. A generic application is an application that\nyou define by pointing to a group of LVM volumes to be protected.\n\n### Back up database logs\n\nDatabase log backup is enabled in a Snapshot policy's Advanced Options. It\nenables a single Snapshot policy to backup logs for Microsoft SQL Server\ndatabases, Oracle databases, and consistency groups that contain Microsoft\nSQL Server databases or Oracle databases. The frequency at which database logs\nare backed up is defined separately from that of the database. For example, a\ndatabase can be backed up every day and its logs backed up every hour.\n\nThe frequency of database log backup is set in minutes, and the frequency at\nwhich logs are backed up must not exceed the frequency at which its associated\ndatabase is backed up. For example, if a database backup frequency is every 24\nhours, the log file backup frequency must be less than every 24 hours.\nThe smallest database log backup interval is 15 minutes.\n\nLog retention is defined separately from the retention of the Snapshot policy.\nHaving a separate retention period lets you use logs in conjunction with\ncopies of the database stored in the Snapshot pool.\n\nRegardless of how many logs are backed up during a specified log retention\nperiod, a database's backed up logs are staged to a single VDisk in the\nBackup and DR Snapshot pool. To conserve space in the Snapshot pool,\nyou can use an advanced setting to instruct the database to compress its logs.\n\n### Backup Compute Engine instances\n\nTo backup entire Compute Engine instances, the backup/recovery appliance uses\nCompute Engine APIs. Compute Engine provides change block tracking for\nBackup and DR's incremental forever backup strategy and can quiesce\napplications for application consistency during backup.\n\nWhen an entire virtual server is backed up, a fully\nfunctional virtual server (operating system, applications, and their data)\nis backed up. Having a copy of the entire virtual server ensures that the\ndata can be accessed quickly and without issues.\n\n### Back up VMware VMs\n\nBackup and DR uses VMware vSphere Storage APIs - Data Protection calls\nto back up an entire VMware virtual server (or specific disks allocated to that\nVM). These enable change block tracking for Backup and DR's\nincremental forever backup strategy and quiesce applications for application\nconsistency during backup.\n\n#### Back up a VMware VM's applications and boot volume\n\nWhen managing applications on VMs you have the option of also backing up the\nVM's boot volume. When a VM's boot volume is backed up, an image can be\npresented as a bootable VM. The image can then be migrated to a new,\npermanent location, if needed.\n\n#### Back up entire VMware VMs\n\nWhen an entire virtual server is backed up, a fully functional virtual server\n(operating system, applications, and their data) is backed up. Having a copy\nof the entire virtual server ensures that the data can be accessed fast\nand without issues. Because the image presented is a fully functional\nvirtual server, it can be migrated to a new, permanent location if needed."]]
