backup.old

Started by Steve Pribylover 10 years ago10 messagesgeneral
Jump to latest
#1Steve Pribyl
Steve.Pribyl@akunacapital.com

Good Evening,

What do I need to do to recover a database server that has a backup.old file in the data_directory. I have see references to a database being stopped during a backup and/or a second backup running and moving the old file aside, but it was not clear to me what needs to be done do recover.

postgresql-9.3 9.3.0-2.pgdg12.4+1

TIA
Steve

________________________________
[http://www.akunacapital.com/images/akuna.png]
Steve Pribyl | Senior Systems Engineer
Akuna Capital LLC
36 S Wabash, Suite 310 Chicago IL 60603 USA | www.akunacapital.com <http://www.akunacapital.com&gt;
p: +1 312 994 4646 | m: | f: +1 312 750 1667 | Steve.Pribyl@akunacapital.com

Please consider the environment, before printing this email.

This electronic message contains information from Akuna Capital LLC that may be confidential, legally privileged or otherwise protected from disclosure. This information is intended for the use of the addressee only and is not offered as investment advice to be relied upon for personal or professional use. Additionally, all electronic messages are recorded and stored in compliance pursuant to applicable SEC rules. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, printing or any other use of, or any action in reliance on, the contents of this electronic message is strictly prohibited. If you have received this communication in error, please notify us by telephone at (312)994-4640 and destroy the original message.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

#2John R Pierce
pierce@hogranch.com
In reply to: Steve Pribyl (#1)
Re: backup.old

On 10/6/2015 8:28 PM, Steve Pribyl wrote:

What do I need to do to recover a database server that has a backup.old file in the data_directory. I have see references to a database being stopped during a backup and/or a second backup running and moving the old file aside, but it was not clear to me what needs to be done do recover.

postgresql-9.3 9.3.0-2.pgdg12.4+1

what method or software were you using to perform this backup?

--
john r pierce, recycling bits in santa cruz

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

#3Steve Pribyl
Steve.Pribyl@akunacapital.com
In reply to: John R Pierce (#2)
Re: backup.old

Honestly I don't know. It was either pg_dump or a recovery script, that would have included a call to pg_start_backup. It does have the start_backup looking format.

START WAL LOCATION: F3/1000028 (file 00000045000000F300000001)
CHECKPOINT LOCATION: F3/1000060
BACKUP METHOD: pg_start_backup
BACKUP FROM: master
START TIME: 2015-05-30 01:39:24 CDT
LABEL: base-backup

Steve Pribyl
Sr. Systems Engineer
steve.pribyl@akunacapital.com
Desk: 312-994-4646

________________________________________
From: pgsql-general-owner@postgresql.org <pgsql-general-owner@postgresql.org> on behalf of John R Pierce <pierce@hogranch.com>
Sent: Tuesday, October 6, 2015 10:43 PM
To: pgsql-general@postgresql.org
Subject: Re: [GENERAL] backup.old

On 10/6/2015 8:28 PM, Steve Pribyl wrote:

What do I need to do to recover a database server that has a backup.old file in the data_directory. I have see references to a database being stopped during a backup and/or a second backup running and moving the old file aside, but it was not clear to me what needs to be done do recover.

postgresql-9.3 9.3.0-2.pgdg12.4+1

what method or software were you using to perform this backup?

--
john r pierce, recycling bits in santa cruz

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
________________________________
[http://www.akunacapital.com/images/akuna.png]
Steve Pribyl | Senior Systems Engineer
Akuna Capital LLC
36 S Wabash, Suite 310 Chicago IL 60603 USA | www.akunacapital.com <http://www.akunacapital.com&gt;
p: +1 312 994 4646 | m: | f: +1 312 750 1667 | Steve.Pribyl@akunacapital.com

Please consider the environment, before printing this email.

This electronic message contains information from Akuna Capital LLC that may be confidential, legally privileged or otherwise protected from disclosure. This information is intended for the use of the addressee only and is not offered as investment advice to be relied upon for personal or professional use. Additionally, all electronic messages are recorded and stored in compliance pursuant to applicable SEC rules. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, printing or any other use of, or any action in reliance on, the contents of this electronic message is strictly prohibited. If you have received this communication in error, please notify us by telephone at (312)994-4640 and destroy the original message.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

#4Steve Pribyl
Steve.Pribyl@akunacapital.com
In reply to: Steve Pribyl (#3)
Re: backup.old

Good Afternoon,

We are in a bit of pickle with this as I think some of the issues we may be having could possible be caused by being backup mode for months.

What can I check or do to make sure the db is not in backup mode and under what circumstances/how can I remove that backup.old file?

Thanks
Steve Pribyl

________________________________________
From: pgsql-general-owner@postgresql.org <pgsql-general-owner@postgresql.org> on behalf of Steve Pribyl <Steve.Pribyl@akunacapital.com>
Sent: Tuesday, October 6, 2015 10:47 PM
To: John R Pierce; pgsql-general@postgresql.org
Subject: Re: [GENERAL] backup.old

Honestly I don't know. It was either pg_dump or a recovery script, that would have included a call to pg_start_backup. It does have the start_backup looking format.

START WAL LOCATION: F3/1000028 (file 00000045000000F300000001)
CHECKPOINT LOCATION: F3/1000060
BACKUP METHOD: pg_start_backup
BACKUP FROM: master
START TIME: 2015-05-30 01:39:24 CDT
LABEL: base-backup

Steve Pribyl
Sr. Systems Engineer
steve.pribyl@akunacapital.com
Desk: 312-994-4646

________________________________________
From: pgsql-general-owner@postgresql.org <pgsql-general-owner@postgresql.org> on behalf of John R Pierce <pierce@hogranch.com>
Sent: Tuesday, October 6, 2015 10:43 PM
To: pgsql-general@postgresql.org
Subject: Re: [GENERAL] backup.old

On 10/6/2015 8:28 PM, Steve Pribyl wrote:

What do I need to do to recover a database server that has a backup.old file in the data_directory. I have see references to a database being stopped during a backup and/or a second backup running and moving the old file aside, but it was not clear to me what needs to be done do recover.

postgresql-9.3 9.3.0-2.pgdg12.4+1

what method or software were you using to perform this backup?

--
john r pierce, recycling bits in santa cruz

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
________________________________
[http://www.akunacapital.com/images/akuna.png]
Steve Pribyl | Senior Systems Engineer
Akuna Capital LLC
36 S Wabash, Suite 310 Chicago IL 60603 USA | www.akunacapital.com <http://www.akunacapital.com&gt;
p: +1 312 994 4646 | m: | f: +1 312 750 1667 | Steve.Pribyl@akunacapital.com

Please consider the environment, before printing this email.

This electronic message contains information from Akuna Capital LLC that may be confidential, legally privileged or otherwise protected from disclosure. This information is intended for the use of the addressee only and is not offered as investment advice to be relied upon for personal or professional use. Additionally, all electronic messages are recorded and stored in compliance pursuant to applicable SEC rules. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, printing or any other use of, or any action in reliance on, the contents of this electronic message is strictly prohibited. If you have received this communication in error, please notify us by telephone at (312)994-4640 and destroy the original message.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

#5David G. Johnston
david.g.johnston@gmail.com
In reply to: Steve Pribyl (#4)
Re: backup.old

On Wed, Oct 7, 2015 at 2:58 PM, Steve Pribyl <Steve.Pribyl@akunacapital.com>
wrote:

Good Afternoon,

We are in a bit of pickle with this as I think some of the issues we may
be having could possible be caused by being backup mode for months.

What can I check or do to make sure the db is not in backup mode and under
what circumstances/how can I remove that backup.old file?

um...


http://www.postgresql.org/docs/9.3/interactive/functions-admin.html#FUNCTIONS-ADMIN-BACKUP-TABLE

pg_is_in_backup()

David J.

#6Steve Pribyl
Steve.Pribyl@akunacapital.com
In reply to: David G. Johnston (#5)
Re: backup.old

Great, dur(rtfm), so is it save to delete the backup.old, if the db is not in backup mode.

Steve Pribyl
Sr. Systems Engineer
steve.pribyl@akunacapital.com<mailto:steve.pribyl@akunacapital.com>
Desk: 312-994-4646

________________________________
From: David G. Johnston <david.g.johnston@gmail.com>
Sent: Wednesday, October 7, 2015 2:12 PM
To: Steve Pribyl
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] backup.old

On Wed, Oct 7, 2015 at 2:58 PM, Steve Pribyl <Steve.Pribyl@akunacapital.com<mailto:Steve.Pribyl@akunacapital.com>> wrote:
Good Afternoon,

We are in a bit of pickle with this as I think some of the issues we may be having could possible be caused by being backup mode for months.

What can I check or do to make sure the db is not in backup mode and under what circumstances/how can I remove that backup.old file?

um...

http://www.postgresql.org/docs/9.3/interactive/functions-admin.html#FUNCTIONS-ADMIN-BACKUP-TABLE

pg_is_in_backup()

David J.

________________________________
[http://www.akunacapital.com/images/akuna.png]
Steve Pribyl | Senior Systems Engineer
Akuna Capital LLC
36 S Wabash, Suite 310 Chicago IL 60603 USA | www.akunacapital.com <http://www.akunacapital.com&gt;
p: +1 312 994 4646 | m: | f: +1 312 750 1667 | Steve.Pribyl@akunacapital.com

Please consider the environment, before printing this email.

This electronic message contains information from Akuna Capital LLC that may be confidential, legally privileged or otherwise protected from disclosure. This information is intended for the use of the addressee only and is not offered as investment advice to be relied upon for personal or professional use. Additionally, all electronic messages are recorded and stored in compliance pursuant to applicable SEC rules. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, printing or any other use of, or any action in reliance on, the contents of this electronic message is strictly prohibited. If you have received this communication in error, please notify us by telephone at (312)994-4640 and destroy the original message.

#7David G. Johnston
david.g.johnston@gmail.com
In reply to: Steve Pribyl (#6)
Re: backup.old

On Wed, Oct 7, 2015 at 3:16 PM, Steve Pribyl <Steve.Pribyl@akunacapital.com>
wrote:

Great, dur(rtfm), so is it save to delete the backup.old, if the db is not
in backup mode.

​I don't see anything that would cause "backup.old" to be linked to an
active backup if there was one in progress...and as far as I can tell a
successfully completed backup doesn't leave around any such file either.
So it should be safe to delete regardless of what pg_is_in_backup returns.
If that returns true then I would be concerned that something (or someone)
else is messing with the backup/data directory ​and that something likely
also introduced backup.old

David J.

#8Steve Pribyl
Steve.Pribyl@akunacapital.com
In reply to: David G. Johnston (#7)
Re: backup.old

Thank you very much. I read someplace if you run pg_start_backup twice the backup.old will be created, but there was not much beyond that and now I can't seem to find the reference.

Steve Pribyl
Sr. Systems Engineer
steve.pribyl@akunacapital.com<mailto:steve.pribyl@akunacapital.com>
Desk: 312-994-4646

________________________________
From: David G. Johnston <david.g.johnston@gmail.com>
Sent: Wednesday, October 7, 2015 2:25 PM
To: Steve Pribyl
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] backup.old

On Wed, Oct 7, 2015 at 3:16 PM, Steve Pribyl <Steve.Pribyl@akunacapital.com<mailto:Steve.Pribyl@akunacapital.com>> wrote:

Great, dur(rtfm), so is it save to delete the backup.old, if the db is not in backup mode.

I don't see anything that would cause "backup.old" to be linked to an active backup if there was one in progress...and as far as I can tell a successfully completed backup doesn't leave around any such file either. So it should be safe to delete regardless of what pg_is_in_backup returns. If that returns true then I would be concerned that something (or someone) else is messing with the backup/data directory and that something likely also introduced backup.old

David J.

________________________________
[http://www.akunacapital.com/images/akuna.png]
Steve Pribyl | Senior Systems Engineer
Akuna Capital LLC
36 S Wabash, Suite 310 Chicago IL 60603 USA | www.akunacapital.com <http://www.akunacapital.com&gt;
p: +1 312 994 4646 | m: | f: +1 312 750 1667 | Steve.Pribyl@akunacapital.com

Please consider the environment, before printing this email.

This electronic message contains information from Akuna Capital LLC that may be confidential, legally privileged or otherwise protected from disclosure. This information is intended for the use of the addressee only and is not offered as investment advice to be relied upon for personal or professional use. Additionally, all electronic messages are recorded and stored in compliance pursuant to applicable SEC rules. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, printing or any other use of, or any action in reliance on, the contents of this electronic message is strictly prohibited. If you have received this communication in error, please notify us by telephone at (312)994-4640 and destroy the original message.

#9David G. Johnston
david.g.johnston@gmail.com
In reply to: Steve Pribyl (#8)
Re: backup.old

On Wed, Oct 7, 2015 at 3:29 PM, Steve Pribyl <Steve.Pribyl@akunacapital.com>
wrote:

Thank you very much. I read someplace if you run pg_start_backup twice
the backup.old will be created, but there was not much beyond that and now
I can't seem to find the reference.

​Scanning the docs and logic tells me that attempting to do pg_start_backup
twice in a row should result in the second attempt giving an error...but I
could be misinformed.

The file pg_start_backup creates is named "backup_label" and so I'd also
expect any attempt to add an old suffix would keep the same base name...

David J.​

#10Scott Mead
scottm@openscg.com
In reply to: David G. Johnston (#9)
Re: backup.old

On Wed, Oct 7, 2015 at 15:38, David G. Johnston
<david.g.johnston@gmail.com>
wrote:
On Wed, Oct 7, 2015 at 3:29 PM, Steve Pribyl <
Steve.Pribyl@akunacapital.com [Steve.Pribyl@akunacapital.com] > wrote:
Thank you very much. I read someplace if you run pg_start_backup twice the
backup.old will be created, but there was not much beyond that and now I
can't
seem to find the reference.

backup_label gets deleted on pg_stop_backup() on the *master*.
Backup_label will still be in the *backup* itself however (or, more
succinctly,
a slave server). When you start the backup / slave, it will process
backup_label
so that it can start recovery. Once we don't need it anymore, the file is
renamed to backup_label.old. Typically, when you see a backup_label.old on
a
writable master, it was either: * a backup that was restored and put in to
service * a slave server that was promoted A pg_controldata will probably
show a timeline != 1

Scanning the docs and logic tells me that attempting to do pg_start_backup
twice
in a row should result in the second attempt giving an error...but I could
be
misinformed.
The file pg_start_backup creates is named "backup_label" and so I'd also
expect
any attempt to add an old suffix would keep the same base name...
David J.