Ibcmd создать базу

pg_basebackup для файлового архива

Это основной способ резервного копирования, если у вас нет второго сервера PostgreSQL для репликации, или платных PostgresPro

pg_dump — логическое резервное копирование и восстановление

Для создания полноценной резервной копии базы данных используется утилита pg_dump, которая позволяет делать дамп одной базы. Не блокирует пользователей. Способ бэкапа — логический, с помощью команд. К недостаткам можно отнести долгое время восстановления. Н Е может использоваться как для восстановления на определенный момент времени.

Для резервных копию сразу всех баз экземпляра субд (кластера) — утилита pg_dumpall
. Кроме того, она сохраняет и данные, относящиеся к кластеру в целом.

Для восстановления резервной копии в специальном формате требуется другая утилита — pg_restore
. Она читает файл и преобразует его в обычные команды psql. После восстановления базы имеет смысл выполнить команду ANALYZE
, которая соберет статистику.

В среде Linux

Выше описанный вариант обычно демонстрируют на курсах, но он обладает многими недостатками включая время на операцию.

Вариант с бэкапом в директорию кучи файлов в данном примере делает это в 4 потока с максимальным сжатием 9

/opt/pgpro/1c-14/bin/pg_dump -Fd -U postgres -h localhost -j 4 -Z 9 -f /tmp/demo.dump demo

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

Такой вариант в один файл сожмет, но в один поток.

/opt/pgpro/1c-14/bin/pg_dump -Fd -U postgres -h localhost -Z 9 -f /tmp/demo.dump demo

Восстановление отсюда в туже базу :

/opt/pgpro/1c-14/bin/pg_restore -U postgres -h localhost -c -C -f /tmp/demo.dump

Что не так с этим способом
, хотя многие его используют.

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

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

Таким образом, такой метод применим, если у вас базе работает пара пользователей и забивает в день пару документов, и их проще руками восстановить. Для большинства такой метод логического резервного копирования не годится — объем потерянных данных неприемлем. Ну разве что вы в отсутствии пользователей сделаете дапм и перенесете на новое место, например на новый сервер. Но и тут скорее надо делать бэкап всего «кластера PG» целиком командой pg_dumpall, а при полностью идентичных средах просто каталог кластера скопировать.

Dump не содержит информации для дальнейшего воспроизведения журнала транзакций и потому не подходит для решения задачи восстановления на момент времени (Point-in-Time Recovery, PITR).

И это ещё не говоря о том что не сбрасываются на из кэша на диск данные, и вообще могут жить в кэше ОС, что не добавляет гарантий 100% работоспособности бэкапа. В очень редких случаях бэкап может оказаться не пригоден для восстановления базы из него. Т.е. в силу особенностей механизмо работы субд DUMP это не полный аналог полного бэкапа скуля!

Так почему так часто используют дампны для бэкапа — потому что просто и понятно

#Остановка службы 1С

#Выгрузка дампа Наша_база в локальную папку

pg_dump -Upostgres -w -Ft -b -EUTF8 -v -f "/Backup/dumps/Наша_база_`date '+%d.%m.%y'`.psql" "Наша_база"

#Сжатие дампа Наша_база в локальной папке

bzip2 "/Backup/dumps/Наша_база_`date '+%d.%m.%y'`.psql"

#Запуск Службы 1С

#Копирование сжатого дампа в каталог NFS сервера

cp "/Backup/dumps/Наша_база_`date '+%d.%m.%y'`.psql.bz2" "/NFS_Backup/"

# удаление дампа из локальной папки

rm -f "/Backup/dumps/Наша_база_`/bin/date '+%d.%m.%y'`.psql.bz2"

/Backup/dumps — это папка на сервере для выгрузки дампов баз.

/NFS_Backup — это каталог с примонтированным сетевым диском на NFS сервере, куда собственно и складываются ежедневные бэкапы баз.

Делаю скрипт исполняемым:

chmod +x /scripts/Backup_PostgreSQL

Добавляем правило в планировщик заданий Cron:

nano /etc/crontab —- Онлайн конфигуратор Crontab https://crontab.guru/

Добавляю в самом низу строчку:

0 22 * * 1-5 root /scripts/Backup_PostgreSQL

Это строка означит, что скрипт, будет запускаться с правами root каждый день с понедельника по пятницу в 22:00.

Процедура восстановления базы из бэкапа:

Переходим в каталог с архивом:

Получаем файл дамп базы Наша_база_21.11.22.psql

В консоли провожу смену пользователя на posgres:

Подключаюсь к нашему серверу баз данных использую учетную запись postgres:

Удаляю ту базу, бэкап которой я хочу восстановить:

DROP DATABASE «Наша_база»;

CREATE DATABASE «Наша_база»;

Отключаемся от сервера баз данных:

Выходим из под пользователя postgres:

Заливаем дамп Наша_база_17.11.22.psql в базу zup:

pg_restore -Upostgres -d «Наша_база» -w -v «Наша_база_17.11.22.psql»

Один из плюсов командной строки это легкая интегрируемость в код конфигураций 1с.

Вот например такое решение
.

В среде Windows

Есть простая графическая утилита Postgres SQLBackup 1.1.2

Утилита прекрасно подключается и к Linux серверам с PostgreSQL и делает бэкапы! Если у Вас нет отдельного физического сервера с ОС Windows или постоянного включенного комьпютера, то вы можете в линукс среде развенуть wine или виртуалку для работы программы

Ошибки при поднятии из dump-а

Если вы не тренируете восстановление, то будьте к готовы к ситуациям типа:

«Подскажите пожалуйста в чём затык: когда-то давно (и не мной) был настроен бекап баз в psql посредством скрипта -> на выходе получаю psq.bz2 файлы, которые можно развернуть только через psql (т.к. pg_restore, т.к получаю сообщение «pg_restore: error: input file appears to be a text format dump. Please use psql.»). В итоге гружу этот текстовый формат в ПУСТУЮ базу посредством psql -> получаю гору ошибок вроде: «ОШИБКА: отношение «public._acc43474» не существует» или «ОШИБКА: отношение «_enum41552» уже существует»), бекап заливается, но при попытке подключить такую базу с стороны 1C получаю ошибку со скриншота. Права owner’a на базу проверял -> там штатный «postgres». Бекап 100% рабочий. По сути, даже если я сам снимаю новый text format dump «каким-нибудь DBeaver» он заливается назад в пустую базу точно также -> ошибки «

или по забугорному RTO (recovery time objective)

это промежуток времени, в течение которого система может оставаться недоступной в случае аварии. Например, в центре обработки данных произошел пожар, но мы хотим, чтобы система была снова доступна для работы через 2 часа. Это и есть наш RTO. Мы должны планировать так, чтобы за этот промежуток восстановить работоспособность информационной системы на резервном оборудовании или площадке. Это можно реализовать с помощью различных технологий отказоустойчивости или же простым восстановлением из резервных копий на другой сервер. В любом случае мы должны обеспечить этот показатель при инциденте.

Не надо путать время восстановления и объем потерянных данных
.

На время восстановления влияет:

1. время восстановления аппаратной составляющей

Время простоя обычно снижают аппаратным резервированием (дублированием).

2. доставка к месту восстановления бэкапов

Время простоя снижают доставкой заранее бэкапа или реплику транзакции.

Также значимую роль занимает скорость сети.

3. время накатывания бэкапов

Диски с бэкапами часто бывают медленными. Для уменьшения времени считывания бэкапов используют быстрые SSD.

На время восстановления могут повлиять и другие факторы.

см. также http://www.gilev.ru/31march/

или по забугорному — RPO (recovery point objective)

это максимальный период времени, за который могут быть потеряны данные в результате инцидента. Например, у нас имеется информационная система и RPO для нее мы определили в 1 час. Это значит, что, если вдруг происходит авария, мы готовы к тому, что систему удастся восстановить, но в ней будут потеряны данные не более, чем за последний час. Количество потерянных данных может быть меньше, если нам повезет, но не более 1 часа. Этот показатель говорит нам о том, как часто мы должны делать резервные копии нашей системы, и какие технологии применять, чтобы удержать этот показатель. Может ли он быть ноль? Теоретически да, но на практике организовать это очень сложно. Это можно организовать, только, если запись идет как минимум в 2 разных хранилища. Использование AlwaysOn Availability Groups или Database Mirroring вам не поможет, т.к. эти технологии не спасут от случайного удаления таблицы.

Наиболее популярный вариант MS SQL Server — log-shipping (доставка журналов)
скажем с частотой раз в минуту (при условии что сам процесс бэкапа лога успевает быстрее и не идет накопления очереди) позволяет обеспечить RPO в одну минуту например.

см. также http://www.gilev.ru/31march/

см. также http://www.gilev.ru/rto/

Физическое резервирование или репликация или зеркалирование использует механизм восстановления после сбоев. Для этого требуются:

— копия файлов кластера (базовая резервная копия);

— набор журналов предзаписи WAL, необходимых для восстановления согласованности.

  restore headeronly from disk = ‘c:\base.bak’  

Получим информацию о хранящихся в файле .bak бэкапах с идентификаторами position, датами их создания BackupFinishDate начальным и конечным номерами LSN и всей прочей информацией.

эта статья является продолжением серии обучающих статей, предыдущая clonezilla

На текущий момент программа работает под ОС Windows

Прежде чем вы будете что-то администрировать и активно менять/настраивать, обеспечьте резервное копирование ценной информации, чтобы в случае непредвиденных сценариев Вы могли откатиться к предыдущему успешному состоянию, а также при необходимости обратиться к резервной копии большой давности.

Примечание. Более подробно вопросы резервного копирования рассматриваются в http://www.gilev.ru/pgbackup/
, но пока мы будем ориентироваться на простоту и надежность подохода.

Для упражнения нам потребуется второй физический сервер. Или можете в качестве него задействовать свой ноутбук с Windows. Если ничего такого нет, то можете в VMware в соседней виртуалке развернуть Windows, но исключительно в целях обучения в ограниченных условиях.

Выравнивание времени на астра линукс

Обычно на машинах с Windows время синхронизируется и точное, а вот на астре по дефолту могут быть проблемы.

Запустите терминал Fly и выполните последовательно три команды:

sudo apt purge -y ntp
sudo timedatectl set-ntp true
sudo systemctl start systemd-timesyncd

посе этого при наличии доступа в инет время выровняется

Подготовка дистрибутива

Установка клиентской части PostgreSQL в среде windows

При работе совместно нескольких серверов крайне желательно выровнять время!

Запустите скаченный файл PostgreSQL_1C_14.7_64bit_Setup.exe — версия как и на исследуемом сервере.

Хорошо, что установщик графический и все слишком очевидно.

Нам потребуется только клиентская часть.

Ставим и идем дальше.

Установка Handy Backup

Установка handybackup.exe выполняется интуитивно понятно. Нам потребуется серверная версия. Нам же с серверами работать, да еще и с другими 🙂

На следующем шаге выберите «Handy Backup Server Network». Тут подразумевается, что мы ставим не агента, откуда будем извлекать какие то данные, а сам сервер, которые будет следить за расписанием, выполнять резервное копирование, оповещать и т.п.

Вас могут попросить подтвердить установку от имени конкретного пользователя. Нажмите «Да».

Далее флажки могут быть любыми, завершаем установки. И запускаем саму программу.

При желании вы также можете сразу купить лицензию и активировать её, но для обучения нам это пока не нужно, пропустим этот шаг и запустим триальную версию.

Донастройка

Настройка оповещений на почту

Прежде всего настройте оповещения на ваш почтовый ящик.

В панели инструментов выберите «Настройки»

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

Создание контрольной информации для проверки

Будем вручную проверять корректность работы бэкапов.

С этой целью запустим клиентскую часть с ранее развернутой базой с тестом.

Откроем в меню операции — справочник.

Создаем одну запись с названием «запись должна попасть в полный бэкап»

Закрываем клиента 1с.

И переходим в машину с Windows.

Создание полной резервной копии PostgreSQL

Щелкаем по одноименной пиктограмме на рабочем столе.

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

В панели инструментов выбираем «Создать» (Новое задание).

При создании копии выбираем продвинутый режим.

Выбираем раздел баз данных (database) и движок Postgres

Щелкаете на субд.

В открывшемся окне созадем «новое подключение».

Важно! Обратите внимание что вы программой резервного копирования подключаетесь к субд Postgres на удаленном компьютере по стандартному порту 5432. Т.е. у вас будет не localhost, а netbios или доменное имя.

Обратите внимание, если ваш компьютер с Windows находится вне локальной сети с сервером Postgres, то вам может потребоваться на роутере пробросить порт 5432 «наружу». Если в одной локальной сети, то просто указать DNS имя сервера.

Далее программа подключиться к вашему серверу тут же и отрисует доступные к резервному копированию базы данных Postgres.

Всегда будет база данных ‘postgres’, она служебная. Однако ее тоже стоит копировать, она не большая, место много не займет, а пригодится может.

Обратите внимание, что в одном экземпляре субд не стоит держать несколько высокононагруженных или объемных баз. Для копий разработчиков или т.п. лучше поднять отдельный экземпляр, об этом вдальнейшем отдельно поговорим.

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

Нажмите Ок.

Возвращаемся к предыдущему окну.

Возможно в других сценариях, особенно не 1с-ных можно было бы покопировать отдельно конкретные таблицы, но мы ничем таким заниматься не будем, просто далее.

Переходим к важному моменту — месту размещения копий.

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

Выбираем полную копию.

Будем хранить 7м последних дней.

Понятно что максимальная глубина исторических копий будет определяться свободным местом на диске, но при существенной цене потери информации даже такой диск 30.72Tb Samsung PM1643a (MZILT30THALA-00007) будет выгодным.

Дополнительную информативность бэкапу придаст временная метка.

Важно! Убедитесь что времена на разных серверах совпадают.

Ок, далее.

Для экономии места на диске и удобства хранения — сожмем архив и запакуем все в один. Файл.

Тут конечно три базы и вы можете сказать что это может увеличить время восстановления, но все базы маленькие, а при реальных размерах конечно надо осознанно выбирать.

Мы шифровать архив не будем, так как бэкап будет храниться на локальных дисках сервера. ( А вдруг интернет пропадет). Но если вы маленькая компания и ваш исходный сервер и так в облаках, то обязательно шифруйте, если будете в облаках VK и т.п. хранить.

Зададим циклическое расписание выполнять бэкап около часа ночи, но вы помните что хранится то будут последние 7 дней, а потом старые бэкапы будут стираться автоматически.

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

В завершении убедимся что процесс работает как задумывался, запустим его.

Если на практике у вас базы будут большого размера, то вам потребуется хороший оптический канал, минимум 10 GBE sfp+, а может быть и выше.

Создание контрольной информации для проверки

Снова запускаем клиентскую часть 1с и в справочник Номенклатура добавляем вторую запись с названием «эта запись не должна попасть в полный бэкап».

Восстановление данных из полной резервной копии PostgreSQL

Запускаем снова операцию «Создать».

Но в этот раз выбираем второй вариант «Восстановить данные».

Открываем диск с бэкапами и находим каталог с нужной нам временной меткой в наименовании, выделяем файл с расширением hbi.

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

Указываем полное восстановление

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

Прощелкиваем дальше мастер до конца и готово. Поскольку стояла галочка сразу запустить, то дождемся завершения восстановления данных из бэкапа.

Теперь идем в клиента 1с и смотрим справочник Номенклатура. Если вы проделали всё верно, то у вас будет в этот момент только одна запись с наименованием «запись должна попасть в полный бэкап». Второй записи не будет.

<!—

Создание инкрементной резервной копии PostgreSQL

Минимизируем риски потери данных. Для этого вызовем создание аналогичного задания, только на этот раз будем делать не полную копию, а инкрементную и для одной конкретной базы.

Все шаги показывать не буду, только ключевые, всё по аналогии.

Ключевой момент — интервал времени
5 минут означает что максимально потерянная информация около 5 минут
если вы уменьшите интервал, то у вас будет существенно выше требования к место под бэкапы
если слишком увеличите интервал, то объем потерянной информации существенно возрастет
нужно найти компромис исходя из финансовых возмжностей и требований бизнеса

Примечание. Такой подход работает аналогично файловому архиву описанному здесь который можно настроить из командной строки под линукс.

Можете дождаться выполнения первого прохода регламентным заданием чтобы убедиться что все успешно резервируется.

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

Внесем контрольные данные для проверки.

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

Теперь удалим из справочника запись и закроем 1с.
Перейдем в handybackup и создадим новую задачу, где укажем hbi файл в каталоге с меткой времени предшествующей удалению.

—>

Плюсы и минусы

У любого технического решения есть плюсы и минусы.

Начнем с минусов:

— сеть конечно дает возможность возможность копировать базы из разных сред с нескольких серверов, но она же будет скорее всего ограничивает максимальное количество одновременно взаимодействуюх

— также сеть ограничивает максимальный размер баз — это всё относительно времени технологического окна

— привязанность к версии субд (правда в виртуалках можно нарезать несколько сред)

Теперь плюсы:

— быстрая и легкая установка

— интуитивно понятный графический интерфейс, минимум времени на освоение

— наличие техподдержки, что не повредит в организациях

— возможность копирования не только локально, но и на другие сервера и в облако

— логирование и отслеживание с оповещением о возникающих проблемах и коллизиях

— прозрачность работы

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

— не надо знать линукс и командную строку

— есть возможность внести свои сценарии в работу, например перед бэкапом баз PostgreSQL можно воспользоваться разделом «Запустить программу до выполнения задачи» с опцией «Дождаться окончания работы программы» и написать туда например сброс данных из кэша на диск «C:\Program Files\Handy Backup 8\ws64\psql.exe» -h АдресВашегоСервера -U postgres -p 5432 -c «checkpoint;»

или же через параметр -f \путьдоскрипта\скрипт.sql выполнить целый ряд команд, ну например написать в скрипт помимо коммита переключение журнала WAL на следующий файл «select pg_switch_wal();» и так далее

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

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

— отечественный производитель ПО, продукт внесен в реест отечественного ПО

На этом все, в следующей статье мы будем администровать кластер 1с
.

Программу купить можно здесь
.

Резервное копирование путем выгрузки в dt

Выгрузка базы данных 1С в dt-файл не является средством резервного копирования базы данных для программных продуктов 1С:Предприятие. Выгрузка/загрузка dt является средством конвертации из файловой в серверную и наоборот, а также средством миграции с одной субд на другую.

Это официальная точка зрения фирмы 1С ( вы, конечно, можете считать иначе), фирма 1С не гарантирует восстановление базы данных из только что благополучного выгруженного dt-файла, поскольку из битой базы ( но внешне ещё работающей) вам с высокой долей вероятности выгрузится битый dt-файл. https://its.1c.ru/db/metod8dev/content/2922/hdoc
и https://its.1c.ru/db/v8314doc#bookmark:adm:TI000000137

Тем неменее это не останавливает народ использовать инструмент в качестве резервного копирования. Доходит до смешного, иногда люди воротят сверхсложные схемы чтобы в итоге сделать dt
.

Отчасти это возможно происходит потому что «что ближе программисту по опыту и понятней», то и использует.

Кроме интерактивного режима выгрузку можно сделать и в пакетном варианте:

Файловая версия:

"C:\Program Files\1cv81\bin\1cv8.exe" config /F"C:\ bases1c\BUH\Titan" /N"Администратор" /DumpIB "C:\Buh_Titan_%date%.dt"

Серверная версия:

"C:\Program Files\1cv81\bin\1cv8.exe" config /S"Server\AtlantBuh" /N"Администратор" /DumpIB "C:\Buh_Titan_%date%.dt"

Недостатки выгрузки через Конфигуратор:

1. Мопольный доступ на время выгрузки. Надо выгоднять пользователей. Часто это приходится автоматизировать через COM
или RAC
.

2. Длительное время создания.

3. Может возникнуть ситуация, при которой файл выгрузки будет невозможно загрузить, если в информационной базе, из которой производилась выгрузка, существовали ошибки.

4. Высокие требования к оперативной памяти.

Более свежий и улучшенный инструмент такой выгрузки получил развитие в утилите ibcmd, не требующей лицензии 1с и монопольного доступа для выгрузки:

Особенности. На скорость выгрузки и загрузки сильно влияет 1 GBE сеть. Т.е. существенно быстрее будет, если клиентская часть 1с или утилита будет находится на сервере 1с, а сервер 1с совмещен с сервером субд.

Загрузка. Загрузка данных из dt может выполняться как в один поток, так и во множесте потоков.

Причем при многопоточной загрузке можно поймать «блокировки» или «положить» диски и обойти проблему можно ручным указанием одного потока.

Можно прописать /RestoreIB «имяфайлазагрузки.dt» -JobCount 1 в «Дополнительные параметры запуска» в свойствах ИБ в стартере 1с.

Востановление через утилиту ibcmd" infobase create --db-path=d:\ibsrv\standalone-server\db-data --restore=1cv8.dt
дает гибкость при написании скриптов при массовом разворачивании баз (например в класее обучения) или при написании в 1с утилит по реализации такого копирования
.