Архивирование базы в dt и дамп postgres

25.08.22

–

Захотелось клиентам выгрузку архива баз, и выгрузку в дт, готовые скрипты с сети не заработали. Может, кому-то поможет. Релиз 8.3.18.1741.

Скачать исходный код

	Наименование	Файл	Версия	Размер
	Архивирование базы в dt и дамп postgres: .sh 1,05Kb 2	.sh		1,05Kb	2	Скачать

# Каталог архивов
dir_backups='/home/user/1c_dump/'
# Дата
data=`date +"%Y-%m-%d_%H-%M"`

# Создаем дамп

#db_name user1c pass_1c // если нет пароля то ключь --password=pass_1c не используем
/opt/1cv8/x86_64/8.3.18.1741/ibcmd infobase dump --db-server=localhost --dbms=postgresql --db-name=db_name --db-user=postgres --db-pwd=pass_sql --user=user1c --password=pass_1c $dir_backups/$data-db_name.dt
pg_dump -U postgres db_name | gzip > $dir_backups/$data-db_name.dump.gz

# Удаляем в папке с архивами файлы старше 1-х дней
find $dir_backups -type f -mtime +1 -exec rm -rf {} \;

#Востановление базы
#psql -U postgres -c 'DROP DATABASE "db_name";'
#psql -U postgres -c 'CREATE DATABASE "db_name";'
#gunzip <имя_архива>.dump.gz
#psql -U postgres -d DocMngProf < /home/user/1c_dump/db_name.sql

#запуск по расписанию
#sudo nano /etc/crontab
#0 0 * * * home/user/1c_dump/backup.sh
# systemctl restart cron

backup postgres sql dt.

–

См. также

Журнал изменений с восстановлением состояния ссылочных объектов и архивацией по HTTP / COM (расширение + конфигурация, 8.3.14+, ЛЮБАЯ конфигурация)

Архивирование (backup) Журнал регистрации Поиск данных Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 1С:Управление торговлей 11 Платные (руб)

База данных «сама» меняет данные в документах/справочниках? Тогда данный журнал изменений для Вас! Практически не влияет на скорость записи объектов за счет быстрого алгоритма! Скорость работы почти в 2 раза выше типового механизма "История изменений"! Позволяет следить за изменениями и удалением в любых ссылочных объектах конфигурации, с возможностью архивации по HTTP(!) или COM, и сверткой данных. А так же, может восстановить состояние реквизитов (значения) до момента изменения или удаления объекта из базы. Есть ДЕМО-база где можно самостоятельно протестировать часть функционала! Работает на любых платформах выше 8.3.14+ и любых конфигурациях! Версия 3.1 от 24.08.2023!

21600 руб.

15.05.2017 42645 10 24

BackUPv8 - система резервного копирования баз 1С

Архивирование (backup) Платформа 1С v8.3 Конфигурации 1cv8 Платные (руб)

Автоматическое создание копий файловых и серверных информационных баз 1С Предприятие 8 и размещение копий в облаке Яндекс.Диск, локальном или сетевом ресурсе.

1200 руб.

03.09.2014 14833 15 6

Автоматическое резервное копирование любой клиент-серверной базы 1С в формате DT с удалением сеансов, архивацией, изменением расширения (8.3.14+, расширение)

Архивирование (backup) Инструменты администратора БД Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 Платные (руб)

Данная разработка позволит решить вопрос с резервным копированием Ваших баз в автоматическом режиме, расположенных на сервере 1С. Система умеет ставить блокировки на вход, блокировать фоновые задания, принудительно отключать сеансы пользователей. И все это система делает в автоматически при создании бэкапа (или через команду). Выгрузка происходит в родной формат 1С - .dt. Так же система умеет архивировать данные выгрузки с установкой пароля. Умеет менять расширение файла zip или dt на любое указанное вами, что позволит сохранить выгрузки от шифровальщика. Может удалять старые копии выгрузок, оставляя указанное количество резервных копий, начиная с самой поздней.

6000 руб.

06.11.2012 70232 622 44

Резервное копирование журнала транзакций, наконец-то!

Архивирование (backup) Администрирование СУБД Россия Бесплатно (free)

Постараюсь объяснить, зачем нужно резервное копирование именно журнала транзакций, а не только базы данных, и почему я словно сбросил груз, настроив его - как, покажу, естественно. Кстати, будут скрипты T-SQL (с подробными комментариями) - отличный способ сделать администрирование базы более уютным.

04.12.2023 6271 n_mezentsev 15

Копии баз данных и размер БД. Проблемы и пути решения

Администрирование СУБД Архивирование (backup) Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Столкнулся с проблемой быстрого роста объема БД. Статья о том, как решал эту проблему.

30.11.2022 2792 DrMih 5

Резервное копирование и восстановление 1С баз на PostgreSQL в Windows с помощью pgAdmin, bat-файлов и планировщика

Архивирование (backup) Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

В данной инструкции будет описано, как с помощью pgAdmin, bat-файлов и планировщика заданий Windows организовать резервное копирование, восстановление и хранение копий баз данных.

07.10.2022 20550 sapervodichka 36

143

Cкрипт для выгрузки DT (детешников) утилитой ibcmd 1С+MSSQL

Архивирование (backup) Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

1С+MSSQL Выгрузка информационной базы в файл dt ibcmd infobase dump.

26.09.2022 3794 user1752096 6

Утилита копирования баз данных 1С

Архивирование (backup) Платформа 1С v8.3 Абонемент ($m)

Небольшая утилита для копирования файловых баз данных 1С.

1 стартмани

02.06.2022 4272 3 Giblarium 12

Комментарии

Подписаться на ответы Инфостарт бот

Свернуть все

1. Gilev.Vyacheslav 1911 03.03.23 10:15 Сейчас в теме

поправьте меня, но pg_dump -U postgres db_name должен вроде пароль спросить ?

2. Pasha1st 838 28.03.23 12:27 Сейчас в теме

(1) в Linux по умолчанию (без указания -h 127.0.0.1 например) подключение идёт через unix-сокет, на который опять же по умолчанию стоит проверка прав peer. Если скрипт выполнять от пользователя postgres - пароль не спросит.
Вариант 2 - установить проверку для локального postgres в trust. Тогда тоже не спросит
Вариант 3 - установить переменную PG_PASSWORD=пароль
Вариант 4 - прописать пароль к серверу в pgpass.conf (только не помню где он в linux должен лежать)

А вот дёргать дамп через ibcmd с базы при работающем сервере 1С не стоит, легко получить неконсистентные данные, ibcmd не использует общую транзакцию. Вариант рабочий, но в правильном виде можно сделать копию базы (pg_dump |psql) и с неё делать дамп. Или просто остановиться на pg_dump )))

3. Gilev.Vyacheslav 1911 29.03.23 03:44 Сейчас в теме

(2)

подключение идёт через unix-сокет

в статье идет подключении по tcp/ip , если сервер 1с на другом сервере, то ни какого юникс-сокета

в trust

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

PG_PASSWORD=пароль

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

пароль к серверу в pgpass.conf

так понимаю вы с серьезной службой безопасности еще не дел не имели

а pg_dump типа полностью консистентную базу делает? pg_dump НЕ может использоваться как для восстановления на определенный момент времени. Пока делается бэкап, а на большой базе это может занимать существенное время, то даже если по окончанию бэкапа вы начнете делать новый, но в этот момент произойдет сбой, и второй не успеет к этому моменту завершиться, то вы потеряете много данных.
Кроме того, не получится откатиться к нужному моменту времени, вы сможете выбирать только из времен создания дампов.
Таким образом, такой метод применим, если у вас базе работает пара пользователей и забивает в день пару документов, и их проще руками восстановить. Для большинства такой метод логического резервного копирования не годится — объем потерянных данных неприемлем. Ну разве что вы в отсутствии пользователей сделаете дапм и перенесете на новое место, например на новый сервер. Но и тут скорее надо делать бэкап всего «кластера PG» целиком командой pg_dumpall, а при полностью идентичных средах просто каталог кластера скопировать.
Dump не содержит информации для дальнейшего воспроизведения журнала транзакций и потому не подходит для решения задачи восстановления на момент времени (Point-in-Time Recovery, PITR).
И это ещё не говоря о том что не сбрасываются на из кэша на диск данные, и вообще могут жить в кэше ОС, что не добавляет гарантий 100% работоспособности бэкапа. В очень редких случаях бэкап может оказаться не пригоден для восстановления базы из него. Т.е. в силу особенностей механизмо работы субд DUMP это не полный аналог полного бэкапа скуля!

уж не говорю о том что каждую неделю в тематических чатах и форумах вижу "не подымается dump, что делать?"

4. Pasha1st 838 29.03.23 12:06 Сейчас в теме

(3) Мой ответ был исключительно в контексте вопроса к статье.
Статья - очень поверхностная и местами вредительская.
Угадайте что же могло указать в статье что среда - линукс, и в команде подключения
pg_dump -U postgres db_name
используется unix-сокет?
Без допнастроек (про которые автор скромно умолчал) скрипты работать не будут, я только предполагаю что же он использует чтобы скрипты работали. Скорее всего - запуск скрипта от пользователя postgres, тогда сработает подключение с правами peer
Но перечислил и другие варианты
Далее, у Вас явно уклон в кейс "одна большая база", хотя на одного клиента с базой хотя бы на 100Гб встретится сотня клиентов с одной-несколькими мелкими базами (до 10Гб скажем).
PITR тоже нужен не всем, а с тем что в postgres он работает только при копировании кластера целиком - ещё и не всем удобен.
pg_dump сделает базу на определенный момент времени, это не хорошо и не плохо, это особенность. Из плюсов - можно делать копию одной отдельной базы, стандартный plain-формат не восстановиться не может, а если и есть проблемы - легко поправить в дампе текстовым редактором.
С кешами - для pg_dump мимо, на то это и логический дамп.
А вот у MSSQL действительно можно получить дамп (с поврежденной базы) который потом не восстановится. И приходится отдельно включать проверку копий.

5. Gilev.Vyacheslav 1911 02.04.23 10:26 Сейчас в теме

(4)

PITR тоже нужен не всем, а с тем что в postgres он работает только при копировании кластера целиком - ещё и не всем удобен.

так сразу бы и сказали что вы из лагеря "отрицателей RPO/RTO"
какие блин "удобно-не удобно", таких горе-специалистов надо сразу увольнять
основная задача админа - обеспечить работоспособность компании и не потерять информацию в случае сбоя или свести к минимуму потери.

я уж не говорю частичной неработоспособности дампов - https://forum.infostart.ru/forum34/topic205091/

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

А вот у MSSQL действительно можно получить дамп (с поврежденной базы) который потом не восстановится.

двоишнику на заметку:
- DBCC CHECKDB
- контроль целостности бэкапа
- мониторинг логов скуля на ошибки записи
- мониторинг ssd на износ и температуту
- исторические копии на глубину последние 7 дней, месячной, кватральной и годовой давности - на удаленную площадку без сквозной авторизации (например по фтп)
решают полностью вопрос

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

6. Pasha1st 838 02.04.23 12:46 Сейчас в теме

(5) Что же Вы не комментируете исходную статью?
Типичного бухгалтера, коих тысячи, с базами в пару-тройку гигабайт, из которых гиг конфигурация и гиг ФИАС, вполне устраивает ежедневное копирование, зато восстановление в течении 5 минут. Да и с такими объемами можно их делать каждый час.
Весело становится когда такой бухгалтер работает в кластере с не одним десятком баз и надо вернуть только одну именно его, потому что "случайно" удалил документы прошлого года. А бекап настроен по феншую кластера целиком.
Для разных случаев - разные сценарии копирования. Расскажу фокус - для маленьких баз выхлоп от pg_dump в plain вообще можно через diff прогнать и сохранить разницу. Для больших не получится. Для каждого случая свой подход.
Ваш сценарий - "всё сломалось, срочно восстанавливаем как есть". Есть и другие.

я уж не говорю частичной неработоспособности дампов

Знакомый случай. Редкий и сейчас неактуальный - в базах с уровнем совместимости 8.3+ в таблицу config ввели разбиение данных с полем PARTNO, которое сводит проблему на нет.
При этом Вы рассказываете что же нужно делать в MSSQL чтобы избежать кривых дампов, но для PostgreSQL считаете что "всё плохо". Настраивать и контролировать надо и там и там.

исторические копии на глубину

Советы хорошие, правда применимы и для любой СУБД, хоть файловой. И если их не обсуждали не значит что им не следуют.
Из моего комментария на вопрос к статье про использование пароля для pg_dump Вы делаете какие-то слишком глобальные выводы. Я тут не писал статью "как правильно делать бекапы на все случаи жизни".