[Archivesspace_Users_Group] Test server / production server ArchivesSpace question.

[Chelsea Lobdell]

Just chiming in and backing up what Steve is saying. If you are just
sync'ing the live DB with the test DB there's no need to run a backup. You
really only need to have backups when you are upgrading to a new version of
the software.

I would also start with a fresh index. For this I would stop the
application, ingest the live DB dump into the test DB, drop the current
index to force a complete re-index by using the following command:

rm -rf /path/to/archivesspace/data/*

And then restart the application. A re-index can take some time depending
on how large your DB is. Ours typically runs 1-2 hours.

- Chelsea

*---------------*
*Chelsea Lobdell*
*Library Web Developer/ Swarthmore College*
*clobdel1 at swarthmore.edu <clobdel1 at swarthmore.edu> / (610)690-6818*

On Tue, May 1, 2018 at 11:10 AM, Majewski, Steven Dennis (sdm7g) <
sdm7g at virginia.edu> wrote:

>
> The mysqldump is sufficient to restore ArchivesSpace state.
> It will rebuild the solr indexes. That will take a bit longer, but I
> prefer to do a complete clean reindex when cloning production to test. (
> There are a number of glitches where the first bit of advice is usually to
> trigger a reindex. )
>
> The only other state information that isn’t in the mysql database is the
> log info for batch jobs, which is in the data/shared/job_files directories.
> If you’re going to want to access output from old batch processes, you need
> to copy those.
> Typically, I retain those files when updating ArchivesSpace on production,
> but I don’t copy them when cloning production to test.
>
> — Steve Majewski
>
>
>
> On May 1, 2018, at 10:39 AM, Neal, Rick <rneal at richmond.edu> wrote:
>
> Good morning,
>
> I am having some ArchivesSpace issues and need some advice.
>
> I have a test instance and a production instance of ArchiveSpace.
>
> I use version 1.5.1 on both servers.  I use mysql.
>
> I want to update the test server from the production server.
>
> A.      I dumped the database with mysqld on the production server.
>
> B.      I then ran backup.sh on the production server (thinking that I
> need the index) and got the OUTPUT below at the bottom.  I did *not *get
> a zip file created.  I have no idea what happened but I am concerned now
> that the backup.sh file did something besides simply failing to create a
> zip file for me to take over to the test sever.  I am concerned that if I
> restart the service ArchiveSpace will fail.
>
> C.      I took the database dump and ingested it on the test server.   I
> stopped and restarted the archivesspace service.  ArchivesSpace doesn’t
> show up in the browser.  I recovered from a VM backup and have no problems
> with the test server but of course it did not get updated.
>
> Questions:
> 1.       How concerned should I be about item B above?  I took the
> database dump so I have that but I don’t know anything about whether the
> index is damaged or how to fix it if it is.  Again I am concerned that
> ArchivesSpace will not come back up if I restart the service.
> 2.       What is the proper process for updating a test instance?
>
> Thanks for your help
>
> Rick Neal
> University of Richmond
>
>
>
> OUTPUT
>
> [root at server scripts]# ./backup.sh --output /dir/backup-20180501.zip
> Loading ArchivesSpace configuration file from path:
> /dir1/archivesspace/config/config.rb
> Loading ArchivesSpace configuration file from path:
> /dir1/archivesspace/config/config.rb
> 2018-05-01 10:00:46 -0400: Writing backup to /dir/backup-20180501.zip
> INFO: Previous snapshot status: {"startTime"=>"Tue May 01 10:00:00 EDT
> 2018", "fileCount"=>42, "status"=>"success", "snapshotCompletedAt"=>"Tue
> May 01 10:00:00 EDT 2018", "snapshotName"=>nil}; snapshot:
> IOError: No such file or directory
>               create at /dir1/archivesspace/gems/gems/
> jruby-jars-1.7.21/lib/jruby-stdlib-1.7.21.jar!/META-INF/
> jruby.home/lib/ruby/shared/tmpdir.rb:0
>         initialize19 at org/jruby/ext/tempfile/Tempfile.java:95
>                  new at org/jruby/RubyIO.java:853
>         get_tempfile at /dir1/archivesspace/gems/gems/
> rubyzip-1.0.0/lib/zip/file.rb:410
>   on_success_replace at /dir1/archivesspace/gems/gems/
> rubyzip-1.0.0/lib/zip/file.rb:401
>               commit at /dir1/archivesspace/gems/gems/
> rubyzip-1.0.0/lib/zip/file.rb:294
>                close at /dir1/archivesspace/gems/gems/
> rubyzip-1.0.0/lib/zip/file.rb:322
>                 open at /dir1/archivesspace/gems/gems/
> rubyzip-1.0.0/lib/zip/file.rb:100
>           __ensure__ at ../launcher/backup/lib/backup.rb:115
>               backup at ../launcher/backup/lib/backup.rb:111
>                 main at ../launcher/backup/lib/backup.rb:150
>               (root) at ../launcher/backup/lib/backup.rb:154
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>
>
> _______________________________________________
> Archivesspace_Users_Group mailing list
> Archivesspace_Users_Group at lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20180501/7cc86902/attachment.html>