Описанные выше проблемы сопровождается устрашающими сообщениями: «файл базы данных поврежден», «файл базы данных полностью разрушен», «ошибка компоненты DBENG..», «..ошибка SDBL…» и т.д. У пользователей в таких случаях, возникают одни и те же вопросы:
— из-за чего такое бывает?
— кто виноват?
— что теперь делать?
Как правило, причинами нарушений структуры баз данных, могут являться как банальное поражение дан- ных компьютерными вирусами, перебои в электрической сети или сбои в работе локальной сети, на жестком диске и других жизненно важных составляющих компьютера, так и некорректное завершение работы программы 1С или компьютера, сбои в процессе обновления базы 1С из- за скачка в электросети или нестабильного подключения к сети Интернет и т.д.
К сожалению, не все поврежденные базы можно «вылечить» без потери данных и единственным способом обезопасить себя от возможных неприятных последствий является резервное копирование информационных баз.
Часто ли вы делаете резервные копии баз? Мы настоятельно рекомендуем делать резервные копии баз 1С в обязательном порядке перед каждым обновлением или любыми непроверенными действиями и экспериментами с данными, а также время от времени просто так выполнять копирование баз.
Где хранить копии базы?
Представьте ситуацию: Вы исправно делаете копии базы и храните эти архивы рядом с самой базой данных (на том же жестком диске, например). В таком случае любое серьезное повреждение или поломка компьютера сулит безвозвратную потерю как самой базы, так и ее копии.
Чтобы этого избежать, мы советуем на вашем предприятии хранить архивы 1С на отдельном компьютере в локальной сети. Если такой возможности нет, то можно хранить копии на своих рабочих компьютерах в отдельной от каталога базы папке, страхуя себя и предприятие ещё несколькими актуальнейшими копиями на съемных носителях (DVD, CD-диск или флэшка).
Как начать делать копии?
Если ранее копии делались «не помню как» или «не помню куда», то стоит создать на отличном от системного жестком диске или в специальной сетевой папке каталог «Архивы 1С» и начать помещать в этот каталог копии баз и делать это как можно чаще. Также не забывайте, что копирование базы нужно выполнять, только если все пользователи завершили работу с базой. Например, утром, вечером или ночью, когда никто с данными базы (уже или ещё) не работает.
Как делать копии баз 1С?
Существует несколько способов копирования файловых баз. Основные из них описаны на ИТС в разделе
«Разработка и амнистирование», мы рассмотрим их подробнее.
1. Копирование каталога базы данных или файла БД (с расширением 1CD).
Скопировать файл БД или весь каталог с базой можно практически всегда как в архивную папку, так и обратно для восстановления данных из архива.
Кроме этого, существуют специальные программы-архиваторы, которые можно настроить на автоматическое выполнение подобного копирования со сжатием данных и без сжатия в заданный день и час без участия человека. В рамках данной статьи мы не будем рассматривать настройку такого копирования – это работа технических специалистов. Если таких сотрудников в организации нет, можно обратиться за оказанием данной услуги в Компанию Портал-Юг.
Рассмотрим пример поиска и копирования файла (каталога) БД для создания копии.
Это делается очень просто. База данных 1С представляет из себя папку. Местонахождение этой папки легко определить в окне запуска 1С, ориентируясь на нижнюю строку.
Если база не файловая, а клиент-серверная, то в этом окне путь к ней будет начинаться со слова «Srvr=…» вместо «File=…». Вопросы администрирования клиент- серверных баз намного сложнее, они решаются силами технических специалистов, имеющих соответствующий опыт работы, поэтому в данной статье мы их не рассматриваем.
После того, как определён путь, его можно открыть любым доступным способом, например, через Мой компьютер/…
Обычно файл базы называется «1Cv8.1CD» и часто, по умолчанию, файл-менеджер (в данном случае «Мой компьютер») настроен так, что расширения файлов не видно. В таком случае можно ориентироваться на тип файла –
«Файловая информационная база». Если с базой данных никто не работает, то в каталоге БД файл с таким типом только один.
Именно этот файл – «Ваше всё» – хранит и конфигурацию (структуру) и все данные, внесенные в базу пользователем. Для создания резервной копии достаточно скопировать этот файл БД или весь каталог в папку с архивами 1С и не забыть переименовать его так, чтобы различать копии базы от разных дат.
2. Выгрузка информационной базы в архивный файл с расширением dt в режиме Конфигуратора.
Основное отличие этого способа от первого в том, что данные базы запаковываются в специальный архивный
файл, позволяющий более компактно хранить данные за счет уменьшения размера файла. Если возникает необходимость «выгрузить» базу в такой файл, то достаточно воспользоваться штатным способом, предусмотренным разработчиками для любых баз:
— открываем базу в режиме «Конфигуратор»;
— в меню «Администрирование» выбираем «Выгрузить информационную базу»;
— меняем имя файла так, чтобы отличать его от копий, сделанных ранее;
— стартуем сохранение.
Обращаем ваше внимание — загрузка данных полностью заменяет содержимое каталога ИБ содержимым загружаемого файла!
Кроме этого, во избежание ошибок и проблем с загрузкой данных в базу перед выгрузкой в dt-файл, рекомендуется убедиться в пригодности архива, сделав тестирование и исправление базы. Подробнее об этом можно почитать на ИТС: Разработка и администрирование/ Документация/Платформа 1С:Предприятие 8.2/Руководство администратора/Администрирование информационной базы/Глава 6…/п.6.9. Обратите внимание, что перед тестированием также обязательно сделать копию базы, т.к. этот процесс может произвести необратимые изменения в базе данных. Уважаемые пользователи, берегите своё время, деньги и здоровье – выгружайте информационные базы в архивную папку как можно чаще. Помните, что далеко не все нарушения в структуре данных возможно исправить. А причины таких потерь не предсказуемы.
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
Преступление и наказание.
Зачетная статья (еще и с картинками), для бухов самое то (ну и себя прорекламировать, как же без этого) 🙂
отличный пост)
рекламой попахивает!
Ну да я думаю для бухов в качестве инструкции пойдет.
Про зайцев — неактуально. А вариант 2 вообще недопустимо использовать для архивного копирования, об этом 1С во всех руководствах пишет. Архивация файловой базы слишком тривиальна, а клиент-серверной в одной статье не опишешь. Тем более, что делается это исключительно средствами СУБД.
(6) 13jaguar, можно уточнить точное местоположение, где 1С об этом пишут.
(5) alsoftik, а для кого же еще !!!!!
(7) Юрий ЛЛ, я лично где-то читал, могу и ошибаться, возможно на ИТС есть. Там не то что не рекомендуют, там просто говориться, что правильнее на клиент серверных системах резервные копии делать средствами самой субд. Так как, если в базе данных вдруг окажется какая-то ошибка, которая не заметна во время работы, то в DT вы базу выгрузите, а вот обратно вы можете ее не загрузить !!!!!
Насчет, как такие ошибки находить и вовремя исправлять, это уже другой вопрос….
«Разработка и амнистирование» — это жесть…
(1) Тогда уж Преступление, наказание и амнистирование.
Видимо, сама разработка — преступление, потом где-то вне зоны действия ИТС — наказание, а уж потом — амнистирование…
ну или для кого-то разработка — это уже наказание…
(7) Юрий ЛЛ, хороший вопрос по существу. Не буду перечислять все ссылки, приведу одну. «Руководство администратора», 2009, стр.94. Там указано, что «Этот механизм предназначен прежде всего для получения образа информационной базы независимо от способа хранения данных. Иногда этот режим используют также для создания резервной копии информационной базы, однако такой вариант его использования обладает рядом недостатков.» Эта фраза в различных модификациях можно найти в большинстве руководств, как администратора, так и пользователя. Правильный же способ архивного копирования приведен чуть дальше, на стр.95 вышеупомянутого руководства.
К сожалению, ни в одном руководстве не указано, что есть ненулевая вероятность невозможности корректного восстановления информационной базы из файла *.dt вследствие того, что при записи в этот файл происходит сжатие информационной базы с преобразованием к промежуточному формату (сжатие с потерями!), причем протокол и формат сжатия не документированы. Попробуйте сжать файл *.dt любым архиватором и легко в этом убедитесь. Лично я дважды сталкивался с такой проблемой. Как правило, это может происходить, если выгрузка производилась одним релизом платформы (старым), а загрузка другим. Поэтому в более новом руководстве 1С настоятельно рекомендует использовать режим выгрузки в файл исключительно для переноса информационной базы из файлового в клиент-серверный вариант. Кроме того, сжатие с потерями предполагает, что информационная база абсолютно свободна от ошибок, в противном случае загрузка может оказаться невозможной. Следует понимать, что исходный файл ИБ и восстановленный через *.dt — это РАЗЛИЧНЫЕ файлы! Об этом же неоднократно говорят в Продвинутом курсе программирования Фарита Насипова.
Учитывая вышеизложенное, для архивного копирования файловой ИБ можно использовать только 1 вариант (копирование файла 1cv8.1CD) как напрямую, так и с помощью специализированных программ. Однако, я не рекомендовал бы это доверять бухам. У них своей работы хватает.
(10) 13jaguar, у Вас немного неточное представление о механизме сжатия базы в .dt
само сжатие данных идёт без потерь (deflate), но сжимается не первоначальный файл БД (.1CD для файловой БД, например), а идёт считывание данных всех таблиц, и уже эти считанные данные в промежуточном формате хранения потом сжимаются.
в итоге, если файл БД не содержал физических ошибок, то сжатие получается без потерь (в данном контексте имеется в виду: без потерь значимой информации БД), плюс устраняется избыточность данных, почти всегда имеющаяся в хранящемся на диске файле БД.
если же файл БД содержит ошибки — тут начинаются нюансы. например, испорчен заголовок некоторой таблицы, но само содержимое этой таблицы физически остаётся в определённом месте файла. в таком случае, имея исходный .1CD, можно попробовать восстановить эту таблицу. если же был процесс выгрузки в .dt — то всё, таблица не считалась, поэтому ни следа её данных в файле выгрузки, естественно, не будет
(11) andrewks, согласен. Именно так. Но, применительно к данной теме, мы ведь должны получить гарантированно точную копию ИБ, а в случае выгрузки-загрузки через .dt, этого сделать в общем случае нельзя. Впрочем, Вы как раз и описали механизм сжатия с потерями. Просто, в случае если ИБ удовлетворяет некоторым условиям (не содержит ошибок) указанные потери не являются существенными. База остается работоспособной, но это уже другая база… И, как правило, исходного .1CD на момент обнаружения ошибки уже нет. Разве что, если его специально скопировали в архив непосредственно перед выгрузкой в .dt…
(12) 13jaguar,
база та же самая, файл базы другой.
тут нужно разделять понятия «содержимое ИБ» и «содержимое файла ИБ»
выгрузка обеспечивает сжатие содержимого ИБ без потерь в случае, если в структуре файла ИБ нет физических ошибок
в случае же с содержимым файла ИБ, конечно, выгрузка делает сжатие с потерями в любом случае, однако надо помнить, что не вся информация файла ИБ есть информация ИБ
(13) andrewks, правильно. Согласен.
Резервное копирование заезженная тема, поэтому в статью не мешало бы добавить другие шаги на пути к жизни «без головной боли невосстановимых бэкапов» (хранение копии в другом здании/месте, обязательную проверку резервной копии и т.п.)
У меня был случай, когда резервные копии ушли вместе с рабочей базой при краже всех компьютеров фирмы 🙂
Яндекс диск вам в помощь!
(15) andr_andrey, Или Яндекс-диск, или внешний жесткий диск? Чем мешают?