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.

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..

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).

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..

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.

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

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.

This is coming soon...