One of my servers has a virus and the Postgres service in Windows is not running a backup and I'm using Odoo8 and even the Odoo Service is not running.
Is it possible to restore a database using only a OID directory which from what I know is the database file of Postgres.
I assume you mean /data/base/<oid> directory. Unfortunately it's not enough. There are some settings stored outside database oid directory as you called it.
Ex:
/data/glboal/ - cluster users' settings (passwords, roles etc)
/data/pg_xlog/ - WAL entries - possibly with transactions changes not "transfered" to database files yet.
/data/pg_tblspc/ - tablespaces
You need whole /data directory. Read more about PHYSICAL BACKUP.
Edit:
So, if whole /data is available for you, you can restore database to other server. There's one thing you should remember: destination postrges cluster must be at the same varsion ex. 9.4.1. When the first and seccond numbers match (ex 9.2.10 and 9.2.16) this should also work most of the times. Keeping that in mind, you just need to replace /data/ directory on destination server with your source /data directory (destination server must be stopped during that operation).
Related
I've followed the instructions to set up a replica server of PostgreSQL with repmgr, But I can't start the PostgreSQL service because of a permission problem.
On the stand by server, I have this on my /etc/repmgr.conf file:
node_id=2
node_name=aws-replica
conninfo='host=<REDACTED> user=repmgr dbname=repmgr port=5432'
data_directory='/mnt/data/postgres/data'
log_file='/var/log/repmgr.log'
As you can see, I've changed the location of the data directory to /mnt/data/postgres/data and also updated the postgresql.conf file with the same information.
When I try to start the PostgreSQL service, I get this error on journalctl:
FATAL: data directory "/mnt/data/postgres/data" has wrong ownership
HINT: The server must be started by the user that owns the data directory.
The folder in question is owned by a normal user, the same one that runs repmgr. If I set the ownership of the folder to postgres:postgres, then repmgr can't perform any operations because it can't access the folder. I tried joining the postgres group, but the service won't start unless the folder has 700 permissions, so it's pointless to join the group.
So, I'm either not being able to start postgresql or repmgr. What can I do to make it work?
The problem was that I created a postgres DB using innitdb, which wasn't necessary. I deleted the database and then ran repmgr as the postgres user, and it worked.
I have a backup of /data/db that contains all .wt files along with journal directory etc. I have stopped the db, replaced the current db directory with the one backed up and started the db. This works, Mongo starts up but when I "show databases" there are no results. The local machine (that was backed up) did not have authentication enabled. The machine I am using to attempt the restore does have it enabled, I am able to start the mongo client without any authentication.
Is there another step to this process?
Is the authentication difference an issue?
We have a disk on which a Postgres server used to be running, with one important database.
We need to move (and import) one of the databases that were live on that disk, to a live server.
Is that even possible?
I seem to only find scenarios where the server(s) are running when migrating data.
You need to use pg_dump and pg_restore because there is no way in PostgreSQL to copy database files for one single database between 2 instances.
However there is the possibility to copy the old PGDATA to a new PGDATA on new machine
(see How to copy a Postgres database from a mounted disk to a live Postgres server). But you need to have the corresponding PostgreSQL binaries to be able to move the database with pg_dump from old instance to new instance with pg_restore.
I have a postgre database DATA1 in table space location D:\tbl_DATA1. We use OS backup restore tool copy the the D:\tbl_DATA1 to a target machine C:\tbl_DATA1. Is it possible for recreate the database from this folder in the second mahcine?
https://www.postgresql.org/docs/current/static/backup-file.html
An alternative backup strategy is to directly copy the files that
PostgreSQL uses to store the data in the database
and later two restrictions mentionned
The database server must be shut down in order to get a usable backup.
You should resotore the whole PGDATA direcotory, not the certain individual tables or databases from their respective files or directories.
So yes - it is a common practice to shutdown the PostgreSQL, copy PGDATA directory to other machine and start Postgres in order to get the cluser copy. But it is done cluster level - not tablespace as you mention or database - the whole data_directory should be copied.
So no - copying the tablespace directory and trying to hack the db to add a tablespace will fail.
I am currently moving some data around and I am running into an interesting issue.
I have a CentOS server (6.3) up and running with Postgres 9.2 on a server with limited built in disk space; however, I do have a large amount of extremely reliable external network disk space available.
I have set the tablespace to a directory on this storage devise for my database and everything seems to be working well, until...
I realized that I have a large amount of BLOB data that needs to be stored in pg_largeobject.
I have been goggling how to set the tablespace of pg_largeobject and I did find some results, but they are horribly out dated.
I did find one article that looks promising, but I'm hesitant because the thread also references that things will/should have changed.
I have two questions...
In an ideal world, I would like to move all of postgres (including pg_largeobject) onto this external storage for ease of maintenance. Is this possible?
If not, how can I get pg_largeobject to use my network storage?
As you alluded to, your best bet is to move the entirety of PostgreSQL onto the remote storage, assuming that storage uses a reliable file network block device like iSCSI, ATAoE or NBD. I wouldn't recommend running Pg on NFS, and running it on CIFS/SMBFS just won't work.
Just:
Make a backup
Take a note of the output of SHOW data_directory; in psql
Shut PostgreSQL down
Move the data directory (the folder containing pg_xlog, pg_clog, etc) to the remote storage
Adjust the permissions on the parent directories for the datadir's new location to make sure the postgres user, postgres, group or others permissions block has at least execute on each parent directory so it can traverse the tree.
Adjust your system startup scripts to set the new location as the PostgreSQL datadir or symlink the old datadir location (output by SHOW data_directory) to the new location.
Start PostgreSQL
Unfortunately, different systems and packages find the datadir different ways. Debian/Ubuntu use pg_wrapper, for example.