Pull to refresh

Comments 13

Улыбнул скриншот

Как надо чистить корзину.....

Посмотрите в сторону pg_probackup, они есть под винду - это куда лучше, проще и главное эффективней.

Вообще не надо postgresql под винду. Сотня-другая пользователей, и тормоза становятся невыносимыми.
А так, pg-probackup (https://github.com/postgrespro/pg_probackup) рулит:

  • автоматическая ротация архивов,

  • автоматическое слияние инкрементальной и полной копии,

  • полные, инкрементальные, PITR архивные копии,

  • непрерывное архивирование сегментов wal, с удалением ненужных сегментов,

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

  • сжатие архивных копий и сегментов wal,

  • прогнозируемое время восстановления,

  • ещё много всего, навскидку не упомню.

Но с него такой развесистой статьи не получится :) Настройка в полдюжины команд, и пара в кроне.

P.S. Кто-нибудь объяснит мне, почему везде pg_probackup, а пакет называется pg-probackup?

Простите, я не могу перестать кричать после прочтения этой статьи. Спать пора, а я не могу остановиться :)

Через пуск или в проводнике открываем приложение.
"C:\Program Files\pgAdmin 4\v6\pgAdmin4.ico"

Тыкая на файл иконки, Вы приложение не запустите.

Удаляем архивы старше 30 дней вручную. Затем чистим корзину на рабочем столе.
В проводнике папка E:\UH_IMD\Backup.

Выглядит надежно.

Автоматическое выполнение очистки копий старше 30 дней
Использован стандартный планировщик заданий Windows каждую субботу в 10:00 утра запуск, выполнения командного файла.

Просто замечу, что если у Вас 30 дней не будет делаться по какой то причине резервное копирование, то у вас не будет ни одной резервной копии

Пример содержимого общего файла логов backup.log.

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

P.S. Коллеги, сразу скажу, что я не системный администратор, а программист 1С. Системщик решил бы, может быть, элегантнее. 

С десяток лет уже не оправдание, знание основ SQL для 1С специалистов уже давно обыденность.

Автор статьи: технический руководитель проектов внедрения 1С:ERP Внедренческого центра «Раздолье» Дмитрий Малышев.

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

Вопрос на засыпку: у меня 200+ баз, от 10-15 гигабайт каждая, где в статье отсутствует фрагмент про инкрементные бэкапы?

Простите меня, но такие примеры "внедрений" просто ужасны.

Первая реакция была схожая, но я как «админ адинэс» уже давно принял для себя за правила относится к подобному творчеству разрабов 1С философски ))
Ну нет там толковых сисадминов, точнее — их единицы. У нас (в России) вообще традиционно системным инженерам внимание уделяется по остаточному принципу, т.к. мало кто понимает — что они вообще делают, а в сфере 1С — это вообще тухляк. Пресловутая «миста» забита подобными статьями чуть больше, чем полностью: торжество магических практик налицо.
По этому не пинайте автора — он играет как может )) Сказали «давай статью IT-тематики в блог на Хабре, ща продвигаться будем» — он и дал, что мог.

На всякий случай акцентирую внимание: В блоге компании занимающейся внедрениями ERP решений, технический руководитель проектов внедрений выкладывает статью под своим авторством, в которой на уровне компетенций джуна описывает процесс обслуживания типовой (даже не ERP) конфигурации 1С с хранением базы в PostrgeSQL.

Чего я ожидаю от этой статьи написанной техруком из специализированной компании занимающейся внедрением? Как минимум выжимку из внутрикорпоративного чеклиста/гайдлайна/деплоймент воркфлоу в создании которого, естественно, участвовали специалисты этой компании в своей области, как минимум сисадмины + DBA + 1С Эксперты ибо это то что делают внедренцы в инфраструктурах заказчиков. Это такой живой документ, который актуализируется после каждого внедрения.

Чего мы получаем?

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

Давайте закроем глаза и поставим натянутую четверочку как в современном образовании? Ну старался же человек? Или нет? А что я сделаю, если вдруг узнаю что эта компания что то захочет у меня внедрять что то?

Не говоря о том что для любого мало-мальски грамотного администратора РСУБД "дамп" вообще ни каким боком не является синонимом "бекапа"!

За то, что не нужно искать команды для pg_dump - спасибо. Отдельно спасибо за команду forfiles.

А вот

Ищите для работы вот этот материал с инструкциями для скачивания и использования:

ну это как-то неправильно... тем более что это есть по тексту, просто не отдельными файлами.

Или это такой способ повысить поисковый индекс сайта "компании";)

Нет, там ссылки на конкурирующий сайт, за это могут "оштрафовать". Скинуть в личку?

Сколько я ни экспериментировал с pg_dump - восстановить базу 1с обратно не получалось. Подскажите, не проще ли делать бэкап папки Data? Остановить сервис postgreSQL, сделать архив всей папки, запустить сервис обратно

Жаль, поздно увидел заметку. Когда понадобилось из бэкапа восстановить, искать и читать было некогда. Бэкапы делаются в бесплатной версии Effector Saver, пустую базу ничтоже сумняшеся создал в оснастке Администрирования серверов 1С, в PG Admin 4 затащил в неё бэкап без очистки, разумеется конфликтов таблиц куча, база не заработала. Пробовал поврежденную в Конфигураторе в "Тестирование и исправление информационной базы 1С" - 13 часов "исправлялось", таймер задать не сообразил, не ожидал настолько долгого процесса, пришлось убить процесс (ctrl+break не работал, его обычно рекомендуют для этой задачи). Для повторного восстановления уже чистую базу в PG Admin создал, очистку не ставил, template0 не указывал, база восстановилась и работает, хотя была одна ошибка (вроде "схема уже существует"). В 1С базу публиковал опять в оснастке на сервере, не сообразил, что из клиента можно. Из клиента последний раз базу создавал ещё в семерке файловую много лет назад.
Кроме 1С работы на пятерых в одно жало, так что опыт других изучать приходится, когда жареный петух клюнет. Бухгалтерия на плечах сидела. Платная техподдержка 1С отказала в помощи, специалистов по Postgre нет, все по MS-SQL.

Бэкап-файлы хорошо бы архивировать, как Effector Saver делает. Файлы ближе к 8 Гб, а когда баз ещё десяток - слишком много места уходит на бэкапы, в сжатом виде в несколько раз меньше.

Sign up to leave a comment.

Articles