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

Давайте произведём мысленное упражнение. Оторвитесь от газеты, (или не отрывайтесь, если читаете её с экрана на рабочем месте) и представьте, что вот прямо сейчас ваш компьютер отключился и никогда больше не включится. Или то же самое произошло на сервере с базой данных, с которой вы работаете. Ваши действия?

Если на этот случай у вас готов сценарий действий, который вы недавно успешно репетировали, можно дальше не читать — скорее всего вам будет неинтересно. Рассмотрим простой вариант с потерянной базой данных. Потерять её безвозвратно можно многими способами — сбой оборудования, человеческий фактор, стихийные бедствия, а восстановить только одним способом — восстановлением из актуальной резервной копии. Вот тут начинается самое интересное.

ТОП 5 ответов на вопрос «А когда вы в последний раз делали резервную копию?»

1. А что это?

2. А что, обязательно?

3. Мы специально купили для этого программу, но так и не поставили.

4. Как только возникла проблема, сразу сделали резервную копию.

5. Мы сделали перед обновлением, потом увидели, что всё работает, и её удалили.

Какие сделаем выводы из печального опыта других? Во-первых, копии делать надо в любом случае. Естественно, хранить настолько долго, насколько это возможно. Хранить как можно дальше от основного места работы. Например, копия, сделанная на тот же диск, где находится основная информация, не поможет при неисправности этого диска. Копия, сделанная на внешний диск, подключенный к компьютеру, не поможет, если его украдут вместе с компьютером. Насколько надёжно вы хотите защититься от потери данных, зависит только от вашей паранойи. В идеале должно быть примерно так - «оперативная» (как минимум, ежедневная) резервная копия хранится «под рукой», «долговременная» (еженедельная, ежемесячная, ежегодная) хранится на отдельном носителе в специально назначенном месте (дома, в «облаке», в сейфе, в банковской ячейке, спецкапсуле на дне Марианской впадины и т. д.).

Следующий немаловажный момент — проверка корректности создания резервной копии. Случаются моменты, когда вроде как настроили резервное копирование, автоматизировали и забыли на пару лет. Внезапно авария. Решили восстановить данные из резервной копии - и не смогли. Почему? Вариантов масса: копировали не те данные, которые нужны, перевели учёт на новую базу, а копировали по-прежнему старую, место, куда копировали, закончилось год назад и т. д. Поэтому обязательно нужно проверять, возможно ли восстановление из существующей резервной копии.

Чаще всего в организациях резервным копированием занимаются отделы технической направленности. Если у вас таковой имеется, не надо думать, что они по умолчанию делают копии всего, сразу и навсегда. Не стоит надеяться на телепатические способности сотрудников этих отделов, нужно согласовать объекты для резервного копирования, периодичность резервного копирования и глубину хранения резервных копий. Периодически можно их проверять просьбами восстановить копию какой-либо информации на определённый момент времени в рамках согласованного графика резервного копирования.

Давайте теперь рассмотрим некоторые особенности, касающиеся работы с «1С:Предприятием 8». Пользователям «облачных» сервисов (например, 1C-Fresh) в данном отношении легче — кроме резервного копирования, осуществляемого самим сервисом, можно настроить свой график резервного копирования и в любое время сделать резервную копию самому.

При использовании обычной версии «1С:Предприятия» необходимо настраивать резервное копирование самостоятельно. Многие для резервного копирования используют выгрузку информационной базы в режиме Конфигуратора. Это конечно лучше, чем вообще не делать резервную копию, но данный способ не является рекомендуемым самой фирмой «1С» (см. на its.1c.ru статью «Рекомендации по организации резервного копирования информационной базы»). Есть два основных недостатка данного способа — обязательный монопольный режим (прочие пользователи в это время не могут работать с базой данных) и риск, что при повреждённой базе выгрузятся не все данные.

Как делать правильно? В случае файлового режима работы «1С:Предприятия» резервную копию надо делать путём копирования файла 1CV8.1CD из папки с базой данных в отдельную папку. Этот файл и есть ваша информационная база. По желанию, после копирования этот файл можно упаковать любым архиватором (главное, иметь возможность распаковать его обратно). Данный способ тоже имеет недостаток в необходимости монопольного доступа, но зато есть возможность исправить базу в случае её повреждения.

В случае клиент-серверного режима работы рекомендуется создавать резервные копии средствами СУБД (MS SQL, PostgreSQL и т. д.). Главное преимущество - возможность резервного копирования без монопольного доступа, практически незаметно для остальных пользователей. Кроме того, в некоторых случаях можно восстановитьданные не только на момент создания резервной копии, но и на любой момент времени существования базы.

Для привлечения внимания к теме резервного копирования даже установили специальную дату. Международный день резервного копирования (англ. World Backup Day) отмечается 31 марта. День выбран неслучайно: известны случаи потери данных именно 1 апреля. Существует даже целая группа первоапрельских вирусов, которые активизируются именно в этот день. Наверное, стоит отметить этот день внеочередным созданием резервной копии?

Александр Илясов,

руководитель технического отдела