StorReduce is designed to easily recover data to a new StorReduce server instance if an existing instance becomes unavailable. All information required to recover to a new StorReduce server is stored in back-end object storage, so data will never be lost due to a StorReduce server going down.
Only one StorReduce server can write to any given back-end storage bucket at once. If you wish to recover to a new StorReduce server and continue writing data from that new server, see Recovering to a New Write-Enabled StorReduce Instance. Alternatively you can access your data setting up a read-only StorReduce instance, leaving your original server able to write further data in the future; see Recovering Data Using a Read-Only StorReduce Instance.
Note: Recovery to a new server is much faster if there is a recent snapshot of the StorReduce index available.
For this reason we recommend enabling scheduled daily snapshots for your StorReduce server. This can be done by
logging in to the StorReduce dashboard, clicking on the Maintenance tab and clicking on the
button in the Snapshot section.
Recovering to a New Write-Enabled StorReduce Instance
In order to recover to a new server and continue writing data, ownership of the data in a cloud storage bucket must be transferred from the old StorReduce server to a new server. This will allow the new server to write and modify data in the cloud storage bucket. If the old server subsequently comes back up it will no longer be able to write to the bucket, but can still be reconfigured to run in read-only mode.
(Optional) If the old StorReduce server is still running it is recommended to take a snapshot of the local index information. This will speed up the rebuilding of the index in the new server.
To do this, log in to the StorReduce dashboard on your existing instance, click on the Maintenance tab, then click on the
Wait until the snapshot is completed. When this happens the Snapshot area will show the state has returned to ‘Stopped’ and the ‘Last Complete’ field will show when the snapshot finished.
Create your new StorReduce server as described in the Quick Start Guide, up to the point where you are ready to configure the new server. You can perform this step while the snapshot is running, but do not enter the S3 bucket name into the Settings screen yet.
Stop your old StorReduce server instance if it was still running.
In the S3 Management Console, go to your S3 bucket and manually delete the object called “StorReduce-Owner-Stamp”. This object identifies the StorReduce server that owns the data in the bucket. After you have done this, the next server to access the bucket will take ownership of the data. Be careful not to delete any other object from the bucket or you may delete some or all of your data.
Finish configuring your new server with the bucket name and hostname as described in the Quick Start Guide, then save your settings and restart.
The new server may take a short time to start up while it restores the index from the snapshot and replays any further changes made since the snapshot.
Once the new server is started, log in and click on the ‘Browse Data’ tab to confirm that all data is present.
If you have any issue please contact StorReduce via email firstname.lastname@example.org or chat.
Recovering Data Using a Read-Only StorReduce Instance
Data that has been deduplicated using StorReduce can be recovered by configuring a StorReduce server in read-only mode. This will work regardless of ths status of the server originally used to store the data.
Create your new StorReduce server as described in the Quick Start Guide, except see Step (2) below.
On the ‘Settings’ Screen of the StorReduce dsahboard, in the ‘Server’ section, select “Read-Only Mode” from the drop-down list under “Deduplication Server”.
After clicking “Save Settings and Restart Server” the server will come up in read-only mode and provide read-only access to your data. The new server may take a short time to start up while it restores the index from the snapshot and replays any further changes made since the snapshot.