EC2 - Як правильно створити резервну копію даних PostgreSQL?

Ось налаштування: 1 невеликий екземпляр Amazon Linux (підтримуваний EBS) EC2 з 3 додатковими томами. Це і веб-сервер, і сервер баз даних. Один том для коду, один для каталогу даних PostgreSQL (8.4) та один том для зберігання файлів WAL з PostgreSQL.

(1) Об'єм файлів WAL також матиме базове резервне копіювання каталогу даних, яке копіюється після виконання pg_start_backup (). Тоді він буде зберігати безперервний архівний вихід з PostgreSQL (файлів WAL). Щоб зробити знімок цього тома, чи є сенс видавати синхронізацію та заморожувати файлову систему (використовуючи xfs_freeze, якщо це XFS або dmsetup, якщо це EXT4)? Або я можу просто зробити знімок у прямому ефірі? Файли WAL доставлятимуться зі швидкістю один на хвилину. Чи можливо, що знімок може бути ініційований під час копіювання одного файлу WAL, що призведе до пошкодження даних?

(2) Об'єм, який містить прямий каталог даних PostgreSQL, також буде резервно копіюватися для гарного виміру (щодня). Перш ніж зробити знімок цього тома, я видаю pg_dump і отриманий файл SQL зберігається в каталозі даних. Чи є якийсь сенс вживати заходів безпеки, щоб забезпечити відповідність фактичних даних бази даних? Чи правильно вважати, що зйомка в прямому ефірі буде належним чином: (а) резервне копіювання файлів конфігурації (postgresql.conf, pg_hba.conf, pg_ident.conf) та (b) резервне копіювання файлу дамп-файлу SQL. Резервне копіювання цих двох речей, sql-дамп-файлів та конфігураційних файлів, було б головним моментом знімка цього тома. БД не дуже великий, тому я не заперечую проти факту, що файли даних роздують цей знімок. І в такому випадку я можу просто зробити прямий знімок - правильно?

(2a) Чи було б краще просто зберегти каталог даних у кореневому томі та мати резервний скрипт, який копіює файл дамп-файлу sql, а також конфігурує файли на інший том та знімає цей обсяг після того, як буде зроблена копія?

(3) Що стосується тома з кодом на ньому, чи знову є сенс синхронізації та заморожування файлової системи? Або просто можна зробити знімок у прямому ефірі? Ці дані повинні бути досить "статичними".

(4) Це суцільна схема резервного копіювання? Кореневий об'єм не створюється резервного копіювання на регулярній основі, оскільки я просто зберігатиму зображення машини після його налаштування та налаштування.

Дякую

Дивіться точний посібник . Якщо моя порада будь-яким чином суперечить її ", це правильно.

1. Синхронізація не є поганою ідеєю, якщо ваш інструмент копіювання fsync () не містить кожен WAL-файл, який він пише, і каталог, в якому він знаходиться, перш ніж копіювати наступний. Неповний останній файл WAL не має великого значення; в гіршому випадку ви просто видалите його. Pg, як правило, задихається від неповної WAL - хоча контрольної суми не робиться, так що ви могли бпо-справжньому не пощастило, і спробуйте застосувати дані про сміття, щоб, по справжньому шаленому випадку, схоже на справжні записи WAL. На вашому положенні я б синхронізував гучність перед знімком, щоб переконатися, що будь-які неписані брудні буфери в оперативній пам’яті потрапили на файл файлової системи на диску. Замороження допоможе уникнути брудних, але не фатальних частково записаних WAL, тому це не страшна ідея, але не життєво важлива. Важливим є наявність непошкодженої хронології до моменту відновлення. Особисто я записую свої WAL-файли до тимчасового імені файлу і перейменую їх на остаточне ім'я лише один раз повністю скопійованого; якщо ви це зробите, вам не потрібно заморожувати.

2. Звучить правильно. Знімок у прямому ефірі - це так само, як робити тест на витяг підключення в реальній системі з кешуванням запису. Ваша база даних повинна відновити штрафи при відновленні з прямого знімка, як і після витягування модуля. Я рекомендую вам автоматизувати тести реставрацій із знімків. (Примітка. Тест на відновлення знімка не є повною заміною тестування витягування штекера, оскільки він не враховує можливі кешування диска, рейдового контролера тощо). Не тільки конфігураційні файли та дамп, але й база даних самозбереження має бути добре після вашого знімка. Розгляньте можливість синхронізації гучності перед знімком, щоб переконатися, що всі дані дамп тощо дійсно потрапили на диск.
   
   2а. Ви можете заощадити трохи місця на диску. Незначна різниця інакше. Ви зможете зберігати знімки набагато довше, не маючи на цьому всієї живої бази даних.

3. Навіщо навіть знімати обсяг коду? Звичайна копія файлу може бути чудовою. Безумовно, має бути живий знімок.

4. Це не є надійною схемою резервного копіювання. Він не вдається в одній критичній області: тестування відновлення та перевірка не проводиться. Ви завжди повинні регулярно перевіряти свої резервні копії, щоб переконатися, що ви дійсно можете їх відновити.

   Особисто я рекомендую використовувати WAL-доставку або відправляти скидання баз даних на інший хост , бажано, не на Amazon EC2 або принаймні в іншому регіоні. Цей хост повинен виконувати тести автоматизованого відновлення, надсилати вам звіти про результати, а також перевіряти їх вручну.

   Незважаючи на те, що ваші знімки (містять звалища) будуть знаходитись на S3 і там будуть безпечні, це не означає, що вони будуть доступні, коли вам потрібно терміново. Заявки на довговічність Amazon викликають заспокоєння, але ваші дані все ще можуть бути безпечними та абсолютно недоступними для вас під час погано приуроченого відключення послуги S3.