EPrints Technical Mailing List Archive

Message: #09111

< Previous (by date) | Next (by date) > | < Previous (in thread) | Next (in thread) > | Messages - Most Recent First | Threads - Most Recent First

Re: [EP-tech] Moving metadata and files across servers

CAUTION: This e-mail originated outside the University of Southampton.

Hi,

Thanks for the information. They are both using the same version of Eprints and I can ask the IT guy to make sure everything else is the same and up to date. I’ll send him this email and see if he has any other questions. It definitely sounds like a project that can wait until the end of the academic year.

 

Thanks,

~Elizabeth

 

Elizabeth McCormick

Systems Librarian

McConnell Library

Radford University

540-831-5635

emccormick@radford.edu

 

“My body is my temple, and the goddess demands chocolate!”

 

From: Alex Ball <ab318@bath.ac.uk>
Sent: Thursday, November 17, 2022 11:07 AM
To: McCormick, Elizabeth <emccormick@radford.edu>; eprints-tech@ecs.soton.ac.uk
Subject: Re: [EP-tech] Moving metadata and files across servers

 

NOTICE: This email originated externally. It is not from a Radford University account. Use caution responding, opening attachments, or clicking links.

Hi Elizabeth,

 

Moving EPrints from one server to another is quite a technical process. I only have experience of moving our repository to a clean install in a new VM, but what it boils down to is (A) copying over the configuration and documents in your eprints/archives/[archive_id] folder, (B) dumping out your [archive_id] database from the source machine and loading into MySQL or whatever on your target machine, (C) connecting up the [archive_id] instance to the web server on the target machine.

 

If you are moving the repository into an existing EPrints installation, you will find this a lot easier if you have the same version of EPrints running on both machines, and ideally the same MySQL and web server versions as well. If you have plugins or configuration files that rely on Perl modules beyond those required by base EPrints, make sure those modules are also installed on the target machine. The existing repository on the target machine must have a different archive ID to the one you are trying to move. 

 

You might find it easiest to do this in two stages.

  1. On the target machine, use "epadmin create" to set up a fresh, empty repository using the same archive ID as the one on your source machine. Follow the usual steps to get it working. One snag is that you'll want the server to serve it from the domain name currently used by the source machine; one way to get around this is to edit the hosts file on your own computer (so just your computer will interpret the domain name as pointing to the target machine) if you have admin privileges, otherwise set up a new alias domain name you can point at the target machine. The former is preferable if you have to get SSL certificates working. Once you have this fresh installation working, you can move on to step two.
  2. On the source machine, stop the indexer and prevent any more changes happening to the old repository (including any system-level cron jobs you might have set up). We use a maintenance mode script for continuity of service, but the brute force approach of shutting down the web server would work. Dump out the database to a file. (Bear in mind that if you are using your hosts file to direct requests to the new machine, this will also affect SSH requests using that domain name, so you may need to remove your override again while you do this.)

    On the target machine, similarly stop the indexer and close any browser tabs accessing the fresh installation. Move the freshly created eprints/archives/[archive_id] folder to a backup location. Copy over the eprints/archives/[archive_id] folder from the source machine to the target machine, then copy some key files from the backup location to the normal location (in particular [archive_id]/cfg/cfg.d/database.pl with your new database credentials in it). Copy over the database dump and use it to restore the database into the target machine's MySQL (e.g. "mysql -p -u [archive_id] [archive_id] < backup.sql"). For good measure, you can ensure everything is back in sync by running "epadmin update [archive_id]"; you'll probably need to force a full re-index too: "epadmin reindex [archive_id] eprint".
    Click around to make sure everything is working. Once you are happy it is, restart the indexer and then get the domain name to switch over from the source machine's IP address to the target machine's. Finish off by copying over any other system-level housekeeping things like cron jobs, and tidying up your temporary files.

 

I strongly recommend doing a dummy run, restoring your old EPrints to a close facsimile of the target VM, so you can verify the database backup/restore cycle has no nasty surprises, know exactly what files you will need replace with the fresh versions, and find out what system-level changes are needed on the target machine (if any). That way you can minimise the amount of time you spend in step 2 without a working repository.

 

I hope that helps, and good luck!

 

Best wishes,

Alex.

 

On Thu, 2022-11-17 at 14:11 +0000, McCormick, Elizabeth via Eprints-tech wrote:

Hello,

I was not involved with the creation of our two Eprints repositories but now I handle their basic maintenance. Someone in campus IT deals with server-side maintenance. We have two servers; one is physical and ancient while the other is a VM. The physical server houses our electronic theses/dissertations; the VM houses our syllabi. I would like to move all the metadata and document files off the physical server and over to the VM both because the server itself could fail and because it makes no sense to have two machines going. What plug-in or module or process would we use in order to do that?

 

Thank you,

~Elizabeth

 

Elizabeth McCormick

 

 

-- 
Alex Ball (he/him)
Research Data Librarian (Systems)
University of Bath, Bath BA2 7AY, UK
http://www.bath.ac.uk/library/