servidor - ¿Cómo restaurar el archivo de volcado de PostgreSQL en las bases de datos de Postgres?
pg_restore example (7)
Tengo un archivo de volcado con una extensión .SQL (de hecho, es un archivo SQL de texto plano). Quiero restaurarlo en mis bases de datos creadas. Estoy usando pgAdmin III , y cuando uso su "Asistente de restauración" no resalta el botón "Restaurar". En cambio, está esperando una extensión de archivo .backup .
Intenté usar los comandos de shell para restaurar el volcado, pero aún así no funcionó.
Soy un novato en esto. Si alguien pudiera ayudarme, estaría obligado.
Editar
Utilicé el siguiente comando en el Panel SQL Shell de PostGres mientras estaba sentado en el nuevoTestDB.
newTestDB-# /i E:/db-rbl-restore-20120511_Dump-20120514.sql
Todavía dio el mismo error ("Permiso denegado").
Después de elevar los permisos, solo me muestra las tablas predeterminadas de PostgreSQL:
List of tablespaces
Name | Owner | Location
-----------+----------+----------
pg_default | postgres |
pg_global | postgres |
(2 rows)
No sé qué hacer para importar / restaurar la base de datos desde un archivo SQL.
Al usar el comando pg_restore puedes restaurar la base de datos postgres
Primer tipo de terminal abierto
sudo su postgres
Crear nueva base de datos
createdb [nombre de la base de datos] -O [propietario]
createdb test_db [-O openerp]
pg_restore -d [Nombre de la base de datos] [ruta del archivo de volcado]
pg_restore -d test_db /home/sagar/Download/sample_dbump
Espere a que se complete la restauración de la base de datos.
Recuerde que el archivo de volcado debe tener lectura, escritura, acceso de ejecución, entonces para eso puede aplicar el comando chmod
Combinando el consejo de MartinP y el usuario664833, también pude hacerlo funcionar. Advertencia es ingresar psql desde la herramienta GUI pgAdmin eligiendo Complementos ... Consola PSQL establece las credenciales y el nivel de permisos para la sesión psql, por lo que debe tener permisos Admin o CRUD en la tabla y tal vez también Admin en la BD (no estoy seguro de eso). El comando entonces en la consola psql tomaría esta forma:
postgres=# /i driveletter:/folder_path/backupfilename.backup
donde postgres = # es el indicador psql, no parte del comando.
El archivo .backup incluirá los comandos utilizados para crear la tabla, por lo que también puede obtener comandos como "ALTER TABLE ..." en el archivo que se ejecuta pero se informa como errores. Supongo que siempre puede eliminar estos comandos antes de ejecutar la restauración, pero probablemente sea mejor que lamentarlos para mantenerlos allí, ya que no es probable que la restauración de datos falle. Pero siempre verifique para asegurarse de que los datos que desea resore lleguen realmente allí. (Perdón si esto parece ser un consejo condescendiente para cualquiera, pero es un descuido que le puede pasar a cualquiera, sin importar cuánto tiempo hayan estado en esto; un momento de distracción de un colega, una llamada telefónica, etc., y es fácil Olvidé este paso. Lo hice yo mismo usando otras bases de datos al principio de mi carrera y me pregunté "Caramba, ¿por qué no estoy viendo datos de esta consulta?". La respuesta fue que los datos nunca se restauraron realmente, y solo perdí 2 horas intentando para buscar presuntos posibles errores que no existían).
El problema con su intento en la línea de comando psql es la dirección de las barras inclinadas:
newTestDB-# /i E:/db-rbl-restore-20120511_Dump-20120514.sql # incorrect
newTestDB-# /i E:/db-rbl-restore-20120511_Dump-20120514.sql # correct
Para que quede claro, los comandos psql comienzan con una barra psql invertida, por lo que deberías haber puesto /i lugar. Lo que sucedió como resultado de su error tipográfico es que psql ignoró todo hasta encontrar el primero / , que pasó seguido de db , y /db resulta ser el comando psql para enumerar los espacios de tablas , por lo que el resultado fue una lista de espacios de tabla . No era una lista de "tablas predeterminadas de PostgreSQL" como dijiste.
Además, parece que psql espera que el argumento de psql filepath delimite directorios usando la barra inclinada sin importar el sistema operativo (por lo tanto, en Windows esto sería contrario a la intuición).
Vale la pena señalar que su intento de "elevar permisos" no tuvo relación con el resultado del comando que intentó ejecutar. Además, no dijiste qué causó el supuesto error "Permiso denegado".
Finalmente, la extensión en el archivo de volcado no importa, de hecho ni siquiera necesita una extensión. De hecho, pgAdmin sugiere una extensión .backup cuando se selecciona un nombre de archivo de copia de seguridad, pero en realidad puede hacer lo que quiera, incluso sin tener ninguna extensión. El problema es que pgAdmin parece permitir solo una "Restauración" de volcados "Personalizados o tar" o "Directorio" (al menos este es el caso en la versión MAC OS X de la aplicación), así que solo use el comando psql /i como se muestra arriba.
Encuentro que psql.exe es bastante quisquilloso con la dirección de barra oblicua, al menos en Windows (que se ve más arriba).
Aquí hay un ejemplo. En una ventana de cmd:
C:/Program Files/PostgreSQL/9.2/bin>psql.exe -U postgres
psql (9.2.4)
Type "help" for help.
postgres=# /i c:/temp/try1.sql
c:: Permission denied
postgres=# /i c:/temp/try1.sql
CREATE TABLE
postgres=#
Puede ver que falla cuando utilizo barras diagonales "normales" en una llamada. Sin embargo, ambos estilos de barra funcionan si los pasa como parámetros de entrada a psql.exe , por ejemplo:
C:/Program Files/PostgreSQL/9.2/bin>psql.exe -U postgres -f c:/TEMP/try1.sql
CREATE TABLE
C:/Program Files/PostgreSQL/9.2/bin>psql.exe -U postgres -f c:/TEMP/try1.sql
CREATE TABLE
C:/Program Files/PostgreSQL/9.2/bin>
Es posible que necesite establecer permisos en el nivel de la base de datos que le permita al propietario de su esquema restaurar el volcado.
No mencionó cómo se realizó la copia de seguridad, por lo que la respuesta genérica es: generalmente con la herramienta psql .
Dependiendo de lo que pg_dump recibió instrucciones de volcar, el archivo SQL puede tener diferentes conjuntos de comandos SQL. Por ejemplo, si le ordena a pg_dump que pg_dump una base de datos usando --clean y --schema-only , no puede esperar restaurar la base de datos desde ese volcado ya que no habrá comandos SQL para COPYing (o INSERTing if --inserts se usa) los datos reales en las tablas. Un volcado como ese contendrá solo comandos DDL SQL, y podrá recrear el esquema pero no los datos reales.
Un volcado de SQL típico se restaura con psql :
psql (connection options here) database < yourbackup.sql
o alternativamente desde una sesión psql ,
psql (connection options here) database
database=# /i /path/to/yourbackup.sql
En el caso de las copias de seguridad realizadas con pg_dump -Fc ("formato personalizado"), que no es un archivo SQL simple sino un archivo comprimido, debe usar la herramienta pg_restore .
Si estás trabajando en un Unix, prueba esto:
man psql
man pg_dump
man pg_restore
de lo contrario, eche un vistazo a los documentos html . ¡Buena suerte!
1. abre el terminal.
2. respalde su base de datos con el siguiente comando
su bin de postgres - /opt/PostgreSQL/9.1/bin/
su servidor de base de datos fuente - 192.168.1.111
la ubicación y el nombre de su archivo de respaldo - /home/dinesh/db/mydb.backup
su nombre db de origen - mydatabase
/opt/PostgreSQL/9.1/bin/pg_dump --host ''192.168.1.111'' --port 5432 --username "postgres" --no-password --format custom --blobs --file "/ home / dinesh / db /mydb.backup "" mydatabase "
3. Restaure el archivo mydb.backup en el destino.
su servidor de destino - localhost
su nombre de base de datos de destino - mydatabase
crear una base de datos para restaurar la copia de seguridad.
/opt/PostgreSQL/9.1/bin/psql -h ''localhost'' -p 5432 -U postgres -c "CREATE DATABASE mydatabase"
restaurar la copia de seguridad.
/opt/PostgreSQL/9.1/bin/pg_restore --host ''localhost'' --port 5432 --username "postgres" --dbname "mydatabase" --no-password --clean "/ home / dinesh / db / mydb. apoyo"