diff --git a/modules/administration-guide/nav.adoc b/modules/administration-guide/nav.adoc
index d2d702aded..d4e286c089 100644
--- a/modules/administration-guide/nav.adoc
+++ b/modules/administration-guide/nav.adoc
@@ -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[]
diff --git a/modules/administration-guide/pages/devworkspace-backup.adoc b/modules/administration-guide/pages/devworkspace-backup.adoc
new file mode 100644
index 0000000000..bdeb823e6b
--- /dev/null
+++ b/modules/administration-guide/pages/devworkspace-backup.adoc
@@ -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
+----