Difference between revisions of "Restoring files with Duply"
(Notes about clock drift) |
m (Bot: Cosmetic changes) |
||
| Line 1: | Line 1: | ||
| − | = Background = | + | = Background = |
We use Duply (http://duply.net) for backing up our important data to Amazon S3. Currently, backups are scheduled to run once a night, taking incrementals daily and full backups monthly. We don't turn over data that much, so retention is currently indefinite (this will have to be revisited in the future). | We use Duply (http://duply.net) for backing up our important data to Amazon S3. Currently, backups are scheduled to run once a night, taking incrementals daily and full backups monthly. We don't turn over data that much, so retention is currently indefinite (this will have to be revisited in the future). | ||
| − | = Restoring = | + | = Restoring = |
Presuming you've got a clean system, you can start restoring by doing this: | Presuming you've got a clean system, you can start restoring by doing this: | ||
* Install Duply (for CentOS this will be adding the EPEL repo, and then yum -y install duply) | * Install Duply (for CentOS this will be adding the EPEL repo, and then yum -y install duply) | ||
| − | * Log onto our S3 store (officers have the credentials), and navigate to the duply_metadata directory. These are copies of our backup config files/scripts as they existed on the system. | + | * Log onto our S3 store (officers have the credentials), and navigate to the duply_metadata directory. These are copies of our backup config files/scripts as they existed on the system. |
* Copy all of the directories in there into /etc/duply on the new system you're restoring to. | * Copy all of the directories in there into /etc/duply on the new system you're restoring to. | ||
| − | * Make a directory named /restore/ | + | * Make a directory named /restore/ |
* Run "duply <targetname> restore /restore/" | * Run "duply <targetname> restore /restore/" | ||
Duply has some other options to restore from specific points in time, these are left as an exercise for the reader. | Duply has some other options to restore from specific points in time, these are left as an exercise for the reader. | ||
| − | = Troubleshooting = | + | = Troubleshooting = |
Duply crashes inexplicably, or silently fails, if the S3 credentials are incorrect. If you're getting a CollectionError exception, or the restore finds no information, check that your credentials on the TARGET line are up to date. Create a new credential set if you're in doubt, and verify that you can connect using another client (like Cyberduck). | Duply crashes inexplicably, or silently fails, if the S3 credentials are incorrect. If you're getting a CollectionError exception, or the restore finds no information, check that your credentials on the TARGET line are up to date. Create a new credential set if you're in doubt, and verify that you can connect using another client (like Cyberduck). | ||
The VPS's clock likes to drift occasionally for larger swings than ntpd can deal with - if you're getting strange TLS issues when talking to S3 (or things just seem to not work), check that the clock is correct. | The VPS's clock likes to drift occasionally for larger swings than ntpd can deal with - if you're getting strange TLS issues when talking to S3 (or things just seem to not work), check that the clock is correct. | ||
| − | [[Category: System Administration]] [[Category: Disaster Recovery]] | + | [[Category:System Administration]] |
| + | [[Category:Disaster Recovery]] | ||
Latest revision as of 22:24, 27 February 2017
Background
We use Duply (http://duply.net) for backing up our important data to Amazon S3. Currently, backups are scheduled to run once a night, taking incrementals daily and full backups monthly. We don't turn over data that much, so retention is currently indefinite (this will have to be revisited in the future).
Restoring
Presuming you've got a clean system, you can start restoring by doing this:
- Install Duply (for CentOS this will be adding the EPEL repo, and then yum -y install duply)
- Log onto our S3 store (officers have the credentials), and navigate to the duply_metadata directory. These are copies of our backup config files/scripts as they existed on the system.
- Copy all of the directories in there into /etc/duply on the new system you're restoring to.
- Make a directory named /restore/
- Run "duply <targetname> restore /restore/"
Duply has some other options to restore from specific points in time, these are left as an exercise for the reader.
Troubleshooting
Duply crashes inexplicably, or silently fails, if the S3 credentials are incorrect. If you're getting a CollectionError exception, or the restore finds no information, check that your credentials on the TARGET line are up to date. Create a new credential set if you're in doubt, and verify that you can connect using another client (like Cyberduck).
The VPS's clock likes to drift occasionally for larger swings than ntpd can deal with - if you're getting strange TLS issues when talking to S3 (or things just seem to not work), check that the clock is correct.
