Customizing Backup and Restore Process
Stash provides rich customization supports for the backup and restore process to meet the requirements of various cluster configurations. This guide will show you some examples of these customizations.
Customizing Backup Process
In this section, we are going to show you how to customize the backup process. Here, we are going to show some examples of providing arguments to the backup process, running the backup process as a specific user, ignoring some indexes during the backup process, etc.
Specifying database user
If you want to specify the postgres database user you can provide it through user param under task.params section.
The below example shows how you can pass the testuser to set the username as testuser.
apiVersion: stash.appscode.com/v1beta1
kind: BackupConfiguration
metadata:
name: sample-postgres-backup
namespace: demo
spec:
schedule: "*/5 * * * *"
task:
params:
- name: user
value: testuser
repository:
name: gcs-repo
target:
ref:
apiVersion: appcatalog.appscode.com/v1alpha1
kind: AppBinding
name: sample-postgres
retentionPolicy:
name: keep-last-5
keepLast: 5
prune: true
WARNING: Passing
useris not applicable for Basic Authentication.
Passing arguments to the backup process
Stash PostgreSQL addon uses pg_dumpall by default for backup. You can pass arguments to the pg_dumpall through args param under task.params section.
The below example shows how you can pass the --clean to include SQL commands to clean (drop) databases before recreating them.
apiVersion: stash.appscode.com/v1beta1
kind: BackupConfiguration
metadata:
name: sample-postgres-backup
namespace: demo
spec:
schedule: "*/5 * * * *"
task:
params:
- name: args
value: --clean
repository:
name: gcs-repo
target:
ref:
apiVersion: appcatalog.appscode.com/v1alpha1
kind: AppBinding
name: sample-postgres
retentionPolicy:
name: keep-last-5
keepLast: 5
prune: true
WARNING: Make sure that you have the specific database created before taking backup. In this case, Database
testdbshould exist before the backup job starts.
Running backup job as a specific user
If your cluster requires running the backup job as a specific user, you can provide securityContext under runtimeSettings.pod section. The below example shows how you can run the backup job as the root user.
apiVersion: stash.appscode.com/v1beta1
kind: BackupConfiguration
metadata:
name: sample-postgres-backup
namespace: demo
spec:
schedule: "*/2 * * * *"
repository:
name: gcs-repo
target:
ref:
apiVersion: appcatalog.appscode.com/v1alpha1
kind: AppBinding
name: sample-postgres
runtimeSettings:
pod:
securityContext:
runAsUser: 0
runAsGroup: 0
retentionPolicy:
name: keep-last-5
keepLast: 5
prune: true
Specifying Memory/CPU limit/request for the backup job
If you want to specify the Memory/CPU limit/request for your backup job, you can specify resources field under runtimeSettings.container section.
apiVersion: stash.appscode.com/v1beta1
kind: BackupConfiguration
metadata:
name: sample-postgres-backup
namespace: demo
spec:
schedule: "*/2 * * * *"
repository:
name: gcs-repo
target:
ref:
apiVersion: appcatalog.appscode.com/v1alpha1
kind: AppBinding
name: sample-postgres
runtimeSettings:
container:
resources:
requests:
cpu: "200m"
memory: "1Gi"
limits:
cpu: "200m"
memory: "1Gi"
retentionPolicy:
name: keep-last-5
keepLast: 5
prune: true
Using multiple retention policies
You can also specify multiple retention policies for your backed up data. For example, you may want to keep few daily snapshots, few weekly snapshots, and few monthly snapshots, etc. You just need to pass the desired number with the respective key under the retentionPolicy section.
apiVersion: stash.appscode.com/v1beta1
kind: BackupConfiguration
metadata:
name: sample-postgres-backup
namespace: demo
spec:
schedule: "*/5 * * * *"
repository:
name: gcs-repo
target:
ref:
apiVersion: appcatalog.appscode.com/v1alpha1
kind: AppBinding
name: sample-postgres
retentionPolicy:
name: sample-postgres-retention
keepLast: 5
keepDaily: 10
keepWeekly: 20
keepMonthly: 50
keepYearly: 100
prune: true
To know more about the available options for retention policies, please visit here.
Customizing Restore Process
Stash uses psql during the restore process. In this section, we are going to show how you can pass arguments to the restore process, restore a specific snapshot, run restore job as a specific user, etc.
Passing arguments to the restore process
You can pass arguments to the restore process through the args params under task.params section. This example will restore data from database testdb only.
apiVersion: stash.appscode.com/v1beta1
kind: RestoreSession
metadata:
name: sample-postgres-restore
namespace: demo
spec:
task:
params:
- name: args
value: --dbname=testdb
repository:
name: gcs-repo
target:
ref:
apiVersion: appcatalog.appscode.com/v1alpha1
kind: AppBinding
name: sample-postgres
rules:
- snapshots: [latest]
Specifying database user
If you want to specify the postgres database user you can provide it through user param under task.params section.
The below example shows how you can pass the testuser to set the username as testuser.
apiVersion: stash.appscode.com/v1beta1
kind: RestoreSession
metadata:
name: sample-postgres-restore
namespace: demo
spec:
task:
params:
- name: args
value: --dbname=testdb
- name: user
value: testuser
repository:
name: gcs-repo
target:
ref:
apiVersion: appcatalog.appscode.com/v1alpha1
kind: AppBinding
name: sample-postgres
rules:
- snapshots: [latest]
WARNING: Passing
useris not applicable for Basic Authentication.
Restore specific snapshot
You can also restore a specific snapshot. At first, list the available snapshot as bellow,
❯ kubectl get snapshots -n demo
NAME ID REPOSITORY HOSTNAME CREATED AT
gcs-repo-4bc21d6f 4bc21d6f gcs-repo host-0 2021-02-12T14:54:27Z
gcs-repo-f0ac7cbd f0ac7cbd gcs-repo host-0 2021-02-12T14:56:26Z
gcs-repo-9210ebb6 9210ebb6 gcs-repo host-0 2021-02-12T14:58:27Z
gcs-repo-0aff8890 0aff8890 gcs-repo host-0 2021-02-12T15:00:28Z
You can also filter the snapshots as shown in the guide here.
The below example shows how you can pass a specific snapshot id through the snapshots field of rules section.
apiVersion: stash.appscode.com/v1beta1
kind: RestoreSession
metadata:
name: sample-postgres-restore
namespace: demo
spec:
repository:
name: gcs-repo
target:
ref:
apiVersion: appcatalog.appscode.com/v1alpha1
kind: AppBinding
name: sample-postgres
rules:
- snapshots: [4bc21d6f]
Please, do not specify multiple snapshots here. Each snapshot represents a complete backup of your database. Multiple snapshots are only usable during file/directory restore.
Running restore job as a specific user
You can provide securityContext under runtimeSettings.pod section to run the restore job as a specific user.
apiVersion: stash.appscode.com/v1beta1
kind: RestoreSession
metadata:
name: sample-postgres-restore
namespace: demo
spec:
repository:
name: gcs-repo
target:
ref:
apiVersion: appcatalog.appscode.com/v1alpha1
kind: AppBinding
name: sample-postgres
runtimeSettings:
pod:
securityContext:
runAsUser: 0
runAsGroup: 0
rules:
- snapshots: [latest]
Specifying Memory/CPU limit/request for the restore job
Similar to the backup process, you can also provide resources field under the runtimeSettings.container section to limit the Memory/CPU for your restore job.
apiVersion: stash.appscode.com/v1beta1
kind: RestoreSession
metadata:
name: sample-postgres-restore
namespace: demo
spec:
repository:
name: gcs-repo
target:
ref:
apiVersion: appcatalog.appscode.com/v1alpha1
kind: AppBinding
name: sample-postgres
runtimeSettings:
container:
resources:
requests:
cpu: "200m"
memory: "1Gi"
limits:
cpu: "200m"
memory: "1Gi"
rules:
- snapshots: [latest]