Re: [Archivesspace_Users_Group] Test server / production server ArchivesSpace question.

2018-05-01 Thread 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*
*clobd...@swarthmore.edu  / (610)690-6818*

On Tue, May 1, 2018 at 11:10 AM, Majewski, Steven Dennis (sdm7g) <
sd...@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  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@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@lyralists.lyrasis.org
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
>
>
>
> ___
>

Re: [Archivesspace_Users_Group] Test server / production server ArchivesSpace question.

2018-05-01 Thread Majewski, Steven Dennis (sdm7g) 

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  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@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@lyralists.lyrasis.org 
> 
> http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group 
> 


smime.p7s
Description: S/MIME cryptographic signature
___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

[Archivesspace_Users_Group] Test server / production server ArchivesSpace question.

2018-05-01 Thread Neal, Rick 
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@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@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group