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

[Karsten Hilbert]

On Wed, Jan 14, 2015 at 12:28:33PM +0000, Jim Busser wrote:

> And therefore when I (rightly or wrongly) concluded that I was going to have 
> to restore from my 393 Mb backup, I dropped v19 from the database.
> 
> So, borked or not, that's gone.

:-)  OK. So that's a fact. Which is good in its own right.

> Doing
>       sudo su postgres
> and changing to a directory for which postgres has permissions
>       cd /Library/PostgreSQL/9.3/bin
> and checking the status of the server using pg_ctl
>       /Library/PostgreSQL/9.3/bin/pg_ctl -D '/Library/PostgreSQL/9.3/data' 
> status
> returns
>       pg_ctl: server is running (PID: 76)
> and issuing with the password for postgres
>       psql -l
> results in
>                                   List of databases
>     Name    |  Owner   | Encoding |  Collation  |    Ctype    |   Access 
> privileges   
> ------------+----------+----------+-------------+-------------+-----------------------
>  gnumed_v18 | gm-dbo   | UTF8     | en_CA       | en_CA       | 
>  postgres   | postgres | UTF8     | en_CA.UTF-8 | en_CA.UTF-8 | 
>  template0  | postgres | UTF8     | en_CA.UTF-8 | en_CA.UTF-8 | =c/postgres
>                                                               : 
> postgres=CTc/postgres
>  template1  | postgres | UTF8     | en_CA.UTF-8 | en_CA.UTF-8 | =c/postgres
>                                                               : 
> postgres=CTc/postgres
> (4 rows)

Good, this agrees with your assertion above.

> and when I issue just
>       psql
> and am connected to the database 'postgres' I am warned
>       psql (8.4.9, server 9.3.1)
>       WARNING: psql version 8.4, server version 9.3.
>       Some psql features might not work.
>       Type "help" for help.
>       postgres=#
> and then (perhaps not surprisingly, having dropped v19), your suggested
>       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');
> gives
>       ERROR: template database "gnumed_v19" does not exist

Correct.

> I do have multiple backups of the two sizes of backups and think that part of 
> the size difference
> 
>       383 Mb
>       85 Mb
> 
> the first (383 Mb) being a .tar that expands to two files, a database.sql 
> (383.3 Mb) and a roles.sql (530 bytes):
> 
>       
> backup-gnumed_v19-GNUmed_Team-dhcp-128-189-241-105.ubcsecure.wireless.ubc.ca-2015-01-12-09-59-25-database.sql
>       
> backup-gnumed_v19-GNUmed_Team-dhcp-128-189-241-105.ubcsecure.wireless.ubc.ca-2015-01-12-09-59-25-roles.sql
>       
> and the second (85 Mb) being sql.bz2 which expands to 383.1 Mb:
> 
>       backup-upgrade-v19-to-v20-MacBook-2.local.sql

Aha !  So they may, after all, both contain the same data,
except the one is compressed (.bz2) and the other is not
(.tar). The other difference would be that one had been
created by the backup script (and thusly contains database +
roles) while the other had been created by the upgrade script.

That's good.

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