$ oc get dc/jenkins -o jsonpath='{ .spec.template.spec.containers[?(@.name=="jenkins")].volumeMounts[?(@.name=="jenkins-data")].mountPath }' /var/lib/jenkins
You can manually back up and restore data for your applications and projects.
Backup and restore is not guaranteed. You are responsible for backing up your own data. |
In many cases, you can back up application data by using the oc rsync
command,
assuming rsync
is installed within the container image. The Red Hat rhel7
base image contains rsync
. Therefore, all images that are based on rhel7
contain it as well. See
Troubleshooting and Debugging CLI Operations - rsync.
This is a generic backup of application data and does not take into account application-specific backup procedures, for example, special export and import procedures for database systems. |
Other means of backup might exist depending on the type of the persistent volume you use, for example, Cinder, NFS, or Gluster.
The paths to back up are also application specific. You can determine
what path to back up by looking at the mountPath
for volumes in the
deploymentconfig
.
You can perform this type of application data backup only while the application pod is running. |
Get the application data mountPath
from the deploymentconfig
:
$ oc get dc/jenkins -o jsonpath='{ .spec.template.spec.containers[?(@.name=="jenkins")].volumeMounts[?(@.name=="jenkins-data")].mountPath }' /var/lib/jenkins
Get the name of the pod that is currently running:
$ oc get pod --selector=deploymentconfig=jenkins -o jsonpath='{ .metadata.name }' jenkins-1-37nux
Use the oc rsync
command to copy application data:
$ oc rsync jenkins-1-37nux:/var/lib/jenkins /tmp/jenkins-backup/
Creating a backup of all relevant data involves exporting all important information, then restoring into a new project.
Because the |
List the project data to back up:
$ oc get all
NAME TYPE FROM LATEST bc/ruby-ex Source Git 1 NAME TYPE FROM STATUS STARTED DURATION builds/ruby-ex-1 Source Git@c457001 Complete 2 minutes ago 35s NAME DOCKER REPO TAGS UPDATED is/guestbook 10.111.255.221:5000/myproject/guestbook latest 2 minutes ago is/hello-openshift 10.111.255.221:5000/myproject/hello-openshift latest 2 minutes ago is/ruby-22-centos7 10.111.255.221:5000/myproject/ruby-22-centos7 latest 2 minutes ago is/ruby-ex 10.111.255.221:5000/myproject/ruby-ex latest 2 minutes ago NAME REVISION DESIRED CURRENT TRIGGERED BY dc/guestbook 1 1 1 config,image(guestbook:latest) dc/hello-openshift 1 1 1 config,image(hello-openshift:latest) dc/ruby-ex 1 1 1 config,image(ruby-ex:latest) NAME DESIRED CURRENT READY AGE rc/guestbook-1 1 1 1 2m rc/hello-openshift-1 1 1 1 2m rc/ruby-ex-1 1 1 1 2m NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE svc/guestbook 10.111.105.84 <none> 3000/TCP 2m svc/hello-openshift 10.111.230.24 <none> 8080/TCP,8888/TCP 2m svc/ruby-ex 10.111.232.117 <none> 8080/TCP 2m NAME READY STATUS RESTARTS AGE po/guestbook-1-c010g 1/1 Running 0 2m po/hello-openshift-1-4zw2q 1/1 Running 0 2m po/ruby-ex-1-build 0/1 Completed 0 2m po/ruby-ex-1-rxc74 1/1 Running 0 2m
Export the project objects to a project.yaml
file.
$ oc get -o yaml --export all > project.yaml
Export other objects in your project, such as role bindings, secrets, service accounts, and persistent volume claims.
You can export all namespaced objects in your project using the following command:
$ for object in $(oc api-resources --namespaced=true -o name) do oc get -o yaml --export $object > $object.yaml done
Note that some resources cannot be exported, and a MethodNotAllowed
error is displayed.
Some exported objects can rely on specific metadata or references to unique IDs in the project. This is a limitation on the usability of the recreated objects.
When using imagestreams
, the image
parameter of a deploymentconfig
can
point to a specific sha
checksum of an image in the internal registry that
would not exist in a restored environment. For instance, running the sample
"ruby-ex" as oc new-app
centos/ruby-22-centos7~https://github.com/sclorg/ruby-ex.git
creates an
imagestream
ruby-ex
using the internal registry to host the image:
$ oc get dc ruby-ex -o jsonpath="{.spec.template.spec.containers[].image}" 10.111.255.221:5000/myproject/ruby-ex@sha256:880c720b23c8d15a53b01db52f7abdcbb2280e03f686a5c8edfef1a2a7b21cee
If importing the deploymentconfig
as it is exported with oc get --export
it fails
if the image does not exist.
You can restore application data by using the oc rsync
command,
assuming rsync
is installed within the container image. The Red Hat rhel7
base image contains rsync
. Therefore, all images that are based on rhel7
contain it as well. See
Troubleshooting and Debugging CLI Operations - rsync.
This is a generic restoration of application data and does not take into account application-specific backup procedures, for example, special export and import procedures for database systems. |
Other means of restoration might exist depending on the type of the persistent volume you use, for example, Cinder, NFS, or Gluster.
Verify the backup:
$ ls -la /tmp/jenkins-backup/ total 8 drwxrwxr-x. 3 user user 20 Sep 6 11:14 . drwxrwxrwt. 17 root root 4096 Sep 6 11:16 .. drwxrwsrwx. 12 user user 4096 Sep 6 11:14 jenkins
Use the oc rsync
tool to copy the data into the running pod:
$ oc rsync /tmp/jenkins-backup/jenkins jenkins-1-37nux:/var/lib
Depending on the application, you may be required to restart the application. |
Optionally, restart the application with new data:
$ oc delete pod jenkins-1-37nux
Alternatively, you can scale down the deployment to 0, and then up again:
$ oc scale --replicas=0 dc/jenkins $ oc scale --replicas=1 dc/jenkins
To restore a project, create the new project, then restore any exported files
by running oc create -f <file_name>
.
Create the project:
$ oc new-project <project_name> (1)
1 | This <project_name> value must match the name of the project that was backed up. |
Import the project objects:
$ oc create -f project.yaml
Import any other resources that you exported when backing up the project, such as role bindings, secrets, service accounts, and persistent volume claims:
$ oc create -f <object>.yaml
Some resources might fail to import if they require another object to exist. If this occurs, review the error message to identify which resources must be imported first.
Some resources, such as pods and default service accounts, can fail to be created. |