Re: Recommended way to copy database files on Windows OS (to performfile system level backup) - Mailing list pgsql-general

From Christoph Moench-Tegeder
Subject Re: Recommended way to copy database files on Windows OS (to performfile system level backup)
Date
Msg-id 20180514141427.xikwj3npoucy5a76@squirrel.exwg.net
Whole thread Raw
In response to Recommended way to copy database files on Windows OS (to perform filesystem level backup)  (Yashwanth Govinda Setty <ygovindasetty@commvault.com>)
List pgsql-general
## Yashwanth Govinda Setty (ygovindasetty@commvault.com):

> We are facing this problem while performing file system level backup of database files:
> As each database will form a directory inside Base directory which consists of files representing the tables, when
sometables are dropped during backup, We get error while copying since the files do not exist anymore.
 

This looks like you read only the first sentence of the relevant
documentation:
https://www.postgresql.org/docs/current/static/backup-file.html

The "recommended way" is not "use tar", but to heed both restrictions
mentioned there. Especially, if you want to do a naive copy of the files,
the database has to be shut down.
If shutting down the database is not an option (most cases), your
option is a "base backup" - there's pg_basebackup to help you with
that, and you can do that "the hard way" with the low level API.
Both approaches are described here:
https://www.postgresql.org/docs/current/static/continuous-archiving.html#BACKUP-BASE-BACKUP

This is mostly independent from the OS - but you have to make sure to
follow the process (shutting down the database beforehand, or do the
full base backup) - else the database will be corrupted after restore
and may even fail to start.

Regards,
Christoph

-- 
Spare Space.


pgsql-general by date:

Previous
From: Allan Kamau
Date:
Subject: Re: Recommended way to copy database files on Windows OS (to performfile system level backup)
Next
From: Jonathan Marks
Date:
Subject: Rapid disk usage spikes when updating large tables with GIN indexes