-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathbackup-file.html
More file actions
150 lines (148 loc) · 16.6 KB
/
backup-file.html
File metadata and controls
150 lines (148 loc) · 16.6 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>25.2. ファイルシステムレベルのバックアップ</title><link rel="stylesheet" type="text/css" href="stylesheet.css" /><link rev="made" href="pgsql-docs@lists.postgresql.org" /><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /><link rel="prev" href="backup-dump.html" title="25.1. SQLによるダンプ" /><link rel="next" href="continuous-archiving.html" title="25.3. 継続的アーカイブとポイントインタイムリカバリ（PITR）" /><meta name="viewport" content="width=device-width,initial-scale=1.0" /></head><body id="docContent" class="container-fluid col-10"><div class="other_version"><a href="https://www.postgresql.jp/document/">バージョンごとのドキュメント一覧</a></div><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="4" align="center"><a accesskey="h" href="index.html">PostgreSQL 18.3文書</a></th></tr><tr><td width="10%" align="left"></td><td width="10%" align="left"></td><td width="60%" align="center"><a href="backup.html" title="第25章 バックアップとリストア">第25章 バックアップとリストア</a></td><td width="20%" align="right"><div class="actions"><a class="issue" title="github" href="https://github.com/pgsql-jp/jpug-doc/issues/new?template=bug_report.yml&what-happened=version 18.3 : backup-file.html">誤訳等の報告
</a></div></td></tr><tr><td width="10%" align="left"><a accesskey="p" href="backup-dump.html" title="25.1. SQLによるダンプ">前へ</a> </td><td width="10%" align="left"><a accesskey="u" href="backup.html" title="第25章 バックアップとリストア">上へ</a></td><td width="60%" align="center">25.2. ファイルシステムレベルのバックアップ</td><td width="20%" align="right"> <a accesskey="n" href="continuous-archiving.html" title="25.3. 継続的アーカイブとポイントインタイムリカバリ（PITR）">次へ</a></td></tr></table><hr /></div><div class="sect1" id="BACKUP-FILE"><div class="titlepage"><div><div><h2 class="title" style="clear: both">25.2. ファイルシステムレベルのバックアップ <a href="#BACKUP-FILE" class="id_link">#</a></h2></div></div></div><span class="original">
<title>File System Level Backup</title>
</span><p>
<span class="original">
An alternative backup strategy is to directly copy the files that
<productname>PostgreSQL</productname> uses to store the data in the database;
<xref linkend="creating-cluster"/> explains where these files
are located. You can use whatever method you prefer
for doing file system backups; for example:
</span>
バックアップ戦略の代替案として<span class="productname">PostgreSQL</span>がデータベース内のデータを保存するために使用しているファイルを直接コピーする方法があります。
<a class="xref" href="creating-cluster.html" title="18.2. データベースクラスタの作成">18.2</a>にこれらのファイルがどこにあるか解説されています。
下記のような通常のファイルシステムのバックアップを行うどんな方法でも問題ありません。
</p><pre class="programlisting">
tar -cf backup.tar /usr/local/pgsql/data
</pre><p>
</p><p>
<span class="original">
There are two restrictions, however, which make this method
impractical, or at least inferior to the <application>pg_dump</application>
method:
</span>
しかしこの方法には2つの制約があり、そのためにあまり実用的ではなく、少なくとも<span class="application">pg_dump</span>より劣ると言わざるを得ません。
</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>
<span class="original">
The database server <emphasis>must</emphasis> be shut down in order to
get a usable backup. Half-way measures such as disallowing all
connections will <emphasis>not</emphasis> work
(in part because <command>tar</command> and similar tools do not take
an atomic snapshot of the state of the file system,
but also because of internal buffering within the server).
Information about stopping the server can be found in
<xref linkend="server-shutdown"/>. Needless to say, you
also need to shut down the server before restoring the data.
</span>
有効なバックアップを行うにはデータベースサーバを<span class="emphasis"><em>必ず</em></span>停止しなければなりません。
全ての接続を無効とするような中途半端な対策では作用<span class="emphasis"><em>しません</em></span>
（<code class="command">tar</code>やその類似ツールはある時点におけるファイルシステムの原子的なスナップショットを取らないことと同時に、サーバ内の内部バッファリングの理由によるからです）。
サーバの停止に関しては<a class="xref" href="server-shutdown.html" title="18.5. サーバのシャットダウン">18.5</a>を参照してください。
言うまでもありませんが、データをリストアする前にもサーバを停止させる必要があります。
</p></li><li class="listitem"><p>
<span class="original">
If you have dug into the details of the file system layout of the
database, you might be tempted to try to back up or restore only certain
individual tables or databases from their respective files or
directories. This will <emphasis>not</emphasis> work because the
information contained in these files is not usable without
the commit log files,
<filename>pg_xact/*</filename>, which contain the commit status of
all transactions. A table file is only usable with this
information. Of course it is also impossible to restore only a
table and the associated <filename>pg_xact</filename> data
because that would render all other tables in the database
cluster useless. So file system backups only work for complete
backup and restoration of an entire database cluster.
</span>
データベースのファイルシステムレイアウトの詳細を熟知している場合、ある個別のテーブルやデータベースをそれぞれのファイルやディレクトリからバックアップしたり復元したりすることを試みたいと思うかもしれません。
しかし、それらのファイル内の情報はすべてのトランザクションのコミット状態を保持するコミットログファイル<code class="filename">pg_xact/*</code>なしでは使えないため、この方法では正常なバックアップは<span class="emphasis"><em>行えません</em></span>。
テーブルファイルはこの情報があって初めて意味をなします。
もちろんテーブルとそれに付帯する<code class="filename">pg_xact</code>データだけで復元することも、データベースクラスタにある他のテーブルを無効としてしまうのでできません。
ですので、ファイルシステムバックアップは、データベースクラスタ全体の完全なバックアップとリストア処理にのみ動作します。
</p></li></ol></div><p>
</p><p>
<span class="original">
An alternative file-system backup approach is to make a
<quote>consistent snapshot</quote> of the data directory, if the
file system supports that functionality (and you are willing to
trust that it is implemented correctly). The typical procedure is
to make a <quote>frozen snapshot</quote> of the volume containing the
database, then copy the whole data directory (not just parts, see
above) from the snapshot to a backup device, then release the frozen
snapshot. This will work even while the database server is running.
However, a backup created in this way saves
the database files in a state as if the database server was not
properly shut down; therefore, when you start the database server
on the backed-up data, it will think the previous server instance
crashed and will replay the WAL log. This is not a problem; just
be aware of it (and be sure to include the WAL files in your backup).
You can perform a <command>CHECKPOINT</command> before taking the
snapshot to reduce recovery time.
</span>
その他のファイルシステムバックアップ方法として、ファイルシステムが<span class="quote">「<span class="quote">整合性を維持したスナップショット</span>」</span>機能をサポートしている場合（かつ、正しく実装されていると信用する場合）、データディレクトリのスナップショットを作成する方法があります。
典型的な手順では、データベースを含むボリュームの<span class="quote">「<span class="quote">凍結スナップショット</span>」</span>を作成し、データディレクトリ全体（上述のように、一部だけではいけません）をスナップショットからバックアップデバイスにコピーし、そして、凍結スナップショットを解放します。
これはデータベースサーバが稼働中であっても動作します。
しかし、こうして作成されたバックアップは、データベースサーバが適切に停止されなかった状態のデータベースファイルを保存します。
そのため、このバックアップデータでデータベースサーバを起動する時、直前のサーバインスタンスがクラッシュしたものとみなされ、WALログが取り直されます。
これは問題ではありません。
単に注意してください（そして、確実にバックアップにWALファイルを含めてください）。
<code class="command">CHECKPOINT</code>コマンドをスナップショット取得前に発行することで復旧時間を減らすこともできます。
</p><p>
<span class="original">
If your database is spread across multiple file systems, there might not
be any way to obtain exactly-simultaneous frozen snapshots of all
the volumes. For example, if your data files and WAL log are on different
disks, or if tablespaces are on different file systems, it might
not be possible to use snapshot backup because the snapshots
<emphasis>must</emphasis> be simultaneous.
Read your file system documentation very carefully before trusting
the consistent-snapshot technique in such situations.
</span>
対象のデータベースが複数のファイルシステムにまたがって分散している場合、全てのボリュームに対して完全に同期した凍結スナップショットを得る方法が存在しない可能性があります。
例えば、データファイルとWALログが異なったディスク上にあったり、テーブル空間が異なるファイルシステム上にある場合、スナップショットは同時でなければ<span class="emphasis"><em>なりません</em></span>ので、スナップショットのバックアップを使用できない可能性があります。
こうした状況では、整合性を維持したスナップショット技術を信用する前に使用するファイルシステムの文書を熟読してください。
</p><p>
<span class="original">
If simultaneous snapshots are not possible, one option is to shut down
the database server long enough to establish all the frozen snapshots.
Another option is to perform a continuous archiving base backup (<xref
linkend="backup-base-backup"/>) because such backups are immune to file
system changes during the backup. This requires enabling continuous
archiving just during the backup process; restore is done using
continuous archive recovery (<xref linkend="backup-pitr-recovery"/>).
</span>
同時実行のスナップショットができない場合、選択肢の１つとして、全ての機能の停止したスナップショットを確定させるのに充分な時間、データベースサーバをシャットダウンさせることが挙げられます。
他の選択肢は、継続的なベースバックアップの保管（<a class="xref" href="continuous-archiving.html#BACKUP-BASE-BACKUP" title="25.3.2. ベースバックアップの作成">25.3.2</a>）を行うことです。
こうしたバックアップには、バックアップ中のファイルシステムの変更を心配する必要がないためです。
これにはバックアップ処理期間のみに継続的な保管を行う必要があり、継続的なアーカイブリカバリ（<a class="xref" href="continuous-archiving.html#BACKUP-PITR-RECOVERY" title="25.3.5. 継続的アーカイブによるバックアップを使用した復旧">25.3.5</a>）を使用してリストアを行います。
</p><p>
<span class="original">
Another option is to use <application>rsync</application> to perform a file
system backup. This is done by first running <application>rsync</application>
while the database server is running, then shutting down the database
server long enough to do an <command>rsync &#45;-checksum</command>.
(<option>&#45;-checksum</option> is necessary because <command>rsync</command> only
has file modification-time granularity of one second.) The
second <application>rsync</application> will be quicker than the first,
because it has relatively little data to transfer, and the end result
will be consistent because the server was down. This method
allows a file system backup to be performed with minimal downtime.
</span>
ファイルシステムをバックアップするその他の選択肢として<span class="application">rsync</span>の使用が挙げられます。
これを行うには、先ずデータベースサーバが稼働中に<span class="application">rsync</span>を実行し、そして<code class="command">rsync --checksum</code>を実行するのに充分な間だけデータベースサーバを停止します。
（<code class="command">rsync</code>はファイルの更新時刻に関して1秒の粒度しかありませんので、<code class="option">--checksum</code>が必要です。）
次の<span class="application">rsync</span>は、比較的転送するデータ量が少なく、サーバが稼働していないため最終結果に矛盾がない事から、最初の<span class="application">rsync</span>よりも迅速です。
この方法で最小の稼働停止時間でファイルシステムのバックアップを行う事ができます。
</p><p>
<span class="original">
Note that a file system backup will typically be larger
than an SQL dump. (<application>pg_dump</application> does not need to dump
the contents of indexes for example, just the commands to recreate
them.) However, taking a file system backup might be faster.
</span>
ファイルシステムバックアップは、概してSQLによるダンプより大きくなることに注意してください。
（<span class="application">pg_dump</span>では、例えばインデックスの内容をダンプする必要はありません。単にコマンドで再作成します。）
しかし、ファイルシステムのバックアップを取るほうがより高速でしょう。
</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="backup-dump.html" title="25.1. SQLによるダンプ">前へ</a> </td><td width="20%" align="center"><a accesskey="u" href="backup.html" title="第25章 バックアップとリストア">上へ</a></td><td width="40%" align="right"> <a accesskey="n" href="continuous-archiving.html" title="25.3. 継続的アーカイブとポイントインタイムリカバリ（PITR）">次へ</a></td></tr><tr><td width="40%" align="left" valign="top">25.1. <acronym class="acronym">SQL</acronym>によるダンプ </td><td width="20%" align="center"><a accesskey="h" href="index.html" title="PostgreSQL 18.3文書">ホーム</a></td><td width="40%" align="right" valign="top"> 25.3. 継続的アーカイブとポイントインタイムリカバリ（PITR）</td></tr></table></div></body></html>