You can export an application object to a YAML file by using the oc get command.

[user@host ~]$ oc -n prod get deployment/mysql -o yaml > backup_deployment.yaml

The backup_deployment.yaml file has all deployment details such as specifications, metadata, and status.

[user@host ~]$ cat backup_deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "2"
  labels:
    app: mysql
  name: mysql
  namespace: prod
...output omitted...
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  selector:
    matchLabels:
      app: mysql
      ...output omitted...
status:
  availableReplicas: 1
...output omitted...

You can export all other application resources by using the same oc get command.

You can create the application resources in a new project by using the backup YAML files. You can remove the metadata.namespace field and use the oc create -f command to create each resource in the new project.

Apart from the metadata.namespace field, all backup resource files have runtime and status information such as metadata.annotations, metadata.creationTimestamp, metadata.resourceVersion, metadata.generation, and status. You can remove these fields and keep cleaned backup resource files to create resources in a new project.

The following example demonstrates importing some required resources for an application:

[user@host ~]$ oc create -f clean_backup_deployment.yaml -n prod-backup
deployment.apps/mysql created

[user@host ~]$ oc create -f service-mysql.yaml -n prod-backup
The Service "mysql" is invalid: spec.clusterIPs: Invalid value: []string{"172.30.210.241"}: failed to allocate IP 172.30.210.241: provided IP is already allocated

The mysql deployment was created successfully in the prod-backup project by using the backup YAML file.

However, the metadata and status removal does not work for all resources. Some resources require additional modifications.

The service resource creation failed because the IP address is already allocated to the mysql service in the prod project. The service backup YAML file requires more modification for a successful creation.

The modification depends on the resource type. Service resource creation requires the removal of not only the metadata and status fields but also the spec.clusterIP field from the YAML file.

You can use a text editor or other tools to remove these fields. For example, you can use the yq tool to process the YAML file and remove a specific field.

[user@host ~]$ cat service-mysql.yaml \
  | yq d - metadata.namespace \
  | yq d - spec.clusterIP*  > clean-service-mysql.yaml

[user@host ~]$ oc create -f clean-service-mysql.yaml -n prod-backup
service/mysql created

Similar to the service resource, the route resource creation requires the removal of the metadata.namespace and spec.host fields from the YAML file.

[user@host ~]$ cat route-frontend.yaml \
  | yq d - metadata.namespace \
  | yq d - spec.host  > clean-route-frontend.yaml

[user@host ~]$ oc create -f clean-route-frontend.yaml -n prod-backup
route.route.openshift.io/etherpad created

You do not need to create all the exported resources. The new project creates some resources, such as service accounts, secrets, and role bindings. An application also creates some resources. The deployment resource creates the replicasets resource, and the deploymentconfig resource creates the replicationcontrollers resource.

You can configure the OpenShift internal registry operator to expose the registry externally with the following command:

[user@host ~]$ oc patch \
  configs.imageregistry.operator.openshift.io/cluster \
  --patch '{"spec":{"defaultRoute":true}}' \
  --type merge

The operator creates a default-route route to expose externally the registry that uses the following URL format:

default-route-openshift-image-registry.<apps-domain>

You can use the following command to retrieve the registry URL from the created route and save it in an environment variable for later use:

[user@host ~]$ REGISTRY=$(oc get \
  route default-route \
  -n openshift-image-registry \
  --template '{{.spec.host}}')

OpenShift users who do not have access to the openshift-image-registry namespace can retrieve the registry URL from any image stream:

[user@host ~]$ oc -n openshift get is/cli \
  -ojsonpath="{.status.publicDockerImageRepository}{'\n'}"

default-route-openshift-image-registry.apps.ocp4.example.com/openshift/cli

You can then log in to the internal registry by using your OpenShift username and authentication token with the following command:

[user@host ~]$ podman login \
  -u $(oc whoami) \
  -p $(oc whoami -t) \
  --tls-verify=false \
  $REGISTRY

Alternatively, you can use the oc registry login command to log in to the internal registry without the need to specify your credential and registry URL. The oc registry login command automatically uses your authentication token and the internal registry URL from the OpenShift cluster.

The oc command stores the credentials in the ${HOME}/.docker/config.json file in Base64 format. The Podman, Skopeo, and Docker clients can use the authentication details from that file to access an image registry.

[user@host ~]$ oc registry login
info: Using registry public hostname default-route-openshift-image-registry.apps.ocp4.example.com
Warning: the default reading order of registry auth file will be changed from "${HOME}/.docker/config.json" to podman registry config locations in the future version of oc. "${HOME}/.docker/config.json" is deprecated, but can still be used for storing credentials as a fallback. See https://github.com/containers/image/blob/main/docs/containers-auth.json.5.md for the order of podman registry config locations.
Saved credentials for default-route-openshift-image-registry.apps.ocp4.example.com

To export the image from outside the cluster, expose the internal registry and use the skopeo command to copy the image to a remote registry:

[user@host ~]$ skopeo copy \
  docker://${REGISTRY}/project_name/imagestream:tag \ 
  docker://remote-registry.example.com/path/to/image:remotetag 

Skopeo can copy images to other locations such as a local directory or a .tar archive. See the references section for detailed use of the skopeo copy command.

If Skopeo is not available on your system, then you can use Podman or Docker to pull the image in the local container registry. You can then export the image as a .tar file with the podman save command or push the image to a remote registry.

[user@host ~]$ podman pull \
  ${REGISTRY}/project_name/imagestream:tag

[user@host ~]$ podman save \
  ${REGISTRY}/project_name/imagestream:tag \
  | bzip2 > image_backup.tar.bz2

Alternatively, you can use the oc image mirror command to copy images to a local or remote location, similar to the skopeo copy command:

[user@host ~]$ oc image mirror \
  ${REGISTRY}/project_name/imagestream:* \ 
  remote-registry.example.com/path/to/image

To export a container image from within the cluster, you can use any available container tools in a pod to copy the image to the location of your choice, such as a persistent volume on NFS storage, S3 storage, or a remote registry.

You can use the following YAML file as an example to create a Kubernetes job that exports the container image to a persistent volume by using the OpenShift client:

apiVersion: batch/v1
kind: Job
metadata:
  name: backup-image
  namespace: application
  labels:
    app: backup
spec:
  backoffLimit: 1
  template:
    metadata:
      labels:
        app: backup
    spec:
      containers:
      - name: backup
        image: image-registry.openshift-image-registry.svc:5000/openshift/cli:latest
        env:
        - name: REGISTRY_AUTH_FILE
          value: /tmp/dockercfg.json
        command: ["/bin/bash", "-c"]
        args:
        - | 
          oc registry login
          oc image mirror \
            image-registry.openshift-image-registry.svc:5000/application/myapp:* \
            file://myapp --dir /backup
        volumeMounts: 
          - mountPath: /backup
            name: backup
...output omitted...
      volumes: 
      - name: backup
        persistentVolumeClaim:
          claimName: backup-volume

You can import an image to an image stream in any of your projects by using the same container tools as for the export. Similar to the export, you can use the following skopeo command to import an image from a remote repository:

[user@host ~]$ skopeo copy \
  docker://remote-registry.example.com/myimage:latest \
  docker://${REGISTRY}/project_name/mynewimagestream:latest

You can also use the oc image mirror command to copy images in a similar way to the skopeo copy command:

[user@host ~]$ oc image mirror \
  remote-registry.example.com/myimage:latest \
  ${REGISTRY}/project_name/mynewimagestream:latest

You can use Podman or Docker to import an image, although the process uses more steps, because you must import the image to the local container engine registry and rename the image to use the new registry name.

The following commands import an image in the Podman local registry from a compressed archive and push it to the OpenShift internal registry:

[user@host ~]$ podman load \
  -i image_backup.tar.bz2
...output omitted...
Storing signatures
Loaded image(s): registry.apps.ocp4.example.com/application/myapp:1.2.3

If needed, rename the image with the podman tag command to match the new OpenShift project and image stream:

[user@host ~]$ podman tag \
  registry.apps.ocp4.example.com/application/myapp:1.2.3 \
  ${REGISTRY}/newproject/myapp:1.2.3

Then, send the image to the OpenShift internal registry:

[user@host ~]$ podman push \
  ${REGISTRY}/newproject/myapp:1.2.3
...output omitted...
Writing manifest to image destination
Storing signatures

Volume snapshot capability is available only with Container Storage Interface (CSI) drivers. However, snapshot functions are not implemented for all CSI drivers. The following list includes examples of CSI drivers with the snapshot capability:

Kubernetes provides similar API resources to PersistentVolume and PersistentVolumeClaim to create and manage volume snapshots.

[user@host ~]$ oc get volumesnapshot
NAME         READYTOUSE   SOURCEPVC          ...  SNAPSHOTCONTENT
my-snapshot  true         application-data   ...  snapcontent-798...cf6

After the snapshot is created, it can function as a source to create a PVC and for a pod to use it. The following example is a YAML file for creating a persistent volume from a snapshot:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-snapshot-volume 
  namespace: application 
spec:
  storageClassName: ocs-external-storagecluster-ceph-rbd 
  accessModes:
  - ReadWriteOnce
  dataSource:
    apiGroup: snapshot.storage.k8s.io
    kind: VolumeSnapshot
    name: my-snapshot 
  resources:
    requests:
      storage: 1Gi 

If your application provides specialized backup tools, you can use them to export the data to your chosen location. The following example is a cron job definition to back up a MariaDB database and to store the backup file on AWS S3 storage:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: backup-db
spec:
  schedule: "0 0 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          initContainers:
            - envFrom:
              - secretRef:
                  name: mariadb
              image: quay.io/redhattraining/mariadb:10.5
              command: ["/bin/bash", "-c"]
              args: 
                - >
                  mariadb-dump -u "${MARIADB_USER}" -p"${MARIADB_PASSWORD}"
                  -h mariadb "${MARIADB_DATABASE}"
                  | bzip2 > /backup/backup-$(date '+%Y%m%d-%H%M').sql.bz2;
                  ls -al /backup
              name: backup
              volumeMounts:
                - mountPath: /backup
                  name: backup
          containers:
            - image: docker.io/amazon/aws-cli:latest
              command: ["/bin/bash", "-c"]
              args: 
                - >
                  aws s3 cp --no-progress /backup/backup* s3://backup/
              name: s3cli
              volumeMounts:
                - mountPath: /backup
                  name: backup
                - mountPath: /root/.aws
                  name: aws-creds
          volumes:
            - name: backup
              emptyDir: {}
            - name: aws-creds
              secret:
                secretName: s3config

If the application does not provide backup tools, then you can use volume snapshot to back up the application data. Depending on the storage provider that is available in the OpenShift cluster, you might rather export the snapshot content to an external storage location.

The following example is a job definition that uses an existing snapshot volume to archive the snapshot content, and exports the backup file to a remote S3 bucket:

apiVersion: batch/v1
kind: Job
metadata:
  name: backup
  namespace: application
  labels:
    app: backup
spec:
  backoffLimit: 1
  template:
    metadata:
      labels:
        app: backup
    spec:
      containers:
      - name: backup
        image: docker.io/d3fk/s3cmd:latest
        command: ["/bin/sh", "-c"]
        args:
        - | 
          tar czf -C /snapshot /tmp/mybackup.tar.gz .
          s3cmd cp /tmp/mybackup.tar.gz s3://backup/
        volumeMounts: 
          - mountPath: /snapshot
            name: snapshot
...output omitted...
      volumes: 
      - name: snapshot
        persistentVolumeClaim:
          claimName: my-snapshot-volume

Another option is to export the snapshot content locally from a pod by using the oc cp command. The following example is a pod definition, where the snapshot data is mounted, which you can use to export the data to your workstation:

apiVersion: v1
kind: Pod
metadata:
  name: export
spec:
  containers:
  - image: registry.access.redhat.com/ubi9:latest
    command: ["/bin/bash", "-c"]
    args:
    - sleep infinity 
...output omitted...
    volumeMounts: 
      - mountPath: /snapshot
        name: snapshot
  volumes: 
  - name: snapshot
    persistentVolumeClaim:
      claimName: my-snapshot-volume

You can use the following oc command to copy the snapshot data from the export pod to your local machine:

[user@host ~]$ oc cp export:/snapshot /tmp/backup

After the snapshot content is exported to a remote location, you can safely remove the snapshot PVC and the volume snapshot, to free up space on the storage back end.

To import the data to another cluster or namespace, create a pod or a job where the application volume is mounted, and copy the exported data to the pod.

The following example is a YAML file for creating a job that fetches a remote backup from an S3 bucket and extracts the archive to the application volume:

apiVersion: batch/v1
kind: Job
metadata:
  name: restore
  namespace: application
  labels:
    app: restore
spec:
  backoffLimit: 1
  template:
    metadata:
      labels:
        app: restore
    spec:
      containers:
      - name: restore
        image: docker.io/d3fk/s3cmd:latest
        command: ["/bin/bash", "-c"]
        args: 
        - |
          s3cmd cp s3://backup/mybackup.tar.gz /tmp/
          tar xvzf /tmp/mybackup.tar.gz -C /data
        volumeMounts: 
          - mountPath: /data
            name: application-data
...output omitted...
      volumes: 
      - name: application-data
        persistentVolumeClaim:
          claimName: application-data

You can restore the data to an existing volume, or create a new one. If you use a new volume, then you must update the application to use that new volume.