You are looking at the documentation of a prior release. To read the documentation of the latest release, please visit here.
Stash preserves permission bits of the restored files. However, it may change ownership (owner
gid) of the restored files in some cases. This tutorial will explain when and how ownership of the restored files can be changed. Then, we are going to explain how we can avoid or resolve this problem.
At first, let’s understand how backup and restore behaves in different scenario. A table with some possible backup and restore scenario is given below. We have run the containers as different user in different scenario using SecurityContext.
|Case||Original File Owner||Backup
||Restore Succeed?||Restored File Owner||Restored File Editable to Original Owner?|
|4||2000||root||✓||stash(1005)||✓ (remote backend)||1005||✗|
|5||2000||root||✓||stash(1005)||✗ (local backend)||-||-|
|6||2000||3000||✓||stash(1005)||✓ (remote backend)||1005||✗|
|7||2000||3000||✓||stash(1005)||✗ (local backend)||-||-|
If we look at the table carefully, we are going to notice the following behaviors:
sidecardoes not have any effect on backup. It just needs read permission of the target files.
rootuser then original ownership of the restored files are preserved.
non-rootuser then the ownership of the restored files is changed to restore container’s user and restored files become read-only to the original user unless it was
So, we can see when we run restore container as
non-root user, it raises some serious concerns as the restored files become read-only to the original user. Next section will discuss how we can avoid or fix this problem.
As we have seen when the ownership of the restored files gets changed, they can be unusable to the original user. We need to avoid or fix this issue.
There could be two scenarios for the restored files user.
This is likely to be the most common scenario. Generally, the same application whose data was backed up will use the restored files after a restore. In this case, if your cluster supports running containers as
root user, then it is fairly easy to avoid this issue. You just need to run the restore container as
root user which Stash does by default. However, things get little more complicated when your cluster does not support running containers as
root user. In this case, you can do followings:
chownafter the restore is completed.
For the first method, we can achieve this configuring SecurityContext under
RestoreSession object. A sample
RestoreSession objects configured SecurityContext to run as the same user as the original user (let original user is 2000) is shown below.
apiVersion: stash.appscode.com/v1beta1 kind: RestoreSession metadata: name: deployment-restore namespace: demo spec: repository: name: local-repo rules: - paths: - /source/data target: ref: apiVersion: apps/v1 kind: Deployment name: stash-demo volumeMounts: - name: source-data mountPath: /source/data runtimeSettings: container: securityContext: runAsUser: 2000 runAsGroup: 2000
If you are using local backend to store backed up data, then the original container, backup container and restore container all of them must be run as same user. By default, Stash runs backup container as
stash(1005)user. You can change this to match with the user of your original container using
The second method is necessary when the backup container was not run as the same user as the original container. This is similar to the process when the restored files user is different than the original user. In this case, you have to change the ownership of restored files using
chown after restore.
If you want to use the restore files with a different user than the original one, then you have to change the ownership after restore. You can use an
init-container in your workload that will run
chown command to change the permissions to the desired owner or you can exec into workload pod to change ownership yourself.