Voy a probar Barman, la verdad que me sentía mas cómodo y con mas control
haciendo "a mano". Pero dada la sugerencia, no me queda otra que probar :-)
Saludos y muchas gracias a todos.
El mar., 2 jun. 2020 a las 18:31, Alvaro Herrera ()
escribió:
> Martín Marqués escribió:
> > Mas que recomendar
Martín Marqués escribió:
> Mas que recomendar usar rsync, mejor instalar barman y ahorrarse tantos
> dolores de cabeza!
Sí, yo pensé lo mismo desde hace bastantes mails en este hilo.
Escribir archive_commands y restore_commands no es fácil, aunque lo
parezca. Los ejemplos de la documentación
Mas que recomendar usar rsync, mejor instalar barman y ahorrarse tantos
dolores de cabeza!
El mar., 2 jun. 2020 a las 2:02, Carlos T. Groero Carmona (<
cton...@gmail.com>) escribió:
> Guillermo,
>
> te recomiendo usar rsync en vez the cp, por ejemplo mi archive_command
> luce asi:
>
Guillermo,
te recomiendo usar rsync en vez the cp, por ejemplo mi archive_command luce
asi:
archive_command = 'rsync -az --compress-level=1 %p postgres@external_ip
:/pgsql_data/9.6/archive/%f'
A mi me gusta archivar todos los log en un solo lugar, asi quien lo
necesite lo encontrara en el mismo
Guillermo ese cp no tiene log, si falla no te enteraras nunca, es facil de
ver , pero quería comentarlo.
saludos
jmdc
On Mon, Jun 1, 2020 at 10:29 AM Guillermo E. Villanueva <
guillermo...@gmail.com> wrote:
> Muchas gracias a todos por sus últimas respuestas.
> Me dicen que revise el log, es lo
Muchas gracias a todos por sus últimas respuestas.
Me dicen que revise el log, es lo primero que hice y se los transcribí en
este hilo.
Todo está hecho con usuario postgres y con todos los permisos para tal
usuario.
Les transcribí el comando de restauración, creo que entre todas las cosas
que
Guillermo E. Villanueva escribió:
> Aclaro que pude realizar la restauración del server, pero copiando a mano
> los wal al directori pg_xlog
¿qué hay en archive_command? Me pregunto si estarás borrando los WAL
cuando los archivas (cosa que, obviamente, no debe hacerse)
Saludos
--
Álvaro
Hola Guillermo,
El mar., 26 may. 2020 a las 12:50, Guillermo E. Villanueva (<
guillermo...@gmail.com>) escribió:
> Gracias Juan, en mi caso, la copia (para el restore_command) era en el
> mismo server, y si, tuve que copiar a mano todos los wal
>
Usaste el mismo usuario para copiar los WAL? La
Guillermo, tendrás que ver porque el restore command fallo.. en ese caso
una mirada al log, algo tuvo que pasar y pasará de nuevo
sinó corriges el problema, espacio en disco? ...
On Tue, May 26, 2020 at 12:50 PM Guillermo E. Villanueva <
guillermo...@gmail.com> wrote:
> Gracias Juan, en mi
Gracias Juan, en mi caso, la copia (para el restore_command) era en el
mismo server, y si, tuve que copiar a mano todos los wal
El mar., 26 may. 2020 a las 11:47, Juan ()
escribió:
> Guillermo,
>
> ME pasó lo mismo, porque el destino de la copia no estaba en el mismo
> servidor y parece que la
Guillermo,
ME pasó lo mismo, porque el destino de la copia no estaba en el mismo
servidor y parece que la conexion se pierde,
Alli esta el nombre del file que debes copiar, copias los files hasta que
el pitr sigue, el tiene una lista y la va siguiendo
si no esta ese wall frena, pero espera, si lo
Gracias por tu respuesta Horacio, perdón pero no entiendo bien cual es tu
sugerencia.
Saludos!
Aclaro que pude realizar la restauración del server, pero copiando a mano
los wal al directori pg_xlog
El jue., 21 may. 2020 a las 10:16, Horacio Miranda ()
escribió:
>
> On 22/05/2020 12:56 am,
On 22/05/2020 12:56 am, Guillermo E. Villanueva wrote:
Buen día, ayer me pasó lo mismo amigos, el pitr ignoró totalmente el
restore command y el log me decía que no encontraba los wal en pg_xlog.
Permisos: ok
Sintaxis del recovery: ok
*recovery.conf
*restore_command = 'cp
Buen día, ayer me pasó lo mismo amigos, el pitr ignoró totalmente el
restore command y el log me decía que no encontraba los wal en pg_xlog.
Permisos: ok
Sintaxis del recovery: ok
*recovery.conf*restore_command = 'cp /home/postgres/backups/walbackup/%f %p'
recovery_target_time = '2020-05-20
Guillermo E. Villanueva escribió:
> Alvaro y Dayme les pido disculpas, dos errores consecutivos en el pedido de
> ayuda, no tenía acceso al servidor estos días (vacaciones invernales)
> ahora si estoy frente al server postgres.
> El contenido de recovery.conf es:
> restore_command = 'cp
Alvaro y Dayme les pido disculpas, dos errores consecutivos en el pedido de
ayuda, no tenía acceso al servidor estos días (vacaciones invernales)
ahora si estoy frente al server postgres.
El contenido de recovery.conf es:
restore_command = 'cp /usr/local/pgsql/BK20190705/%f %p'
Como les comenté,
Buenas:
El mar., 9 de jul. de 2019 a la(s) 11:02, Alvaro Herrera (
alvhe...@2ndquadrant.com) escribió:
> Guillermo E. Villanueva escribió:
> > Gracias por tu respuesta Alvaro,
> > recovery.con tiene:
> > restore_command = '/usr/local/pgsql/BK20190705/%f %p'
>
No te falta el cp? o sea debería
no no perdón fue un error de tipeo en el mensaje, el nombre es correcto, se
llama recovery.conf
El mar., 9 jul. 2019 a las 13:02, Alvaro Herrera ()
escribió:
> Guillermo E. Villanueva escribió:
> > Gracias por tu respuesta Alvaro,
> > recovery.con tiene:
> > restore_command =
Guillermo E. Villanueva escribió:
> Gracias por tu respuesta Alvaro,
> recovery.con tiene:
> restore_command = '/usr/local/pgsql/BK20190705/%f %p'
>
> Les cuento que pude resolverlo de una manera no muy convincente, antes del
> start copié todos los archivos wal de respaldo al directorio pg_xlog
Gracias por tu respuesta Alvaro,
recovery.con tiene:
restore_command = '/usr/local/pgsql/BK20190705/%f %p'
Les cuento que pude resolverlo de una manera no muy convincente, antes del
start copié todos los archivos wal de respaldo al directorio pg_xlog y
arrancó bien, pero... pero... y el
Gracias por la respuesta y disculpas por no responder antes.
si existe el archivo con el tamaño correcto.
El vie., 5 jul. 2019 a las 23:10, Juan ()
escribió:
> El archivo existe, cuánto mide? Cual es la longitud seteada de wall?
>
> El vie., 5 de jul. de 2019 11:07 PM, Horacio Miranda
>
Gracias por tu respuesta, perdón por no responder antes, para descartar le
puse permisos 777 postgres:postgres.
La verdad que no se si selinux estaba habilitado, pero si funcionó en las
pruebas, creo que no sería un factor no?
El vie., 5 jul. 2019 a las 23:07, Horacio Miranda ()
escribió:
>
Guillermo E. Villanueva escribió:
> Hola, hice todos los pasos necesarios para una recuperación correcta usando
> PITR.
> Es mas, hicimos pruebas en meses atras y funcionaron bien.
> Ahora que lo necesito en serio, tengo un problema, intento levantar en modo
> de recuperación (recovery.conf) y
El archivo existe, cuánto mide? Cual es la longitud seteada de wall?
El vie., 5 de jul. de 2019 11:07 PM, Horacio Miranda
escribió:
> Revisa los permisos que tiene el archivo, revisa sí selinux esta
> habilitado.
>
>
> On 6/07/2019 10:08 AM, Guillermo E. Villanueva wrote:
> > Hola, hice todos
Revisa los permisos que tiene el archivo, revisa sí selinux esta habilitado.
On 6/07/2019 10:08 AM, Guillermo E. Villanueva wrote:
Hola, hice todos los pasos necesarios para una recuperación correcta
usando PITR.
Es mas, hicimos pruebas en meses atras y funcionaron bien.
Ahora que lo necesito
Hola, hice todos los pasos necesarios para una recuperación correcta usando
PITR.
Es mas, hicimos pruebas en meses atras y funcionaron bien.
Ahora que lo necesito en serio, tengo un problema, intento levantar en modo
de recuperación (recovery.conf) y obtengo lo siguiente:
2019-07-05 18:48:47.864
26 matches
Mail list logo
