Backup policy best practices

Define policy template schedules to meet data capture window requirements, RPOs, and RTOs. For example if a daily capture must be performed some time between 7:00 PM and 7:00 AM, then give the policy a capture window of 19:00 to 7:00. Giving the policy the widest window possible gives the maximum flexibility for the scheduler to schedule all needed jobs.

The time window specified defines the allowed start time for the data capture job. Jobs started at the end of the window is allowed to run through completion.

The following topics detail the best practices for the different policy template policies.

Production to snapshot policies

Recent data is accessed the most frequently. Because of this, you may only need to retain several days of snapshots data (provided you also have OnVault policies with longer retention). You can schedule a snapshot policy schedule that occurs during a specific frequency and time window or on a continuous basis. The minimum recommended frequency for a snapshot policy is one hour (local RPO) although log backups can be run as often as every 15 minutes.

Windowed schedule: one snapshot per window

Most Production to Snapshot policies are designed to take a single snapshot of data in a 24 hour window. Single snapshots can be scheduled to take place within a window that may or may not respect day boundaries (for example, 7 PM to 7 AM).

As an example, you can create a snapshot policy schedule that crosses a day boundary and takes a single snapshot during a specific time window, by setting the following:

  • Schedule type of Windowed (default)
  • Snap on these days: Everyday except Never
  • The window to open and close as needed, typically set from 19:00 to 07:00
  • The frequency to Once Per Window
  • The desired retention time (for example, retain for 2 days)

With this windowed schedule, the day boundary (midnight) is ignored.

Windowed schedule: multiple snapshots in a window

In some cases you may want to capture multiple snapshots within a time window. This approach requires careful planning since it may result in the consumption of system resources and could lead to a situation where snapshots are constantly being taken.

As an example, you can create a snapshot policy schedule that takes multiple snapshots during a specific time window, by setting the following:

  • Schedule type of Windowed(default)
  • Snap on these days: Everyday except Never
  • The window to open as needed, and may or may not span the day boundary.
  • A frequency that does not overlap the time required to take a snapshot. The default is every eight hours. The minimum recommended frequency for a snapshot policy is to run every 1 hour (local RPO).
  • The desired retention time (for example, retain for 2 days)

With this approach, the job runs according to its frequency within the specified window. Any job already running at the close of the window continues to run until it completes.

Continuous schedule: run daily at regular intervals

You can configure a snapshot policy schedule that continuously runs on a daily basis (24/7) at a time interval of every x minutes or hours. For example, you can create a snapshot policy where jobs run daily every four hours, with the first job starting at 1:00 am.

As an example, you can create a snapshot policy that is scheduled to run continuously at a regularly set interval, by setting the following:

  • Schedule type of Continuous
  • A frequency that does not overlap the time required to take a snapshot. The default is every eight hours. The minimum recommended frequency for a snapshot policy is to run every 1 hour (local RPO).
  • Time to initiate the first snapshot job.
  • The desired retention time (for example, retain for 2 days)

You also have the option of scheduling a continuous job to run once per day (the longest continuous policy schedule period without defining a windowed policy schedule). In this case you would specify to Run Every 24 hours, which equals a continuous daily schedule.

OnVault policies

OnVault policies allow you to send data to Google Cloud Storage (an OnVault pool). A schedule within the policy is used to send the most recent data to object storage. After the initial ingest of data, an OnVault capture operation follows the incremental forever data capture process.

When sending data to storage defined by the OnVault pool, an HTTPS connection is used to ensure data security over the network. The OnVault pool's compression option is on by default to minimize network traffic.

When accessing data in an OnVault pool's defined storage location, note the following:

  • Appliances can create clones.
  • Appliances can mount data, but because data is first copied to the snapshot pool then mounted, it is not recommended.
  • LiveClones cannot be created.

You can create three types of OnVault policies:

  • Snapshot to OnVault policies capture data in a snapshot pool and then copy the data in the snapshot pool to a Google Cloud Storage bucket defined by an OnVault pool.
  • Direct to OnVault policies allow VMware VM backups to be sent directly to a Google Cloud Storage bucket defined by an OnVault pool.
  • OnVault to OnVault policies replicate data from one OnVault storage object pool to another another OnVault storage pool.

Snapshot to OnVault policy

Use these instructions to create a Snapshot to OnVault policy schedule that, within a defined window once a day, sends the most recent snapshot data to object storage defined by an OnVault pool, by setting the following:

  • Vault on these days: Everyday
  • The window to open and close as needed. Typically set to 19:00 to 18:50

  • The desired retention time (for example, retain for 3 years

Direct to OnVault policy

Use these instructions to create a Direct to OnVault policy schedule that, within a defined window once a day, sends the most recent incremental updates directly to storage defined by an OnVault pool, by setting the following:

  • On these days: Everyday
  • The window to open and close as needed. Typically set to 19:00 to 18:50
  • The desired retention time (for example, retain for 3 years)

OnVault to OnVault policy

To create an OnVault to OnVault policy schedule that, within a defined window once a day, sends the most recent incremental updates directly to storage defined by an OnVault pool, by setting the following:

  • On these days: Everyday
  • The window to open and close as needed. Typically set to 19:00 to 18:50
  • The desired retention time (for example, retain for 3 years)
  • Verify the source OnVault pool is set correctly
  • Select the target OnVault pool. This is the second OnVault pool to which data will be replicated to from the source OnVault pool.

Production to mirror policies

Best practices for Production to Mirror policies depend on which replication option you plan to use. This section outlines the policy best practices for the StreamSnap replication method offered by the appliance.

Production to mirror: StreamSnap replication policies

Production to Mirror policies that use StreamSnap replication are tied to a specific snapshot policy. They use the schedule and frequency settings of the associated snapshot policy in the template.

StreamSnap replicates data snapshots to a remote backup/recovery appliance over a high quality network, which can provide RPOs as low as one hour. For VMware VMs, snapshot replication is streamed to the second backup/recovery appliance in parallel to the snapshot being copied. Streaming of a VMware VM is performed to avoid waiting until the local snapshot job completes before initiating replication.

StreamSnap replication does the following:

  • Achieves Recovery Point Objectives as short as one hour. The StreamSnap replication policy relies on the associated production to snapshot policy for recovery point objectives and the other advanced snapshot settings. A StreamSnap policy can point to any snapshot policy with frequency of one hour or longer (remote recovery point objectives).
  • Uses an existing IP network to replicate data.
  • Replicates large amounts of data to remote users (for example, test and development environments).
  • Retains multiple point-in-time snapshot images at the remote site, with retention behavior being driven by the settings in the StreamSnap policy.
  • Makes fail-over to a host on the remote site simple.
  • Enables incremental reverse replication (syncback) to the local backup/recovery appliance.
  • Compresses and encrypts replicated data to the second backup/recovery appliance. You can disable compression if the data is already compressed (for example, for images and videos).

When you apply the backup template to an application or VM in the App Manager, the Monitor records the results of the StreamSnap job and it appears as a single job. Once replication is complete, two jobs appear in Monitor with a span Succeeded status; one for the snapshot job and one for the StreamSnap job (see StreamSnap job error handling). If there is a job failure, either for the StreamSnap job or the snapshot job, two job entries appear to identify which job was successful.

What's next