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

25.08.22

База данных - Архивирование (backup)

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

Файлы

ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.

Наименование Скачано Купить файл
Архивирование базы в dt и дамп postgres:
.sh 1,05Kb
3 2 500 руб. Купить

Подписка PRO — скачивайте любые файлы со скидкой до 85% из Базы знаний

Оформите подписку на компанию для решения рабочих задач

Оформить подписку и скачать решение со скидкой

Вы можете заказать платную доработку или адаптацию этой разработки под вашу конфигурацию на «Бирже заказов».

  • 0% комиссии — оплата напрямую исполнителю;
  • Исполнители любого масштаба — от отдельных специалистов до команд под проект;
  • Прямой обмен контактами между заказчиком и исполнителем;
  • Безопасная сделка — при необходимости;
  • Рейтинги, кейсы и прозрачная система откликов.

# Каталог архивов
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.

См. также

Архивирование (backup) Инструменты администратора БД 1С:Предприятие 8 1C:Бухгалтерия 1С:Розница 2 1С:Управление нашей фирмой 1.6 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Управление нашей фирмой 3.0 1С:Розница 3.0 Платные (руб)

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

7320 руб.

06.11.2012    80383    635    45    

94

Архивирование (backup) Обновление 1С Системный администратор Разработчик 1С 8.3 Бесплатно (free)

Платформа 8.3.17, MS SQL Server: обновление конфигурации падает через 15 секунд на этапе обновления предопределённых данных, и конфигуратор при каждом входе предлагает только повторить. Проверьте у себя, когда сделана последняя полная копия базы: у нас её не было почти месяц. Разбор по минутам: что не помогло (перезапуск агента сервера 1С, перезагрузка, пакетный /UpdateDBCfg, три совета со стороны) и почему. Как ibcmd достал .dt из базы, которая не открывается, и как новую базу подставили под старым именем в кластере 1С через rac, не трогая пользователей. Простой 57 минут, потерь данных нет. Отдельно ошибки ИИ-агента Claude, который работал на сервере, и порядок действий на случай, если это случилось у вас.

03.11.2026    451    nedomolkov.ivan    10    

5

Архивирование (backup) Инструменты администратора БД Системный администратор Разработчик 1С 8.3 1С:Управление торговлей 11 1С:Библиотека стандартных подсистем Абонемент ($m)

Полностью автоматизированная внешняя обработка для администрирования 1С: блокировка/разблокировка ИБ, массовое завершение сеансов, резервное копирование и восстановление из .dt, выгрузка/загрузка конфигурации (.cf), пакетная работа с расширениями (.cfe) и дополнительными обработками – всё через удобную форму без ручных запусков конфигуратора и консоли кластера

1 стартмани

21.01.2026    6495    66    war41k    0    

18

Архивирование (backup) Групповая разработка (Git, хранилище) Системный администратор Разработчик Бесплатно (free)

Как дать возможность каждому разработчику 1С вести разработку, тестирование и оптимизацию на собственной полноразмерной копии базы и при этом не тратить миллиарды рублей и тысячи часов на развертывание тестового окружения, а так же экономить дисковое пространство? Расскажем о том, как с помощью инструмента Database Lab получать полноразмерные копии базы 1C на СУБД PostgreSQL за считанные секунды (даже в случае использования многотерабайтных баз).

15.12.2025    14185    nasonkin    19    

31

Архивирование (backup) Учет документов Бухгалтер 1С:Предприятие 8 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Россия Платные (руб)

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

12200 руб.

19.02.2025    2939    3    0    

3

Архивирование (backup) Системный администратор 1С 8.3 Бесплатно (free)

Предлагаю Вашему вниманию 3 скрипта на bash (sh) для архивирования (backup) типовых конфигураций на Linux средствами 1С и Postgres. Перед запуском корректно заполните раздел "Параметры" в соответствии с Вашими настройками.

20.01.2025    5970    Prelude    5    

12

Архивирование (backup) 1С 8.3 1С:Библиотека стандартных подсистем Абонемент ($m)

Резервные копии базы 1С без завершения сеансов: .dt, файл базы, PostgreSQL, MS SQL, своя команда. Расписание, профили, ротация, ZIP, FTP, журнал и письмо об ошибке. Платформа 8.3+ (кроме 8.2), любая конфигурация с БСП. Подключение за 5 минут.

5000 руб.

27.08.2024    4135    1    6    

2

HighLoad оптимизация Администрирование СУБД Архивирование (backup) Системный администратор Разработчик 1С:Предприятие 8 Бесплатно (free)

Бэкап в Postgres состоит из набора граблей, которые нужно обойти для успешного восстановления. Они заложены в самых неожиданных местах от предмета резервного копирования (база или кластер) до структуры каталогов. Один неверный шаг и восстановление будет невозможным. Почему нельзя было сделать проще, как в MS SQL или Oracle? Почему бэкап в Postgres оставляет впечатление чьей-то лабораторной работы? Статья адресована прежде всего специалистам 1С, избалованным комфортом в MS SQL, в суровых буднях импортозамещения на Postgres.

13.08.2024    10673    1CUnlimited    11    

6
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. Gilev.Vyacheslav 1924 03.03.23 10:15 Сейчас в теме
поправьте меня, но pg_dump -U postgres db_name должен вроде пароль спросить ?
2. Pasha1st 867 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 1924 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 867 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 1924 02.04.23 10:26 Сейчас в теме
(4)
PITR тоже нужен не всем, а с тем что в postgres он работает только при копировании кластера целиком - ещё и не всем удобен.

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

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

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

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

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

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

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