Schedule Policies
Schedule policies automate backup operations by defining when and how often backups run. Portworx Backup supports two types of schedule policies that help ensure backups are performed regularly and reliably.
You cannot create a backup schedule or a schedule policy if the cluster is in Delete Pending or Offline state.
Schedule policy types
| Policy Type | Retention Control | Incremental Count | Auto-Delete | Use Case |
|---|---|---|---|---|
| Object unlocked | Configurable | Configurable | Manual | Flexible backup automation as per your requirements |
| Object locked | Based on object-lock policy set on the object store used in the backup target location | Fixed (default: 5) | Optional | For more strict compliance and immutable backup requirements |
Frequency types
Schedule policies support multiple frequency types to accommodate different schedule backup requirements.
- Periodic: Runs at fixed intervals defined in minutes and hours
- Daily: Runs every day at a specified time (hours and minutes from midnight)
- Weekly: Runs on weekly basis on specified day(s) of the week at a configured time. It has two options to define the schedule:
- Single day/Multiple day: Runs on a single day or multiple days of the week at a configured time. For example, you can schedule a backup to run every Monday and Thursday at 2:00 AM, or Monday and Tuesday at 3:00 AM.
- Bi-weekly: Runs every two weeks on specified day(s) of the week at a configured time. For example, you can schedule a backup to run every two weeks on Monday and Thursday at 2:00 AM, or every two weeks on Tuesday at 3:00 AM.
- Monthly: Runs on a specified day within the month at a configured time. It has two options to define the schedule:
- Specific date: Runs on a specified day within specific months at a configured date and time.
- Relative date: Runs on a specified day of the week based on its relative position within the month (e.g., "2nd week, Monday" or "last Friday of the month") at a configured time.
For monthly schedules on Stork versions earlier than 26.2.0, if the specified day exceeds the number of days in the current month, the schedule rolls over to the next month.
All schedule policies execute based on the connected application cluster's local time zone. See Configure time zone for details.
Enhanced scheduling capabilities when using Stork version 26.2.0 or later
When creating schedule policies on clusters running Stork 26.2.0 or later, you have more flexibility in defining the schedule. The following table summarizes the capabilities available for the two options:
| Feature | Stork earlier than 26.2.0 | Stork 26.2.0 and later |
|---|---|---|
| Weekly - Multiple days | Single day selection only | Select multiple days per week |
| Biweekly scheduling | Not available | Available for schedules running every two weeks |
| Monthly - Specific months | Runs every month (no month selection) | Select specific months for the schedule |
| Monthly - Relative date | Not available | Schedule by position in month (e.g., "2nd week, Monday") |
When creating a schedule policy, ensure you select the correct Stork version option to see the features available for your environment.
When your application cluster runs Stork earlier than 26.2.0, you cannot create scheduled backups using the new schedule policy features. Create a schedule policy using the Stork earlier than 26.2.0 option when creating the schedule policy. Only those policies are available to select when creating a scheduled backup.
For application clusters running Stork 26.2.0 or later, you can create scheduled backups using schedule policies created with either option.
For detailed steps on creating schedule policies, see Create schedule policies.
Configure time zone
All schedule policies are executed based on the local time zone of the connected application cluster. This means that the timing for scheduled operations, such as backups or snapshots, aligns with the time zone configured on the cluster where the application is running, rather than the time zone of Portworx Backup cluster. As a result, it is important to ensure that the application cluster's time zone is correctly set to avoid unexpected schedule execution times.
Set schedule time zone with Portworx Enterprise
If you have deployed Portworx Backup with Portworx Enterprise, you need to modify the StorageCluster by adding an environment variable to the Stork component inside the StorageCluster spec with the following command:
kubectl patch storagecluster <stc-name> -n <stc-ns> --type='json' -p='[
{
"op": "add",
"path": "/spec/stork/env",
"value": [
{
"name": "TZ",
"value": "<country-name>/<city-name>"
}
]
}
]'
This command patches a StorageCluster object in Kubernetes using a JSON patch. Where:
-
kubectl patch: The Kubernetes CLI command used to modify a live resource without replacing the whole YAML -
storagecluster <stc-name>: targets a StorageCluster resource with the name you specify -
-n <stc-ns>: the namespace where the StorageCluster resides -
--type='json': specifies that this is a JSON Patch (as defined by RFC 6902) -
-p='[...]': the actual patch operations go here in JSON format -
op:add→ adds a new field or array to the object -
path: /spec/stork/env→ this is the path to the environment variables list for the stork component inside theStorageClusterspec. -
value→ adds a single environment variable -
name: TZ→ timezone -
value: "<country-name>/<city-name>"→ sets the timezone to the specified region
For example: America/Los_Angeles, after applying this command, the stork container will have an environment variableTZ=America/Los_Angeles, which controls the timezone the container runs in.
Set schedule time zone without Portworx Enterprise
If you have deployed only Portworx Backup without Portworx Enterprise in your environment, then to set schedule time zone you need to update the env section of Stork deployment spec on all application clusters as shown below:
containers:
env:
- name: TZ
value: <country-name>/<city-name>
For example, if you update value: Europe/London, the schedules fetch run on London's time zone.