Backing up and Restoring Etherpad Lite Pads

Important.

This document makes the assumption you have a file system backup so the scope of this document focuses on pad data only. This document assumes you have your data stored in a MySQL database.

Backing-up Pad data.

Daily brick level.

If you are running in a production environment you should have master<->master or master->slave replication already in place. You should do daily brick level backups on your slave at a bare minimum, these should be called something like 01042012_pads.sql. To achieve this simply create a cron job that points to a .sh script that has a mysqldump command that dumps your entire database. How to use mysqldump..

Backing up an individual Pad.

Simply add /export/txt (or /export/html) at the end of the pad URL.

For instance, to backup with curl:

curl -o mypad.txt https://beta.etherpad.org/p/progress/export/txt

All of a pads data is stored as changes in the database so basically Etherpad has a copy of all of the states the document was ever in (see "Accessing a prevision revision directly" below).

Restoring Pad data

Restoring an entire pad database.

Get your brick level backup file (.sql file) and do... mysql -uUSERNAME -p DATABASENAME < SQLFILENAME.sql Replacing username, databasename and sqlfilename with the required values..

Restoring an individual Pad.

Because each pads state is stored in the database you can always access old revisions from pads. There are a few approaches to seeing the old data.

Using the timeslider to see old pad data.

To access the timeslider of a (possibly broken) pad just suffix /timeslider on the end of a Pad URL IE http://beta.etherpad.org/p/progress/timeslider

Accessing a prevision revision directly

The timeslider can show you which revision # is assigned to a point in a document. To access a revision directly simply suffix http://beta.etherpad.org/p/progress/export/html?revs=1000 where 1000 is the revision you wish to share.

Fixing a corrupt pad.

This is coming soon...