Re: [Gnumed-bugs] Problems restoring from a backup - directory ... does not exist

[Karsten Hilbert]

On Tue, Jan 13, 2015 at 07:14:07PM +0000, Jim Busser wrote:

> ... I managed, in the course of the last two posts, to bork my v19 database …

Let's be extremely cautious here and let's gather data first.
Please don't take any steps until we agreed upon them. If you
suspect any specific step you took which you think might have
caused it please describe carefully. It might provide clues.

What indications do you see that v19 is borked ?

        - you mention reduced size
        - anything else ?

Let's first create a safe backup of what v19 is _now_:

        - become user "postgres" at the OS level
        - post output of "psql -l"
        - run "psql"
        - now you should be connected to database "postgres"
        - from inside psql run (and post output)
                CREATE DATABASE gnumed_v19borked_backup TEMPLATE gnumed_v19 
OWNER "gm-dbo";
                alter database gnumed_v19_backup set 
default_transaction_read_only TO on;
                UPDATE pg_database SET datallowconn = False WHERE datname = 
'gnumed_v19borked_backup';
                SELECT pg_database_size('gnumed_v19');
        - exit from psql with \q
        - run psql -l and post output
        - put an *extra* copy of both the 83 MB borked v19 dump AND the
          383 MB non-borked v19 dump somewhere really safe, or maybe two
          copies in different places (another machine, USB stick)

Now run (as any user with an uptodate v19 tarball)

        ./gm-fingerprint_db.py gnumed_v19 <YOUR_gm-dbo_PASSWORD>

Note that this may well fail if inside the gnumed_v19 there
doesn't really exist a GNUmed database schema. Please report
the output.

I will now look at the reminder of your mail to plot the
safest way out.

Please don't take extra steps unless you REALLY FULLY know
what that entails.

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