Safe Upgrading

You should really aim to upgrade your EPrints repository about once a year to keep on top of the new developments. Upgrading your EPrints repository can be a very daunting task. The aim of this page is to get people who are not confident about undertaking it into a position where it is safe to do so. Note upgrading is different to migrating (although some of the proceedures maybe the same).

Am I Upgrading?

Upgrading is when you intend to update eprints code base on a server to a later version. Upgrading covers moves from EPrints 3.x.y to 3.a.b if you want to move from EPrints 2.x.y to 3.a.b then you are undertaking a migration. Also if you are moving your EPrints repository from one server to another you are migrating. Upgrading is the same sub-versions of EPrints on the same server.

Preparation

If you are upgrading then there are a number of precautions you can take to ensure the process runs as smoothly as possible. It is impossible to give 100% cast iron garrentee an upgrade will succeed particularly if you have a heavily customised repository so you must make sure that you are in position to roll back should in the unlikely event that the upgrade does not go to plan.

It is worth saying at this point that if possible you can ease your fears by performing this task on a development server as a practice run. This technique if available to you is strongly advised.

To prepare you should:

Tell an adult

Talk to your system administrator about getting a full system backup made. It is advisable to do this fairly regularly anyway incase of hardware failure or fire. See [backing up]

Create a backups directory

mkdir <eprints_root>/backups

To create a directory to put backups into.

Check you have enough disk space

df

Will give you a table:

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda5              32G  1.4G   31G   5% /
/dev/sda7              32G   22G   11G  67% /opt
/dev/sda8              41G   24G   18G  59% /usr
/dev/sda6              16G  6.2G  9.9G  39% /var
/dev/sdb1             135G   24G  105G  19% /backup

You should make sure that the disk which contains your eprints directory (usually /opt or /usr) is over 50% free. The backup of the archive will take up a similar ammount of space to the archive itself so you should check you have room for it before starting.

Backup your database

cd <eprints_root>/backups

to change to your backups directory

mysqldump -u <db_user> -p <db_name> > <archive_name>.archive.backup-<year>-<month>-<day>.sql

at the prompt you will need to enter the password. If your repository is large this step can take a while. The purpose of the elabourate file name is so that at a glance you can tell what this file is. Also if you have multiple backups then ordering them alphabetically will put the backups for that archive in date order so you can find your most recent backup. Ending the file with .sql means you know it is a database backup.

If you do not no your db_user db_name or password for the above step you can find it by typing:

cat <eprints_root/archives/<archive_id>/cfg/cfg.d/database.pl

You should now have a .sql file containing your database backup in your <eprints_root>/backups directory.