Re: [Gnumed-devel] Restoring a database under Debian

[Karsten Hilbert]

On Sat, Jan 24, 2015 at 01:01:07AM +0000, Jim Busser wrote:

> I had begun with my 'source' (untarred) directory containing my patched dump 
> and my roles:
> 
>       
> backup-gnumed_v20-GNUmed_Team-MacBook-2.local-2015-01-21-21-05-31-database.sql
>       
> backup-gnumed_v20-GNUmed_Team-MacBook-2.local-2015-01-21-21-05-31-roles.sql
> 
> and re-tarred it from the directory one above, so as to avoid including some 
> or all of the upstream path.
> 
> On Mac OS, tarring with -W (verify) is unsupported, hence
> 
>       tar -cf 
> backup-gnumed_v20-GNUmed_Team-MacBook-2.local-2015-01-21-21-05-31.tar 
> backup-gnumed_v20-GNUmed_Team-MacBook-2.local-2015-01-21-21-05-31

This would assume you've that the *.sql files sitting in a
directory named

        "backup-gnumed_v20-GNUmed_Team-MacBook-2.local-2015-01-21-21-05-31"

branching off from your current dirctory. Also your command
will create a tar containing the SQL files INSIDE that
subdirectory. When untarring the subdirectory will be
untarred as well and the SQL files will end up inside _that_.

The GNUmed database scripts do not include any subdirectories.

> However when I tried to restore from this inside Debian VM, the following 
> problems ...
> 
> - the roles file that I was presented to edit was empty, and

Because it lived one level deeper.

> - the script failed, claiming the database.sql file did not exist

Because it lived one level deeper.

> despite that following the failure I could (as root) both see them and verify 
> that roles.sql is NOT empty.
> 
> Mind you, I did run into one strange pair of things on my
> first attempt to restore from the tar which I had created
> under Mac OS. Namely, (1) the unarchived files ended up being
> owned by some weird non-existent user and group 503
> (non-existent as queried with getenv passwd)

The tar stores the original owner in numeric form. When
untarred, the numeric owner is set but is not verified to
exist as a symbolic mapping. This is POSIX behaviour.


> and (2) an unexpected extra file was observed in the
> untarred directory, having a name of the form which began
> 'dot underscore' (._backup…database.sql) despite being absent
> (even with ls -al) in the source directory. I did not try to
> reproduce this.

That sort of name is typical for temporary files.

> =====================================================================
> Terminal output, followed by my checking of permissions:
>       
> 
> ==> Trying to restore a GNUmed backup ...
>     file: 
> /media/sf_Shared/backup-gnumed_v20-GNUmed_Team-MacBook-2.local-2015-01-21-21-05-31.tar
> 
> ==> Reading configuration ...
> 
> ==> Setting up workspace ...
>     dir: /tmp/gnumed/gm-restore_2015-01-23_13-31-40/
> 
> ==> Creating copy of backup file ...
> `/media/sf_Shared/backup-gnumed_v20-GNUmed_Team-MacBook-2.local-2015-01-21-21-05-31.tar'
>  -> 
> `/tmp/gnumed/gm-restore_2015-01-23_13-31-40/backup-gnumed_v20-GNUmed_Team-MacBook-2.local-2015-01-21-21-05-31.tar'
> 
> ==> Unpacking backup file ...
>  => Extracting (from tarball) ...
> drwx------ djb/djb           0 2015-01-22 16:34 
> backup-gnumed_v20-GNUmed_Team-MacBook-2.local-2015-01-21-21-05-31/
> -rw-r--r-- djb/djb         171 2015-01-23 12:59 
> backup-gnumed_v20-GNUmed_Team-MacBook-2.local-2015-01-21-21-05-31/._backup-gnumed_v20-GNUmed_Team-MacBook-2.local-2015-01-21-21-05-31-database.sql
> -rw-r--r-- djb/djb   383681340 2015-01-23 12:59 
> backup-gnumed_v20-GNUmed_Team-MacBook-2.local-2015-01-21-21-05-31/backup-gnumed_v20-GNUmed_Team-MacBook-2.local-2015-01-21-21-05-31-database.sql
> -rw-r--r-- djb/djb       10249 2015-01-21 21:05 
> backup-gnumed_v20-GNUmed_Team-MacBook-2.local-2015-01-21-21-05-31/backup-gnumed_v20-GNUmed_Team-MacBook-2.local-2015-01-21-21-05-31-roles.sql

See ?  It is creating another level of subdirectory which the
rest of the script is not written to deal with.

Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346