1AMPGSQL(8) System Administration Commands AMPGSQL(8)
2
6 ampgsql - Amanda Application to interface with PostgreSQL
7
9 Ampgsql is an Amanda Application API script. It should not be run by
10 users directly. It implements on-line backups of PostgreSQL databases
11 in conjunction with WAL archiving.
12 Note
14 Tablespaces are not currently supported.
15 Note
17 On versions of PostgreSQL earlier than 8.2, if the database is
18 quiet during a full backup, then the backup may not complete until
19 enough database activity takes place to trigger the archiving of
20 the current WAL file. Consider adjusting the PG-MAX-WAL-WAIT
21 property from its default (60s) to compensate. Note that you will
22 need to increase dtimeout on the server accordingly.
23
25 This application implements the backup strategy described in
26 http://www.postgresql.org/docs/current/static/continuous-archiving.html.
27 For a level zero (full) backup, ampgsql:
28 · execute PG_START_BACKUP()
30 · dump the data directory
32 · execute PG_STOP_BACKUP()
34 · wait for the final WAL file to be archived
36 · back up the required WAL files
38 · optionally delete WAL files that are no longer necessary
40 The two dumps are made with GNU Tar, to data_dir.tar and archive_dir,
42 respectively. They are then combined into a single tar file.
43 A level N backup creates a single tar file containing all WAL files
45 since the previous level N-1 backup.
46
48 This section lists the amanda.conf(5) properties that control ampsql's
49 functionality. See amanda-applications(7) for information on
50 application properties and how they are configured.
51 ARCHIVEDIR
53 Directory that WAL segment files are archived to, as specified by
54 the archive_command in PosgreSQL's postgresql.conf. The amanda user
55 on the client must have at least read and execute permission on
56 this directory, and preferably write. Without write permission,
57 Amanda cannot clean up expired WAL and backup files.
58 CLEANUPWAL
60 Whether or not to remove old WAL segment files during base backups.
61 Defaults to yes.
62 DB
64 Database to connect to. Defaults to "template1" (which exists by
65 default).
66 DIRECTORY
68 For restore command only, the data is recoved in that directory.
69 Must be a unix path.
70 GNUTAR-PATH
72 Path to the GNU tar executable. This option only has an effect
73 during restore. The default is set when Amanda is built by the
74 --with-gnutar configure option.
75 HOST
77 Host to connect to. If it starts with "/" it will be interepreted
78 as a directory that holds the socket file. PostgreSQL defaults to
79 /tmp.
80 MAX-WAL-WAIT
82 The maximum amount of time to wait for PG_STOP_BACKUP to archive a
83 WAL file. In versions of PostgreSQL before 8.2, PG_STOP_BACKUP does
84 not automatically archive the latest WAL file, so a quiet database
85 may wait a very long time before archiving the WAL file. Default:
86 60 seconds. Set to 0 to wait forever.
87 PASSFILE
89 Connect using the creditials in this file. Each line should have
90 the format "hostname:port:database:username:password". The
91 permissions must permit it to be read only by the user, or the file
92 will not be used. Only usable with Postgres 8.1 and up.
93 PORT
95 The TCP port to connect to, or the suffix of the socket file.
96 PostgreSQL defaults to 5432.
97 PSQL-PATH
99 Path to the psql binary. If not specified, the PATH environment
100 variable will be searched.
101 STATEDIR
103 Directory for saving state about backups already made. The default
104 is set when Amanda is built by the --with-gnutar-listdir configure
105 option.
106 TMPDIR
108 Directory to use for temporary files during the backup process. It
109 should have enough space to store a complete copy of the database.
110 The default is set when Amanda is built by the --with-tmpdir
111 configure option.
112 USER
114 User to connect as. It must be a superuser.
115
117 Client properties are deprecated. All properties should be set in the
118 dumptype.
119 This section lists the amanda-client.conf(5) properties that control
121 ampsql's functionality. If a property is prefixed with the diskname and
122 an underscore, then it will be used when that diskname is being backed
123 up. For example, if the properties PG-DATADIR and foo-PG-DATADIR are
124 set, the value of PG-DATADIR will be used when bar and baz are being
125 backed up, but foo-PG-DATADIR will be used when foo is being backed up.
126 Disknames are specified in the disklist(5).
127 PG-ARCHIVEDIR
129 Directory that WAL segment files are archived to, as specified by
131 the archive_command in PosgreSQL's postgresql.conf. The amanda
132 user on the client must have at least read and execute permission
133 on this directory, and preferably write. Without write permission,
134 Amanda cannot clean up expired WAL and backup files.
135 PG-CLEANUPWAL
137 Whether or not to remove old WAL segment files during base backups.
139 Defaults to yes.
140 PG-DATADIR
142 Cluster data directory
144 PG-DB
146 Database to connect to. Defaults to "template1" (which exists by
148 default).
149 PG-HOST
151 Host to connect to. If it starts with "/" it will be interepreted
153 as a directory that holds the socket file. PostgreSQL defaults to
154 /tmp.
155 PG-MAX-WAL-WAIT
157 The maximum amount of time to wait for PG_STOP_BACKUP to archive a
158 WAL file. In versions of PostgreSQL before 8.2, PG_STOP_BACKUP does
159 not automatically archive the latest WAL file, so a quiet database
160 may wait a very long time before archiving the WAL file. Default:
161 60 seconds. Set to 0 to wait forever.
162 PG-PASSFILE
164 Connect using the creditials in this file. Each line should have
166 the format "hostname:port:database:username:password". The
167 permissions must permit it to be read only by the user, or the file
168 will not be used. Only usable with Postgres 8.1 and up.
169 PG-PASSWORD
171 Password to use when connecting. Deprecated in favor of passfiles.
173 PG-PORT
175 The TCP port to connect to, or the suffix of the socket file.
177 PostgreSQL defaults to 5432.
178 PG-USER
180 User to connect as. It must be a superuser.
182 PSQL-PATH
184 Path to the psql binary. If not specified, the PATH environment
186 variable will be searched.
187
189 Read the postgres documentation carefully before attempting a recovery.
190 This section is only a rough guide to the process.
191 The data recovered from a postgres backup consists of a data tarball
193 and one or more archive tarballs. The data contains the state of the
194 database at the time the full backup was performed, and the archive
195 tarballs contain postgres WAL files that must be re-run to generate a
196 consistent state.
197 Ensure that the database server is shut down, and move the existing
199 data directory aside. Untar the data tarball over this directory, and
200 verify that ownership and permissions are correct. Untar all of the
201 archive tarballs into a single directory - the archive directory.
202 Create a recovery.conf in the data directory, owned by the proper user
203 and with proper permissions. Add a restore_command to it, e.g.,
204 restore_command = 'cp /path/to/archive_dir/%f "%p"'
205 Start the database server, and examine the logs to track the process of
207 the recovery. When the recovery is complete, the server will transition
208 into a running state, and will move the recovery.conf file aside so
209 that it will not attempt a recovery on the next invocation.
210
212 amanda(8), amanda.conf(5), amanda-client.conf(5), amanda-
213 applications(7)
214 The Amanda Wiki: : http://wiki.zmanda.com/
216
218 Nikolas Coukouma <atrus@zmanda.com>
219 Zmanda, Inc. (http://www.zmanda.com)
220Amanda 3.3.3 01/10/2013 AMPGSQL(8)