...

At an absolute minimum, you should back up:

• Wiki Markup\[dspace-source\] if you've made any customisations
• Wiki Markup\[dspace\]/assetstoreunmigrated-wiki-markup
• \[dspace\]/configunmigrated-wiki-markup
• \[dspace\]/history and \ [dspace\]/log if you want to preserve activity records
• PostgreSQL, especially /usr/local/pgsql/data (or wherever the data dir is)

Really you could carry own down the tool and O/S stack; Java, Tomcat it's a judgement call as to how far down you go.

Storage layer backup

...

Just back up the data; i.e. the RDBMS tables and \ [dspace\]/assetstore (in the default config). You assume that you will be able to recreate a software/hardware environment that will run DSpace, and then you will just need to restore the data.

The advantage of this approach is that you only have to back up the data; as long as you can reconstruct the correct DSpace and PostgreSQL versions, it doesn't matter if the underlying hardware and OS are different. i.e. you're not so reliant on having an exact replica of the hardware and OS around to restore the backup.

...

Some notes in http://dspace.org/technology/system-docs/storage.html about backing up and restoring your Postgres database and the bitstream store.

Use import/export tools

Back up the data using the batch item exporter. In other words, you'd use the batch item exporter to export all of the contents of your DSpace to location X, and back X up.

...

• When installing the server, a partition is created for the system and another system for data. Every partition is then divided in Logical Volumes. This enables restore of only required logical volumes.
• We try to install software as much as possible in the system partition, and data on the data partition. Log files however, tend to end up in the system partition.
• DSpace and the Postgresql databases are put on the data partition.
• On the data partition there are separate logical volume for backup, downloads, etc.
• After installation of the server, a full (Ghost) image is taken.
• A daily hotbackup is made of the Postgresql database via a crontab. This can be done while Postgresql is running. We use the following parameters (pg_dumpall -o -c -v), but check documentation for the Postgresql version you are using. These daily backups are kept for a month.
• A weekly incremental backup of all partition is made to disk (and tape). For the incremental backup the Postgresql server has to be shut down, else the Postgresql database files are not included in the backup.
• During the weekly backups we leave Tomcat running and replace the DSpace homepage with a maintenance page. This is not a very good solution, because most users, crawlers and OAI-harversters do not start at the DSpace homepage. This generates many Internal Error Messages. We do not use Apache and are still looking for a good solution in Tomcat.

Other methods

Please check out: http://wiki.lib.sun.ac.za/index.php/SUNScholar/Disaster_Recovery for a method on Ubuntu servers.