system/Backup-and-Restore.md

+## Introduction
+
+Backing up and restoring ReSeeD is, essentially, a matter of copying the Docker  volumes to a different location, and restoring them as needed.
+
+The following data volumes are used by ReSeeD:
+
+1. rdms_app
+2. rdms_cache
+3. rdms_db
+4. rdms_db-fcrepo
+5. rdms_derivatives
+6. rdms_fcrepo
+7. rdms_file_uploads
+8. rdms_redis
+9. rdms_solr
+
+It is important to note that ReSeeD (Hyrax) typically writes data to more than one volume in a given operation. This means that the volumes should be copied/restored as a **complete set**. Also, for the same reason, it is not advisable to copy the volumes while ReSeeD is writing to those volumes.
+
+
+
+## General process
+
+There are two options for ensuring that ReSeeD is not writing to the volumes at a particular moment in time:
+
+**Option 1: Stop the containers**
+
+This option will obviously disrupt the service. However, since RUB intends to re-boot the Docker host system on a regular basis, this may actually be a viable approach:
+
+1. Stop all containers
+2. Backup all volumes
+3. Reboot Docker host
+4. Start all containers
+
+
+**Option 2: Place Hyrax in "read-only" mode**
+
+This option is less disruptive to the service. The system remains available to users (and remote processes using the APIs) in a "read-only" state. This means that the data volumes can be safely copied, and that this set of copies of the volume data is internally consistent. The process would be:
+
+1. Place Hyrax into "read-only" mode. This can be done [via the Admin UI](https://rdms.rd.ruhr-uni-bochum.de/admin/features) or programmatically.
+
+2. Backup all volumes
+
+3. Place Hyrax back into "read--write" mode. This can be done [via the Admin UI](https://rdms.rd.ruhr-uni-bochum.de/admin/features) or programmatically.
+
+   
+
+Placing Hyrax into read-only mode programatically:
+
+```ruby
+Flipflop::FeatureSet.current.replace do
+	Flipflop.configure do
+    	feature :read_only, default: true
+    end
+end
+puts "Read only mode: #{Flipflop.read_only?}"
+```
+
+
+
+## Copying Docker volumes for backup
+
+The supported way to backup/restore Docker volumes is to run a Docker container for this purpose. Note that "run" in this sense has a specific meaning: running a container means that it is started, executed and then stopped in one operation. This approach is used for operations which do not require interaction beyond the parameters passed at "runtime".
+
+
+
+***(The following is copied verbatim from the [Docker documentation](https://docs.docker.com/storage/volumes/#backup-restore-or-migrate-data-volumes))***
+
+### Back up a volume
+
+For example, create a new container named `dbstore`:
+
+```bash
+ docker run -v /dbdata --name dbstore ubuntu /bin/bash
+```
+
+In the next command:
+
+* Launch a new container and mount the volume from the `dbstore` container
+* Mount a local host directory as `/backup`
+* Pass a command that tars the contents of the `dbdata` volume to a `backup.tar` file inside our `/backup` directory.
+
+```bash
+ docker run --rm --volumes-from dbstore -v $(pwd):/backup ubuntu tar cvf /backup/backup.tar /dbdata
+```
+
+When the command completes and the container stops, it creates a backup of the `dbdata` volume.
+
+
+
+### Restore volume from a backup
+
+With the backup just created, you can restore it to the same container, or to another container that you created elsewhere.
+
+For example, create a new container named `dbstore2`:
+
+```bash
+ docker run -v /dbdata --name dbstore2 ubuntu /bin/bash
+```
+
+Then, un-tar the backup file in the new container’s data volume:
+
+```bash
+ docker run --rm --volumes-from dbstore2 -v $(pwd):/backup ubuntu bash -c "cd /dbdata && tar xvf /backup/backup.tar --strip 1"
+```
+
+You can use the techniques above to automate backup, migration, and restore testing using your preferred tools.