Резервное копирование баз данных Postgresql в Linux

У нас в ресурсе уже описано много способов реализации резервного копирования информации. Продолжим данную тему. Теперь, рассмотрим резервное копирование баз данных Postgresql в операционной системе Linux. Вот вариант резервного копирования для 3-х баз данных:

Сохранение бекапа на удаленном сервере по ssh В условиях отсутствия локального или сетевого тома для хранения резервных копий (несколько натянутое условие, но мне пришлось столкнуться), пришлось доработать скрипт; отличие от изначального скрипта – результат дампа не сохраняется локально, а передаётся на удалённый сервер по ssh и там же производится удаление устаревших файлов:

Предварительно надо создать авторизационный ключ для пользователя (в приведённом скрипте пользователь – backup) на сервере резервного хранения и разместить приватный ключ в каталоге, доступном на чтение только пользователю root (в приведённом скрипте ключ лежит в файле /root/nbs01/backup) и настроить sshd удалённого сервера на авторизацию по ключам – об этом весьма подробно написано, например, в этой статье. Да, трафик будет весьма серьёзным, несмотря на возможность сжатия ssh, но конкретно данное решение работает в виртуальной среде, где 3 гигабайта дампа передаются примерно за полторы минуты, что вполне приемлемо. Восстановление базы данных из дампа Тут всё просто – если владелец (имя “роли входа” или пользователь postgresql, указанный владельцем изначальной БД) уже существует, но нет самой базы данных, команда восстановления будет выглядеть примерно так: /usr/pgsql-9.2/bin/pg_restore -e -j 8 -U root -W -d upp /root/files/upp-2013-11-20.pgdump Восстановление будет выполнено в 8 потоков (для ускорения процедуры, в документации pgsql рекомендуется использовать потоков не меньше, чем доступно ядер CPU) от имени пользователя root с интерактивным вводом пароля. Файл /mnt/arc/1C8/upp-2013-11-20-09-45-51.pgdump – […]

Read more

Скрипт автоматического резервного копирования “1С:Підприємство”

Автор: Рудюк С . А. https://corp2.net E-Mail: rs@corp2.net Как показала практика, лучше всего делать резервные копии баз данных “1С:Підприємство” с помощью самой “1С:Підприємство”, а не с помощью средств базы данных. Т.к. по не понятным причинам бекап сделанный с помощью того же Postgresql, после восстановления не корректно работает. Более того, бекап желательно делать ежедневно. Понятное дело, вручную делать резервные копии информации дело неблагодарное, поэтому всегда хочется автоматизировать данный процесс. echo off for /f “tokens=1-4 delims=/ ” %%i in (“%date%”) do (  set dow=%%i  set month=%%j  set day=%%k  set year=%%l  ) set datestr=%month%_%day%_%year% echo datestr is %datestr%  set BACKUP_FILE=dp3_%date%.backup rem %datestr%.backup  echo backup file name is %BACKUP_FILE%  SET PGPASSWORD=ВАШ ПАРОЛЬ echo on net stop “1C:Enterprise 8.2 Server Agent” net start “1C:Enterprise 8.2 Server Agent” “C:\Program Files\1cv82\common\1cestart.exe” CONFIG /S “localhost\\dp3” /N “ВАШ ПОЛЬЗОВАТЕЛЬ” /P “ВАШ ПАРОЛЬ” /DumpIB “C:\backups\backup_dp\dp_3_%date%.dt” /AU- /DisableStartupMessages choice /n /t 180 /d y net use m: \192.168.3.1\backup /u:ПОЛЬЗОВАТЕЛЬ_СЕТЕВОГО_ДИСКА “ПАРОЛЬ ДЛЯ ПОДКЛЮЧЕНИЯ К СЕТЕВОМУ ДИСКУ” move C:\backups\backup_dp\dp_3_%date%.dt m:\1s\dp\dp_3_%date%.dt Объяснение к скрипту: 1. Вначале перезапускаем сервис. Т.к. если “висят” пользователи – резервное копирование не удастся. 2. Запускаем не видимый процесс “1С:Підприємство” и формируем бекап. 3. После истечения времени, достаточного для формирования бекапа “1С:Підприємство” – перемещаем файл на другой накопитель. Автор: Рудюк С . А. https://corp2.net

Read more

Резервное копирование информации между серверами. Защита информации от рейдеров

Автор: Рудюк С . А. https://corp2.net E-Mail: rs@corp2.net В сегодняшнее псевдо-правовое время, никто не может быть спокоен за безопасность техники и информации на ней. Даже если Вы запрячете информацию в бункер, к Вам могут прийти право-охранительные органы, взломать двери и достать оттуда всю технику. И сделать этом могут без выдвижения обвинения, а лиш назвав Вас “свидетелем”. При этом, свидетелем какого дела и почему изымается – могут не объяснять. Адвокатов – могут не пускать. Подобные ситуации в Украине – не редкость. И в последнее время, в связи с происходящей неразберихой в стране – участились. Изъятие информации – это один из самых серьезных и самых дешевых способов удара по предприятию. Многие компании, после таких действий вынуждены распускать персонал и закрывать свою деятельность. Т.к. даже начислить зарплату или отчитаться в налоговой не могут – вся информация “изъята”. Что же делать, если работать приходится в псевдо-прововом государстве ? Храните информацию распределенно по всему миру, синхронизируйте её между собой, храните в недоступных местах для потенциальных рейдеров и рекетиров. В данной статье рассказывается, как построить распределенную систему хранения информации. Структура сети Итак, рассмотрим примерную структуру хранения информации.   Здесь мы имеем структуру из 5 точек, которые синхронизируются друг с другом через интернет. Данная синхронизация может происходить в разное время, с применением динамических ip-адресов и использованием прокси-серверов из-за чего “вычислить” и уничтожить все узлы сразу – сравнительно проблематично. Не говоря о том, что сервера могут находиться в разных странах, числиться за разными людьми и управляться разными администраторами. Количество узлов делается настолько большим, насколько критична потеря информации и […]

Read more

Резервное копирование информации между серверами. Защита информации от рейдеров (Версия 2)

Автор: Рудюк С . А. https://corp2.net E-Mail: rs@corp2.net В сегодняшнее псевдо-правовое время, никто не может быть спокоен за безопасность техники и информации на ней. Даже если Вы запрячете информацию в бункер, к Вам могут прийти право-охранительные органы, взломать двери и достать оттуда всю технику. И сделать этом могут без выдвижения обвинения, а лиш назвав Вас “свидетелем”. При этом, свидетелем какого дела и почему изымается – могут не объяснять. Адвокатов – могут не пускать. Подобные ситуации в Украине – не редкость. И в последнее время, в связи с происходящей неразберихой в стране – участились. Изъятие информации – это один из самых серьезных и самых дешевых способов удара по предприятию. Многие компании, после таких действий вынуждены распускать персонал и закрывать свою деятельность. Т.к. даже начислить зарплату или отчитаться в налоговой не могут – вся информация “изъята”. Что же делать, если работать приходится в псевдо-прововом государстве ? Храните информацию распределенно по всему миру, синхронизируйте её между собой, храните в недоступных местах для потенциальных рейдеров и рекетиров. В данной статье рассказывается, как построить распределенную систему хранения информации. Изменения внесенные  13.10.2014 После выхода первоначальной статьи, я столкнулся с рядом вопросов, которые возникали при возникновении первоначального скрипта. 1. В 64-х разрядных версиях Windows проблема возникает с паролями, в которых есть кириллица. Поэтому, для данных версий, рекомендуется использовать только английские буквы, цифры и спец-символы. 2. При архивации локальных баз данных “1С:Підприємство” файлы не архивируются, если запущен процесс “1С:Підприємство”. Поэтому, перед архивированием, желательно останавливать процесс или использовать архивацию штатными средствами “1С:Підприємство”. 3. Базы данных “1С:Підприємство”, которые работают с […]

Read more