Recuperar datos borrados

Hola Buenas tardes, mi duda es la siguiente:
Necesito recuperar unos datos borrados por accidente; segui un hilo del
mailing list donde indican un procedimiento para recuperar el archivo
fisico.
el hilo es el
siguiente:http://archives.postgresql.org/pgsql-admin/2005-01/msg00176.php
Bien ya tengo el archivo fisico, pero mi problema es como interpretar
las fechas o mas bien el timestamp de dicho archivo, ya busco
información sobre el almacenacimiento físico,
pero no encuentro la documentación donde explique algo sobre eso.
A continuación Inserto una pequeña parte del archivo.

00067edch: 03 45 0C 00 02 00 00 00 F8 45 0C 00 00 00 00 00 ;
.E......øE......
00067eech: 00 00 33 00 01 00 0F 00 12 05 20 00 28 0A 7C 00 ; ..3.......
.(.|.
00067efch: D2 06 00 00 0A 00 00 00 6A 74 31 30 36 39 00 00 ;
Ò.......jt1069..
00067f0ch: 12 00 00 00 48 45 52 4E 41 4E 20 41 4E 54 4F 4E ; ....HERNAN
ANTON
00067f1ch: 49 4F 00 00 09 00 00 00 50 45 52 45 5A 00 00 00 ;
IO......PEREZ...
00067f2ch: 0A 00 00 00 4D 4F 52 45 4E 4F 00 00 17 00 00 00 ;
....MORENO......
00067f3ch: 53 45 43 52 45 54 41 52 2D 41 20 44 45 20 53 41 ; SECRETAR-A
DE SA
00067f4ch: 4C 55 44 00 45 00 00 00 36 41 20 53 55 52 20 4F ; LUD.E...6A
SUR O
00067f5ch: 54 45 20 31 32 20 2C 20 42 41 52 52 49 4F 20 45 ; TE 12 ,
BARRIO E
00067f6ch: 53 51 55 49 50 55 4C 41 53 20 56 49 4C 4C 41 46 ; SQUIPULAS
VILLAF
00067f7ch: 4C 4F 52 45 53 20 56 49 4C 4C 41 46 4C 4F 52 45 ; LORES
VILLAFLORE
00067f8ch: 53 20 43 48 49 41 50 41 53 00 00 00 04 00 00 00 ; S
CHIAPAS.......
00067f9ch: 04 00 00 00 39 00 00 00 54 45 2E 20 30 31 39 36 ; ....9...TE.
0196
00067fach: 35 36 35 32 32 37 38 39 2C 20 53 4F 4C 49 43 49 ; 56522789,
SOLICI
00067fbch: 54 4F 20 49 4E 46 4F 52 4D 41 43 49 4F 4E 20 44 ; TO
INFORMACION D
00067fcch: 45 20 53 55 53 20 42 4F 4C 45 54 4F 53 00 00 00 ; E SUS
BOLETOS...
00067fdch: 06 00 00 00 32 1E 9D F7 1B 4D AC 41 14 00 00 00 ;
....2.÷.M¬A....
00067fech: 0E 00 00 00 50 45 4D 48 36 35 31 31 32 35 00 00 ;
....PEMH651125..
00067ffch: FF FF FF FF ; ÿÿÿÿ
Esta es la estructura de la Tabl
Column | Type | Modifiers
--------------+-----------------------------+----------------------------------------------------------------
idllamada | integer | not null default
nextval('public.llamada_idllamada_seq'::text)
numeropoliza | character varying(20) |
nombre | character varying(30) |
paterno | character varying(30) |
materno | character varying(30) |
lugartrabajo | character varying(300) |
direccion | character varying(300) |
telefono | character varying(30) |
email | character varying(60) |
descripcion | text |
id_user | integer |
fecha | timestamp without time
idagencia | integer |
rfc | character varying(20) |
idquienllama | integer |

Cualquier ayuda u orientación por mínima que sea de ante manos muchas
gracias

On 19/07/07, Alejandro Roberto Morales Arce <alejandro(dot)morales(at)interalia(dot)net> >
> Cualquier ayuda u orientación por mínima que sea de ante manos muchas
> gracias
>

Antes que nada no realizes VACUUM por ningun motivo. Veo que
lograste encontrar la pagina que _hacia_ referencia a tus datos, gran
hazaña!

Ahora, los datos que te muestra estan en hexadecimal por lo que
pudieras probar a abrirlo con un editor hexadecimal para ver si logra
transformar de formato de manera que los puedas ver. Prueba y nos
cuentas.

Sin embargo, mas facil y mas rapido es que tomes tus respaldos que
hiciste como un buen DBA y ocupes psql o pg_restore para dejar todo en
orden nuevamente.

>

--
http://www.advogato.org/person/mgonzalez/

Alejandro Roberto Morales Arce escribió:
> Hola Buenas tardes, mi duda es la siguiente:
> Necesito recuperar unos datos borrados por accidente; segui un hilo del
> mailing list donde indican un procedimiento para recuperar el archivo
> fisico.
> el hilo es el
> siguiente:http://archives.postgresql.org/pgsql-admin/2005-01/msg00176.php
> Bien ya tengo el archivo fisico, pero mi problema es como interpretar
> las fechas o mas bien el timestamp de dicho archivo, ya busco
> información sobre el almacenacimiento físico,
> pero no encuentro la documentación donde explique algo sobre eso.

Busca pg_filedump (http://sources.redhat.com/ creo), con eso puedes
desplegar las tuplas en la tabla. Con eso puedes averiguar el XID de la
transaccion que los borró (xmax); luego vas a pg_clog y marcas esa
transacción "abortada". Claro que ahora que lo pienso, también tendrás
que cambiar los datos y resetear el hint bit "Xmax committed", tupla por
tupla.

(Una alternativa a esto ultimo seria usar una version parchada de
Postgres que ignore los hint bits; con esa examinas la tabla, le haces
vacuum, y luego vuelves a la version sin parchar).

Como dijo Mario, asegurate que no le haces vacuum a esa tabla, o estas
frito. (Hint: desactiva autovacuum tambien, de haberlo).

Es harto trabajo en todo caso. Suerte!

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Bueno Tomando como base que me iria por esta alternativa me surgen las
siguientes dudas:
El servidor con el hack para que no tome en cuenta los hint bits debe
ser exactamente la misma versión ?
los contenidos de PGDATA los tomo tal cual esten o hay que realizar un
paso previó ?
Y por ultimo para trabajar con esta forma alternativa,
previamente debo haber hecho la edición en pg_clog y el seteo del hint bit?
De antemano muchas gracias por la respuesta
>
> (Una alternativa a esto ultimo seria usar una version parchada de
> Postgres que ignore los hint bits; con esa examinas la tabla, le haces
> vacuum, y luego vuelves a la version sin parchar).
>
> Como dijo Mario, asegurate que no le haces vacuum a esa tabla, o estas
> frito. (Hint: desactiva autovacuum tambien, de haberlo).
>
> Es harto trabajo en todo caso. Suerte!
>
>

no hagas top-posting.

On 7/19/07, Alejandro Roberto Morales Arce
<alejandro(dot)morales(at)interalia(dot)net> wrote:
> >
> > (Una alternativa a esto ultimo seria usar una version parchada de
> > Postgres que ignore los hint bits; con esa examinas la tabla, le haces
> > vacuum, y luego vuelves a la version sin parchar).
> >
> > Como dijo Mario, asegurate que no le haces vacuum a esa tabla, o estas
> > frito. (Hint: desactiva autovacuum tambien, de haberlo).
> >
> > Es harto trabajo en todo caso. Suerte!
> >
> >
> Bueno Tomando como base que me iria por esta alternativa me surgen las
> siguientes dudas:
> El servidor con el hack para que no tome en cuenta los hint bits debe
> ser exactamente la misma versión ?

si.

> los contenidos de PGDATA los tomo tal cual esten o hay que realizar un
> paso previó ?

sacarle una copia a todo el directorio PGDATA

> Y por ultimo para trabajar con esta forma alternativa,
> previamente debo haber hecho la edición en pg_clog y el seteo del hint bit?

segun entendi, la idea de trabajar con una version parchada de
postgres era que no tuvieras que setear los "hint bits" tupla por
tupla. en cuanto al pg_clog ese lo modificas en cuanto identifiques el
XID de la transaccion que borro esos registros usando pg_filedump...

--
Atentamente,
Jaime Casanova

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning."
Richard Cook