Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions modules/administration-guide/nav.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -107,6 +107,7 @@
** xref:configuring-fuse.adoc[]
*** xref:enabling-access-to-dev-fuse-for-openshift.adoc[]
*** xref:enabling-fuse-for-all-workspaces.adoc[]
** xref:devworkspace-backup.adoc[]
* xref:managing-ide-extensions.adoc[]
** xref:extensions-for-microsoft-visual-studio-code-open-source.adoc[]
** xref:running-the-open-vsx-on-premises.adoc[]
Expand Down
99 changes: 99 additions & 0 deletions modules/administration-guide/pages/devworkspace-backup.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,99 @@
:_content-type: CONCEPT
:description: DevWorkspace backup
:keywords: backup, storage
:navtitle: DevWorkspace backup
//:page-aliases:

[id="devworkspace-backup"]
= Workspace backup for {prod}

Starting from {prod} version v7.115.0, the {devworkspace} backup job allows for periodic backups of {devworkspace} data to a specified backup location.
Once enabled and configured, the backup job will run at defined intervals to create backups of {devworkspace} data.
The backup controller depends on an OCI-compatible registry e.g., https://quay.io[quay.io] used as an image artifact storage for backup archives.

The backup makes a snapshot of Workspace PVCs and stores them as tar.gz archives in the specified OCI registry.
NOTE: By default, the {devworkspace} backup job is disabled.

The backup is configurable using `DevWorkspaceOperatorConfig` with the following fields:

* *`enable`*: Set to `true` to enable the backup job, `false` to disable it. Default: `false`.
* *`schedule`*: A Cron expression defining how often the backup job runs. Default: `"0 1 * * *"`.
* *`registry.path`*: A base registry location where the backup archives will be pushed.
+
The value provided for registry.path is only the first segment of the final location. The full registry path is assembled dynamically, incorporating the name of the workspace and the :latest tag, following this pattern:
+
`<registry.path>/<namespace>/<devworkspace-name>:latest`

* *`registry.authSecret`*: (Optional) The name of the Kubernetes Secret containing credentials to access the OCI registry. If not provided, it is assumed that the registry is public or uses integrated OpenShift registry.
* *`oras.extraArgs`*: (Optional) Additional arguments to pass to the `oras` CLI tool during push and pull operations.


There are several configuration options to customize the logic:

== Integrated OpenShift container registry
This option is available only on OpenShift clusters with integrated container registry enabled and requires no additional configuration.

To enable the backup use following configuration in the global DWOC:

[source,yaml,subs="+attributes,+quotes"]
----
apiVersion: controller.devfile.io/v1alpha1
kind: DevWorkspaceOperatorConfig
metadata:
name: devworkspace-operator-config
namespace: $OPERATOR_INSTALL_NAMESPACE
config:
routing:
defaultRoutingClass: basic
workspace:
backupCronJob:
enable: true
registry:
path: default-route-openshift-image-registry.apps.{cluster ID}.openshiftapps.com
schedule: '0 */4 * * *' # cron expression with backup frequency
imagePullPolicy: Always
----

**Note:** The `path` field must contain the URL to your OpenShift integrated registry given by the cluster.

Once the backup job is finished, the backup archives will be available in the {devworkspace} {namespace} under a repository
with a matching {devworkspace} name.

== Regular OCI-compatible registry
To use a regular OCI-compatible registry for backups, you need to provide registry credentials. Depending on your
RBAC policy, the token can be provided via a secret in the Operator {namespace} or in each {devworkspace} {namespace}.
Having the secret in the {devworkspace} {namespace} allows for using different registry accounts per {namespace} with more
granular access control.

[source,yaml,subs="+attributes,+quotes"]
----
kind: DevWorkspaceOperatorConfig
apiVersion: controller.devfile.io/v1alpha1
metadata:
name: devworkspace-operator-config
namespace: $OPERATOR_INSTALL_NAMESPACE
config:
routing:
defaultRoutingClass: basic
workspace:
backupCronJob:
enable: true
registry:
authSecret: my-secret
path: quay.io/my-company-org
schedule: '0 */4 * * *'
imagePullPolicy: Always
----
The `authSecret` must point to a real {kubernetes} Secret of type `kubernetes.io/dockerconfigjson` containing credentials to access the registry.

To create one you can use following command:

[source,shell,subs="+attributes,+quotes"]
----
kubectl create secret docker-registry my-secret --from-file=config.json -n devworkspace-controller
----
The secret must contain a label `controller.devfile.io/watch-secret=true` to be recognized by the {devworkspace} Operator.
[source,shell,subs="+attributes,+quotes"]
----
kubectl label secret my-secret controller.devfile.io/watch-secret=true -n devworkspace-controller
----