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

Любая компания сталкиваемся с необходимостью резервного копирования данных. ООО «НОРД-М» предлагает масштабируемые решения для организация любых видов резервного копирования любых видов информационных систем.

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

Мы подберем для Вас программные решения и обоснуем все технические вопросы резервного копирования

В своих решениях мы используем ключевые параметры резервного копирования являются RPO — Recovery Point Objective и RTO — Recovery Time Objective.

RPO определяет точку отката — момент времени в прошлом, на который будут восстановлены данные.

RTO определяет время, необходимое для восстановления из резервной копии.

1. Логический, или SQL, бэкап (pg_dump, mysqldump, SQLCMD). При этом создается мгновенный снимок содержимого базы с учетом транзакционной целостности и сохраняется в виде файла с SQL-командами (можно выбрать всю базу или отдельные таблицы), при помощи которого можно воссоздать базу данных на другом сервере. На это требуется время (особенно для больших баз) для сохранения и восстановления, поэтому очень часто эту операцию выполнять нельзя и ее производят во время минимальной нагрузки (например, ночью). При восстановлении администратору необходимо выполнить несколько команд, чтобы подготовить все необходимое (создать пустую базу данных, учетные записи и прочее).

2. Физический бэкап (уровня файловой системы) — копирование файлов, которые СУБД использует для хранения данных в базе данных. Но при простом копировании игнорируются блокировки и транзакции, которые, скорее всего, будут неправильно сохранены и нарушены. При попытке присоединить этот файл он будет в несогласованном состоянии и приведет к ошибкам. Чтобы получить актуальный бэкап, базу данных нужно остановить (можно уменьшить время простоя, использовав два раза rsync — вначале на работающей, потом на остановленной). Недостаток этого метода очевиден — нельзя восстановить определенные данные, только всю базу данных. При старте БД, восстановленной из архива файловой системы, нужно будет провести проверку на целостность. Здесь используются разные вспомогательные технологии. Например, в PostgreSQL логи упреждающей журнализации WAL (Write Ahead Logs) и специальная функция (Point in Time Recovery — PITR), позволяющая вернуться к определенному состоянию базы. С их помощью легко реализуется третий сценарий.

3.  Бэкап уровня файловой системы объединяется с резервной копией WAL-файлов. Вначале восстанавливаем файлы резервной копии файловой системы, а затем при помощи WAL база приводится к актуальному состоянию. Это чуть более сложный подход для администрирования, но зато нет проблем с целостностью БД и восстановлением баз до определенного времени.

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

Порой потерять даже всего несколько рабочих часов из-за того, что резервное копирование не выполнено, — может быть очень болезненным.

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

- сетевые файловые хранилища на базе SMB, NFS;

- SQL базы;

- базы 1С;

- AD и OpenLDAP;

- конфигурации сетевого оборудования;

- почтовые базы Exchange;

- содержимое дисков серверов;

- содержимое дисков ПК пользователей.

P.S. Бесплатный тестовый доступ и консультация наших тех. специалистов предоставляется для всех наших клиентов