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

25.08.22

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

Скачать файл

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

Наименование		По подписке [?]	Купить один файл
Архивирование базы в dt и дамп postgres: .sh 1,05Kb 3	3	Скачать (1 SM)	Купить за 1 850 руб.

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

+7 –

См. также

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

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

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

6000 руб.

06.11.2012 72787 625 45

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

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

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

1200 руб.

03.09.2014 15703 21 6

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

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

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

04.12.2023 9425 n_mezentsev 15

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

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

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

30.11.2022 3328 DrMih 5

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

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

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

07.10.2022 28593 sapervodichka 37

147

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

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

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

26.09.2022 5179 user1752096 6

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

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

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

1 стартмани

02.06.2022 4689 3 Giblarium 12

Конфигурация 1С v.8, для резервного копирования клиент-серверных баз 1С v.8 в *.DT на внешний FTP сервер

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

Данная конфигурация, по времени, указанном в регламентном задании, проходит по заполненному в ней справочнику баз 1С, отключает пользователей и рабочие сеансы и выгружает в файл *.DT: локальную папку, сетевую папку или ftp сервер.

1 стартмани

22.04.2022 5881 32 FeDBuka 10

Комментарии

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

Свернуть все

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

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

2. Pasha1st 849 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 1917 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 849 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 1917 02.04.23 10:26 Сейчас в теме

(4)

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

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

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

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

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

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

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

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

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

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

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

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

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