Skip to content

Commit

Permalink
Apply suggestions from code review
Browse files Browse the repository at this point in the history
Co-authored-by: Tobias Brunner <tobias.brunner@vshn.ch>
  • Loading branch information
cimnine and tobru committed Sep 23, 2021
1 parent 707c70a commit e4b68ff
Showing 1 changed file with 11 additions and 11 deletions.
22 changes: 11 additions & 11 deletions docs/modules/ROOT/pages/explanations/backup.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -4,14 +4,14 @@ K8up currently implements three ways to do backups:

. xref:how-tos/backup.adoc[_PVC backups_], which work by mounting the underlying `PV` of each `PVC` and reading its files.
. xref:how-tos/application-aware-backups.adoc[_Backup commands_], which print the content, that should be backed up, to STDOUT.
. The special xref:how-tos/prebackuppod.adoc[`PreBackupPod`], which is run as part of a backup.
. xref:how-tos/prebackuppod.adoc[`PreBackupPod`], which is run as part of a backup.

This explanation guide briefly explains each backup method.

== PVC Backup

This is the most straight-forward backup approach.
What k8up basically does is that it looks at all the `PVC` definitions in a namespace.
What K8up basically does is that it looks at all the `PVC` definitions in a namespace.
For every `PVC` it creates a `Job` in that same namespace.
That `Job` will launch a `Pod`, which mounts the respective `PV`.
All the content of that `PV` is then backed-up.
Expand All @@ -23,15 +23,15 @@ It does also not work for content that is not stored in the cluster, like a mana

== Application-Aware Backups

The backup command is defined an annotation on your `Pod`.
When k8up does the backup, it will start that command in the context of your `Pod`.
The backup command is defined as an annotation on your `Pod`.
When K8up does the backup, it will start that command in the context of your `Pod`.
It uses the same method as if you are running `kubectl exec POD -- COMMAND ARGS`.
K8up will then collect everything that is written to `STDOUT`.
The collected content is then stored in the configured backup storage as text file.
The collected content is then stored in the configured backup storage as file.

This method is especially useful to back up databases, because you will get a consistent view of that database.
This is usually not guaranteed with a file-based backup, as the database may have not yet written some content to disk when k8up reads the file.
Or worse: The database modifies the file while k8up is reading it.
This is usually not guaranteed with a file-based backup, as the database may have not yet written some content to disk when K8up reads the file.
Or worse: The database modifies the file while K8up is reading it.
This can be prevented by relying on the respective tooling of your database to take backups.
For PostgreSQL, this tool is `pg_dump` for example.

Expand All @@ -40,17 +40,17 @@ Which means that it can connect to internal (and also external) endpoints to fet
It also works with a variety of database systems and likewise programs that store (some portion of) their data in-memory.

The drawback is that it transfers data via `stdout`, which is less efficient.
The reason is that Kubernetes has to relay that data from the executed command to k8up.
The reason is that Kubernetes has to relay that data from the executed command to K8up.
Another drawback is that your `Pod` must provide the tools to execute the command.
If it does not already contain that command – if it's a distro-less container for example – then the next method might be for you.

== PreBackupPod

The `PreBackupPod` builds upon the concept of the aforementioned _backup command_.
It is essentially a special `Pod` that is created by `k8up` for every backup run.
It is essentially a special `Pod` that is created by K8up for every backup run.
You have all the flexibility of the Kubernetes `Pod`-definition, like defining a special `image` or accessing a `Secret`.
After the `Pod` started, `k8up` will run the given `backupCommand` in that `Pod` as described above.
When the command finished, `k8up` will remove the `Pod` again.
After the `Pod` started, K8up will run the given `backupCommand` in that `Pod` as described above.
When the command finished, K8up will remove the `Pod` again.

The advantage of this method is its flexibility.
You can provide a special image which contains all the commands you need.
Expand Down

0 comments on commit e4b68ff

Please sign in to comment.