Потерять свои данные легко. Достаточно хранить их на рабочем столе или в «моих документах», а затем переустановить Windows. Либо не создавать новую базу данных, а редактировать встроенную в программу демо-базу (при обновлении на новую версию она перезапишется). Или «поймать» вирус-шифровальщик. Если вы не делали резервных копий, то наша поддержка не сможет вам помочь. Но при этом, как показывает практика, даже, если вы делали резервные копии, это не гарантирует того, что вам удастся их восстановить. В этой заметке мы расскажем, как делать резервные копии базы данных Fox Manager правильно, без риска их потерять.
Для начала следует заметить, что делать резервные копии прямо из программы Fox Manager НЕБЕЗОПАСНО! Гораздо правильнее использовать для этого инструменты самой базы данных. Если пользуетесь базой SQLite – достаточно скопировать сам файл базы (xxxxx.sqlite) в какую-то другую папку или на флешку. Если используете базу MySQL – воспользуйтесь утилитой mysqldump, а для базы MS-SQL Server – Sqldumper.exe и т.д.
Ниже мы расскажем несколько историй о том, как пользователи потеряли свои данные, хотя и делали резервные копии.
Случай №1.
Клиент – владелец небольшой фирмы. Базу данных строит сам и сам же делает резервные копии. В ходе работы создал несколько файловых баз и назвал их примерно так «Вася-Пупкин.sqlite», «Вася-Пупкин (Новая).sqlite», «Вася-правки.sqlite» и «Вася-последняя.sqlite». Пользовался только одной из них, а остальные лежали рядом на диске. Регулярно делал резервные копии базы «Вася-последняя.sqlite», но на самом деле всё это время работал с базой «Вася-правки.sqlite». В итоге, когда понадобилось срочно восстановить данные после поломки ноутбука – получил копию, которой больше года.
Вывод: следите за тем, чтобы делать резервные копии именно рабочей базы данных. Посмотреть путь к рабочей базе данных можно в нижней части окна программы.
Случай №2.
Достаточно большое зарубежное предприятие пользуется программой на нескольких языках и использует серверную базу данных. Администратор делает резервные копии автоматически и хранит их как на сервере, так и на внешнем жестком диске. Как-то раз руководство попросило восстановить данные за прошлую неделю, так как им не понравились новые редакции бизнес-процессов, разработанные аналитиками. Администратор удалил рабочую базу данных и восстановил данные из резервной копии. После этого все буквы русского алфавита стали нечитаемыми. Оказалось, что всё это время резервные копии сохранялись в неправильной кодировке и восстановить оригинальную информацию не представляется возможным.
Вывод: недостаточно делать резервные копии, нужно также проверять их целостность и корректность. Не поленитесь восстановить данные в пробную пустую базу и убедиться, что резервное копирование прошло успешно.
Случай №3.
Системный администратор делает резервные копии каждый день в конце рабочего дня и хранит данные за последнюю неделю. Как-то раз, ответственный за бизнес-модель специалист ушёл в отпуск, а кто-то из сотрудников случайно удалил несколько важных бизнес-процессов. В первое время никто ничего не заметил, так как визуально у каждого сотрудника просто пропало по несколько функций из должностных инструкций. Спохватились только дней через 10, после выхода бизнес-аналитика из отпуска, но, к сожалению, нужного процесса не было ни в одной из резервных копий.
Вывод: храните не только самые последние резервные копии, но также оставляйте по одной версии на конец недели и конец месяца.
Подводя итоги, хотим заметить, что просто делать резервные копии недостаточно, необходимо проверять их целостность и иметь несколько версий из разных временных промежутков. Бизнес-модели строятся долго, лучше потратить пару минут в конце рабочего дня на создание копии, чем несколько недель пытаться восстановить информацию по отдельным документам и отчётам.