pg_dump должен был скопировать всю базу. Кроме собственно базы есть ещё лог последних действий, но мне казалось, что он довольно быстро накатывается на саму базу.

Смотри логи на тему на что там pg_dump матерился.

Был успешно настроен постгрес версии 9.3 (от ethersoft, который патченный, официально заявленный рабочим)

Однако, 9.3 еще не вышел, а тут уже патченный.

настроены бекапы по крону с помощью /usr/bin/pg_dump с последующим сжатием.

Каким образом? Возможно оно у тебя по крону бэкапило не то и не туда.

Сегодня оказалось, что после незапланированного рестарта сервера постгрес не смог запуститься по причине существования pid-файла.

А процесса, соответствующего этому pid-файлу точно не было?

Было обнаружено, что на каталоге домашней директории пользователя postgres (под которым работает сам сабж) не было прав для этого пользователя (вот уже первый вопрос - как это так случилось?).

Возможно права сменил злоумышленник. Возможно по этому пути не примонтировался раздел, который должен был примонтироваться. Возможно посыпалась файловая система.

Когда права были восстановлены, то оказалось, что в БД документы последние (1с) аж за 8-е ноября! Восстановление последнего бекапа (вчерашнего) вообще рвет шаблон: в нем база данных с последними документами от 10-го числа!

Мне пришло в голову четыре варианта:

• ты неправильно смотрел даты последних документов;
• твой бэкап кроном на самом деле не работал, либо работал «через раз»;
• пользователи потёрли документы ручками (на этот случай посмотри журнал геристрации);
• резервная копия не смогла полностью восстановиться (смотри ошибки, которые мог выдать постгрес при восстановлении).

Что, постгрес очень долго хранит базу в памяти и в какой-то очень периодический момент кеширует только?

Зависит от настроек.

постгрес не смог запуститься

Надеюсь, в этот момент директория базы была скопирована в надежное место?

запамятовал

9.1 же

Как все было:

#!/bin/bash mplace=/mnt/smbshare date=`date «+%Y-%m-%d-%H%M%S»` dump=«/var/lib/pgsql/9.1/backups/AN8-sql-$date.gz» cd /var/lib/pgsql/9.1/backups echo «dumping...» su postgres -c «pg_dump AN8 | gzip > $dump» cat /etc/mtab | grep $mplace if [ $? ]; then echo «mount» mount -t cifs -o guest //192.168.0.95/backups $mplace fi cat /etc/mtab | grep $mplace if [ $? <> 0 ]; then echo «copy...» cp $dump $mplace echo «waiting... 5 sec.» sleep 5 echo «umount» umount $mplace echo «ok.» fi

вот так делал дампы. Реально системы работала, а сегодня после аварийного выключения пользователями Дампы восстанавливаются, но получается лажа полная... Восстановил в чистую БД - косяк. 1с-ина работает криво, ИБ нерабочая... Сейчас восстановил ИБ на 15.11.

Кроме собственно базы есть ещё лог последних действий, но мне казалось, что он довольно быстро накатывается на саму базу.

Как их накатить? Неужели восстановление дампа недостаточно?

По идее всё должно делаться автоматом. pg_dump вроде по умолчанию делает sync и тому подобные необходимые вещи. А как там на самом деле настроена я телепатически понять не могу — смотри в строну настроек Write-Ahead Log и pg_dump

Ну и да — вполне возможно, что поудаляли документы ручками. Смотри бэкап за предыдущий день.

Смотри логи. Куда логи кладутся смотри в настройках. Если логи не куда не клались, то ССЗБ.

Вполне возхможно из-за того что я разместил базу на рэйд-массиве, скопировал туда БД, и сделал линк на /var/lib/pgsql/9.1/data м.б. из-за этого?

Если всю директорию скопировал, то в чём проблема? Базу надеюсь останавливал на время копирования?

не из-за этого. «я сто раз так делал» :)

Когда переносил конечно, но это было давно...

Тогда нет проблем.

Смотри не самый последний бэкап, а предыдущий, предыдущий перед предыдущим и сравнивай изменения. Я не знаю есть ли что-то вроде diff для бэкапов postgresql дампов, но в принципе там это не сложно реализовать для просмотра текстовых «не блобных» вставок.

Вот ща посмотрел, у меня когда отрабатывает pg_dump то выбивает так: ...killing

Из-за чего это может быть?

Когда в скрипте вызывается pg_dump

Ща взглянул на postgresql.conf там fsync = on закомментирован

Логи вроде пишутся в каталоге БД ща смотрел..

а где постгрес базы хранит? В каком подкаталоге? Как точно идентфицировать все файлы, необходимые для работы конкретной базы?

Это надо смотреть структуру. Есть системные таблицы в которых всё это перечисляется. По-моему там одному файлу соответствует одна таблица или что-то вроде.

Для ускорения. Если делаешь pg_dump по идее проблем быть не должно.

Оч странно, ничего такого не помню. Правда у меня в работе старый PostgreSQL, но в работе ооооочень давно.

у тебя, случаем, не на рейде когда зеркало развалилось и щас система стартовала с другого винта?

а случаем не raid1? Один из винтов не отваливался? а то как то было в практике.. тоже было весело..

опередил =)

Из-за чего это может быть?

например, памяти не хватает и ядро прибивает. В dmesg смотрел? А может ты ulimit на процессорное время сделал...

А еще 1c ку лучше бекапить ей самой.

Так как сервер выполняет фоновые задания, и то что ты делал pg_dump все равно что lvm снапшот сделать... вроде что-то есть, но это не бекап.

Есть мнение, что ты не понимаешь, что такое pg_dump

1Cка не рекомендует бекапить ей самой. Рекомендует на уровне СУБД. - В книге по Администрированию написано так.

для этого надо юзверей выгонять.

надо юзверей выгонять.

я думаю pg_dump в пределах одной транзакции делает бэкапы. Это, в принципе, легко проверить.

Что-то наподобии: делаем sync, все прочие транзакции на запись делаем в журнал, и в это время делаем дамп базы?

ммм, я крайне мало что понимаю в базах, но мне кажется всё гораздо проще. У каждой строки (записи) в базе есть диапазон номеров транзакций (просто два числа типа uint32) при котором эта строка существует. Поэтому pg_dump дампит только те строки которые существовали на момент начала дампа. Более новые просто будут скипаться.

Удаление строки не удаляет её из базы, просто помечается номер транзакции когда она существовала. Думаю, изменение тоже работает похожим образом.

9.1 же

значит 9.1.2, т.к. на 1с только эта версия заявлена..

так вот почитайте на досуге:

http://www.postgresql.org/docs/9.1/static/release-9-1-3.html

http://www.postgresql.org/docs/9.1/static/release-9-1-4.html

http://www.postgresql.org/docs/9.1/static/release-9-1-5.html

http://www.postgresql.org/docs/9.1/static/release-9-1-6.html