Re: wrong size archive file

in a nutshell,

save the content of pg_xlog to /tmp or somwhwere safe.
restore your basebackup
empty out the pg_xlog after the restore
copy the saved pg_xlog into the cluster pg_xlog dir
configure recovery.conf to point to archived files
start and keep your fingers crossed.

Or if you can afford to lose some transactions
restore from base
remove all archive and backup files from pg_xlog
configure you recovery.conf
and start up

On Wed, Oct 23, 2013 at 1:48 PM, Denish Patel <denish(at)omniti(dot)com> wrote:

> For the reference here are the steps ...
>
> http://www.postgresql.org/docs/9.2/static/continuous-archiving.html#BACKUP-PITR-RECOVERY
>
>
> On Wed, Oct 23, 2013 at 4:44 PM, Denish Patel <denish(at)omniti(dot)com> wrote:
>
>> I don't think you need to move anything out of pg_xlog to WAL archive
>> Directory. You should remove all files from pg_xlogs directory on recovery
>> database server too (i.e Run rm pg_xlog/* )
>>
>> Please remove the 00000001000000000000004C from WAL archive directory,
>> remove all files from pg_xlogs on recovery database and try to startup
>> database ?
>>
>> On Wed, Oct 23, 2013 at 4:35 PM, Ginepro, Raymond C <GineproR(at)aetna(dot)com>wrote:
>>
>>> Quick summary of what I did and the archive file:****
>>>
>>> I shut down postgres via pg_ctl stop****
>>>
>>> I renamed the existing data directory****
>>>
>>> I created a new directory for the restore with the old name****
>>>
>>> Unzipped and untarred the base.tar.gz file****
>>>
>>> ** **
>>>
>>> In the pg_xlog, of the renamed data directory, there is the following:**
>>> **
>>>
>>> postgres(at)xpostgw2d:/postgresql/data/GRIZZ??/pg_xlog>ls -ltr****
>>>
>>> total 16432****
>>>
>>> -rw------- 1 postgres vfabric 305 Oct 9 14:56
>>> 00000001000000000000002B.000****
>>>
>>> 00020.backup****
>>>
>>> -rw------- 1 postgres vfabric 56 Oct 9 15:01 00000002.history****
>>>
>>> -rw------- 1 postgres vfabric 8192 Oct 9 15:01 xlogtemp.3402****
>>>
>>> -rw------- 1 postgres vfabric 8192 Oct 9 15:29 RECOVERYXLOG****
>>>
>>> -rw------- 1 postgres vfabric 8192 Oct 21 14:22
>>> 00000001000000000000004F****
>>>
>>> -rw------- 1 postgres vfabric 305 Oct 21 14:22
>>> 00000001000000000000004C.000****
>>>
>>> 00020.backup****
>>>
>>> -rw------- 1 postgres vfabric 16777216 Oct 21 14:30
>>> 00000001000000000000004D****
>>>
>>> -rw------- 1 postgres vfabric 8192 Oct 21 14:30
>>> 00000001000000000000004E****
>>>
>>> drwx------ 2 postgres vfabric 4096 Oct 21 14:30 archive_status****
>>>
>>> ** **
>>>
>>> I copied the 00000001000000000000004C.00000020.backup file to
>>> 00000001000000000000004C in the archive directory /postgresql/archive/GRIZZ.
>>> ****
>>>
>>> ** **
>>>
>>> The recovery.conf file has the following param:****
>>>
>>> ** **
>>>
>>> restore_command = 'cp /postgresql/archive/GRIZZ/%f "%p"'****
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> *From:* Denish Patel [mailto:denish(at)omniti(dot)com]
>>> *Sent:* Wednesday, October 23, 2013 3:30 PM
>>> *To:* Ginepro, Raymond C
>>> *Cc:* pgsql-admin(at)postgresql(dot)org
>>> *Subject:* Re: [ADMIN] wrong size archive file****
>>>
>>> ** **
>>>
>>> Thanks. Backup looks good. ****
>>>
>>> ** **
>>>
>>> How's your recovery.conf look like? Can you provide 'ls -l' on archive
>>> file "00000001000000000000004C" from your WAL directory?****
>>>
>>> ** **
>>>
>>> On Wed, Oct 23, 2013 at 3:14 PM, Ginepro, Raymond C <GineproR(at)aetna(dot)com>
>>> wrote:****
>>>
>>> I have created a script to run the pg_basebackup utility. The options
>>> it uses are:****
>>>
>>> pg_basebackup -D $BACKUP_DIR/$TIMEINFO -F t -z -Z 9 –x****
>>>
>>> where $BACKUP_DIR is set to our backup directory and $TIMEINFO is set to
>>> TIMEINFO=`date +%Y%m%d_%H%M%S`.****
>>>
>>> ****
>>>
>>> The backup looks ok when I unzip it and untar it. As it is being
>>> created, it switches to the next WAL file and the first one is way small.
>>> ****
>>>
>>> ****
>>>
>>> ****
>>>
>>> ****
>>>
>>> *From:* Denish Patel [mailto:denish(at)omniti(dot)com]
>>> *Sent:* Wednesday, October 23, 2013 3:07 PM
>>> *To:* Ginepro, Raymond C
>>> *Cc:* pgsql-admin(at)postgresql(dot)org
>>> *Subject:* Re: [ADMIN] wrong size archive file****
>>>
>>> ****
>>>
>>> Before going into recovery discussion, I would like to learn about how
>>> did you take a backup ? Have you followed "Making A Base Backup" procedure
>>> documented in
>>> http://www.postgresql.org/docs/9.2/static/continuous-archiving.html<http://www.postgresql.org/docs/9.2/static/continuous-archiving.html>?
>>> ****
>>>
>>> ****
>>>
>>> On Wed, Oct 23, 2013 at 2:56 PM, Ginepro, Raymond C <GineproR(at)aetna(dot)com>
>>> wrote:****
>>>
>>> Good afternoon,
>>>
>>> I am testing out recovery on 9.2 postgres and I am getting the following
>>> message when I try to start up the cluster:
>>>
>>>
>>>
>>> FATAL: archive file "00000001000000000000004C" has wrong size: 305
>>> instead of 16777216
>>>
>>>
>>>
>>> This archive log was active at the start of the backup and is not 16M in
>>> size in the original pg_xlog. How do I get around this? Is there a fix
>>> for this?
>>>
>>>
>>>
>>>
>>>
>>> This e-mail may contain confidential or privileged information. If
>>>
>>> you think you have received this e-mail in error, please advise the
>>>
>>> sender by reply e-mail and then delete this e-mail immediately.
>>>
>>> Thank you. Aetna
>>>
>>>
>>> --
>>> Sent via pgsql-admin mailing list (pgsql-admin(at)postgresql(dot)org)
>>> To make changes to your subscription:
>>> http://www.postgresql.org/mailpref/pgsql-admin****
>>>
>>>
>>>
>>> ****
>>>
>>> ****
>>>
>>> --
>>> Denish Patel,
>>> OmniTi Computer Consulting Inc.
>>> Database Architect,
>>> Phone: 240.646.0770 x 232 ****
>>>
>>>
>>>
>>> ****
>>>
>>> ** **
>>>
>>> -- ****
>>>
>>> Denish Patel,
>>> OmniTi Computer Consulting Inc.
>>> Database Architect,
>>> http://omniti.com/does/data-management****
>>>
>>> http://www.pateldenish.com****
>>>
>>
>>
>>
>> --
>> Denish Patel,
>> OmniTi Computer Consulting Inc.
>> Database Architect,
>> http://omniti.com/does/data-management
>> http://www.pateldenish.com
>>
>
>
>
> --
> Denish Patel,
> OmniTi Computer Consulting Inc.
> Database Architect,
> http://omniti.com/does/data-management
> http://www.pateldenish.com
>

--
Thanks,

Jorge Torralba
----------------------------

Note: This communication may contain privileged or other confidential
information. If you are not the intended recipient, please do not print,
copy, retransmit, disseminate or otherwise use the information. Please
indicate to the sender that you have received this email in error and
delete the copy you received. Thank You.