Рекомендации по организации резервного копирования для систем с Windows Server / Windows SQL Server

Публикация № 554112

Администрирование - Администрирование данных 1С - Архивирование (backup)

backup sql резервные копии дедупликация

В данной статье мы рассмотрим работу с резервными копиями базы данных 1С, а также некоторые приемы, оптимизирующие работу с резервными копиями.

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

Я думаю, что агитировать читающих данную статью за создание копий не следует, поэтому расскажу о том, какой метод создания резервных копий я использую.

 Место хранения. 

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

Следующий вариант - другой логический диск на том же физическом. Этот вариант имеет смысл рассматривать всерьез только в очень бюджетных инсталляциях - когда, например, используется мини-сервер 1С на 5 подключений, а база занимает до 1 гигабайта. В таком случае можно хранить резервные копии в отдельном разделе, только следует делать копии еще и в какое-нибудь облачное хранилище. Какое - каждый может определить для себя сам. Самые популярные варианты - Яндекс диск и Google Drive. Они дают небольшое количество гигабайт под хранилище, но удаленные файлы складывают в корзину, поэтому время от времени процесс фактического сохранения данных в облаке требуется проверять. Иначе после аварии может оказаться, что весь объем хранилища занят находящимися в корзине резервными копиями месячной и более давности, в результате чего самая свежая копия у нас только за прошлый месяц. Если же размер файлов резервных копий не позволяет нам держать в облаке все резервные копии - рекомендую определиться с определением того, за какой период времени мы можем позволить себе потерять данные. Может быть, нас устроит еженедельная копия. В таком случае стоит создать дополнительный каталог для резервных копий, и уже этот каталог синхронизировать с облачным хранилищем.  Если вам не хватает емкости облачных сервисов в бесплатном варианте - то либо вы переоцениваете собственные данные, либо вам все-таки стоит раскошелиться на отдельный жесткий диск.

Более продвинутый вариант - использование дополнительного жесткого диска. Если у вас есть 2 жестких диска, особенно если они одинаковые, может возникнуть желание объединить их в RAID1 (зеркало). А уже полученный том разбить на 2 части - для базы и для резервных копий. Но, на мой взгляд, в случае выхода данного RAID-массива может возникнуть проблема к доступу к любому логическому диску, в результате чего мы потеряем и данные, и копии. Поэтому разносим данные и копии по физическим дискам. В отличие от вышерассмотренного варианта, у нас сохраняется информация в случае выхода из строя любого из дисков, а возможная потеря данных уменьшена до времени между 2 копиями.

Отдельно отмечу тот факт, что на серверах, которые представляют собой уже настоящий сервер, достаточно часто встречаются аппаратные RAID-контроллеры, к которым подключено достаточно большое количество физических жестких дисков. В таком случае RAID массив обычно нарезают на логические диски. У администраторов может возникнуть желание выделить в таком массиве раздел под хранение резервных копий. И даже его зазеркалить. Но надо учитывать тот факт, что из строя может выйти сам RAID-контроллер. И как тогда с него списать данные? Конечно, данные (пока еще) не пропали, но доступ к ним сильно затруднен. Возьмите средней руки администратора, который больше  программист-администратор 1С, чем системный администратор. Вполне вероятно, что при попытке получения данных с сервера с неисправным RAID-контроллером он или окончательно разрушит данные, или же процесс восстановления данных затянется до неприемлемых сроков. "Слава богу, что такие контроллеры еще есть на рынке, мы сегодня получим счет на новый контроллер, завтра его оплатим, и к концу недели он будет у нас" - вариант рабочий, но долгий. Поэтому я считаю, что доступ к резервным копиям должен быть как можно более простым - допустимо хранить их на выделенном диске, подключенном к обычному SATA контроллеру, чтобы в случае проблем достаточно было подключить диск к другому компьютеру / серверу и считать данные.

Сам же я использую еще более усложненный вариант. Современные серверные версии Windows позволяют подключать сетевые диски по протоколу iSCSI и работать с ними как с обычными физическим - то есть создавать тома, форматировать их и т.д. С точки зрения операционной системы они выглядят именно физическими дисками. Поэтому если в организации есть сервер для хранения резервных копий - если он поддерживает данный функционал, то рекомендую им воспользоваться. В случае выхода из строя основного сервера, можно подключить это iSCSI диск  к другому серверу за считанные минуты, в результате период простоя пользователей может быть минимальным.

Составление циклов

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

Конечно, только вы знаете особенности работы вашего сервера 1С и требования к сохранности данных. Сервер может как использоваться круглосуточно, так и использоваться 5 дней в неделю с 8 до 17. В любом случае можно дать общие советы по организации расписания резервного копирования.

2 основных типа создания резервных копий  - это журнал транзакций и полная копия. В журнал транзакций включаются данные, которые изменялись с момента снятия предыдущей копии. Копии журнала транзакции не являются накопительными - если мы сделали полную копию в 12 часов ночи, а потом каждый час делаем копию журнала транзакций - чтобы восстановить базу на 12 часов дня нам потребуется восстановить полную копию и 12 журналов транзакций.  Но мы можем восстановить базу на любой момент времени, который входит в данный промежуток. Так, например, если в силу каких-то причин нам надо восстановить базу по состоянию на 6:28, мы можем восстановить базу из полной копии, последовательно накатить журналы транзакции и прийти к нужной временнОй точке. MS Management Studio позволяет прямо выбрать требуемый момент времени, после чего определяет список требуемых для восстановления журналов.

Полная копия базы данных представляет собой полную копию на момент времени. Она не позволяет восстановить данные на любой период времени, но она самодостаточна - если у нас есть файл полной копии, нам больше ничего не надо.

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

А теперь рассмотрим эту схему поподробнее.

Я использую следующие уровни:

1.  час

2. день

3. неделя

4 месяц

5 квартал

6 год

Если максимальный период возможной потери данных небольшой - допустим, полчаса-час, то в базе однозначно требуется включить  полную модель восстановления и делать резервные копии журналов с заданной частотой. Это у нас резервные копии уровня 1. на данном уровне мы только делаем резервные копии журналов, ничего не очищаем. Обычно копии журнала транзакций имеют расширение trn.  Если предприятие работает не круглосуточно, то копии журнала можно делать ежечасно, но только в рабочее время, захватывая по 1-2 часа до и после рабочего времени. Хотя в очередной раз повторю, что выбор частоты создания копий зависит от специфики работы предприятия и определяется самим администратором.

Ежедневные копии (уровень 2) делаются каждый день, в часы наименьшей загруженности, в формате полной копии. Если по выходным предприятие не работает, вполне нормально делать копии только по субботам, а воскресенье оставить для других заданий. А если сервер выключается на выходные или на ночь - то копии надо делать в обеденный перерыв или другие малонагруженный период времени. Для ежедневных копий вполне нормально оставить стандартное расширение для копий - bak. После создания самой копии, в случае успешного ее окончания, настроена очистка для файлов резервных копий первого уровня - файлов trn - старше 2 суток. Таким образом, за последние 2 суток мы можем восстановить базу на, практически, любой момент времени.

Еженедельные копии (уровень 3) мы делаем либо в определенный день недели, например, воскресенье. Только надо внимательно смотреть, чтобы разные задания не пересекались. А если они приходятся на один день - запускать их в разное время. Для копий данного уровня мы устанавливаем расширение week и очищаем ежедневные копии старше 2 недель.

Ежемесячные (уровень 4) настраиваются аналогично, только запускаются они раз в месяц, файлы имеют расширение month и очищаем предыдущие копии старше 3 месяцев. Рекомендую запускать задание не в конкретное число, а в конкретный день недели, например, первое воскресенье месяца.

Квартальные и годовые копии можно создавать по желанию. У меня квартальные копии имеют расширение quartal и очищаются ежемесячные копии старше 2 кварталов (6 месяцев), а годовые копии имеют расширение year и очищают квартальные копии старше 2 лет.

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

Некоторые трюки.

Место на сервере резиновым не является, поэтому мы можем использовать некоторые трюки для оптимизации места под хранение данных. В Windows Server 2012 появилась новая функция, под названием дедупликация. Что это такое? Рассмотрим обычный вариант - пользователи хранят в своей папке на сервере, к примеру, телефонный справочник. У большинства из пользователей справочник будет одинаковым, но каждый из них будет занимать место. Дедупликация в Windows - это специальный сервис, который запускается время от времени, анализирует новые и измененные файлы, ищет в них одинаковые части, в результате чего на диске оставляет общее содержимое в 1 экземпляре, а остальное возвращает операционной системе в качестве свободного места. Алгоритмы Windows достаточно продвинутые, позволяют анализировать файлы не только целиком, но и частями. В результате чего при использовании дедупликации мы можем сэкономить достаточное количество свободного места. Для того, чтобы воспользоваться данной функцией, следует установить компонент Windows "Дедупликация данных", и включить ее для тома с резервными копиями. Если вы хотите заранее оценить эффект от дедупликации - можете скачать программу ddpeval с сайта Microsoft, запустить ее для выбранного диска или каталога, и программа проанализирует и сообщит, сколько места можно освободить в результате дедупликации.

Следующий момент, связанный с дедупликацией данных - если вы решите ее использовать - рекомендую отключить сжатие резервных копий (кроме журнала транзакций). Это связано с тем, что сжатые в архив файлы с небольшими изменениями в исходных данных могут дать практически несовпадающие архивы. Поэтому сжатые архивы плохо дедуплицируются. А так как резервные копии содержат много одинаковой информации, файлы с этими копиямы должны прекрасно дедуплицироваться. Так, например, у меня на одном из серверов базы данных на диске емкостью 2048 Гб хранятся резервные копии объемом 440 Гб и свободно еще 2009 Гб. То есть 440 Гб физически занимают 39 Гб, то есть дедуплицированы практически в 11 раз.

Однако есть и некоторые ограничения. Дедуплицированные диски можно подключать только к компьютерам с операционной системой, их поддерживающей. В противном случае мы рискуем разрушить данные на диске и вместо восстановления потерять их. Так что рекомендую держать если не сервер под горячую замену, так хотя бы виртуальную машину с установленной Windows 2012 и включенной дедупликацией. Это позволит в случае аварии запустить виртуальную машину, дать ей доступ к физическому диску с копиями или же к iSCSI хранилищу и спокойно списать требуемые копии.

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

Имейте план восстановления! Вы можете в целом представлять что и как делать при восстановлении, но в ответственный момент вы можете что-нибудь перепутать и уже безвозвратно потерять данные. Или вы можете быть в отпуске или недоступны.

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

Специальные предложения

Вознаграждение за ответ
Показать полностью
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. asved.ru 35 12.10.16 08:27 Сейчас в теме
2 основных типа создания резервных копий - это журнал транзакций и полная копия. В журнал транзакций включаются данные, которые изменялись с момента снятия предыдущей копии


Вот этот абзац читать не надо. Лучше поищите нормальную статью про режимы и типы резервных копий MSSQL.
4. Zebar 64 12.10.16 14:12 Сейчас в теме
(1) Антон, можете рассказать, что именно принципиально неправильного я написал? Я не спорю, что специализированная статья по резервному копированию на MS SQL будет лучше, глубже и т.д. Но человеку, который переходит с файлового варианта на SQL обозначенные понятия будут достаточны, чтобы в общих чертах разобраться.
6. asved.ru 35 13.10.16 06:22 Сейчас в теме
(4) начать хотя бы с того, что журнал транзакций не содержит никаких "измененных данных", а содержит информацию об изменениях данных, достаточную для повтора этих изменений.
Кроме того, в simple режиме это не работает. А из full схемы явно вытекает log shipping для поддержки актуальной копии на удаленной площадке, про который следовало бы упомянуть.
Кроме того, Вы забыли (или не знали? ;)) про дифференциальный бэкап и про copy_only.
8. Zebar 64 13.10.16 09:32 Сейчас в теме
(6) Про типы резервного копирования diff и copy_only не забыл. Еще раз - специальная статья по типам резервного копирования будет лучше. Я поставил себе задачу в упрощенном виде рассказать про основные вещи для резервного копирования. И я рассказал о своем опыте, который построен на этих 2 типах.
Насчет full mode для журнала транзакций - у меня это упоминается в неявном виде: "Если максимальный период возможной потери данных небольшой - допустим, полчаса-час, то в базе однозначно требуется включить полную модель восстановления и делать резервные копии журналов с заданной частотой"
Про лог shipping - сталкивался с этим вне пределов 1С, никакого мнения пока не имею, так как у меня нет информации по изменению производительности в схеме быстрый сервер -> медленный сервер


2. Dragonim 127 12.10.16 08:36 Сейчас в теме
Не статья, а сборище мифов о резервном копировании.

1. Диски объединённые в рейд массив необходимо рассматривать как один (без разнице какой рейд используется), а следовательно применяются все те же правила что и для одного физического диска.
2. Делать резервные копии на ещё один физический диск (не логический) установленный в том же сервере имеет смысл, т.к. бекап на этот диск будет делаться намного быстрее чем по обычной сети, аналогично будет делаться быстрее восстановление.
3. В идеальном случае полные бекапы должны быть в трёх копиях, первая хранится на том же сервере на другом физическом диске, вторая в быстрой сети (обычно не далеко от самого сервера для более быстрого доступа), третья находится в другой местности, т.е. очень далеко от сервера. Чаще всего пренебрегают хранить копию на том же сервере на другом физическом диске, т.к. современные сети очень быстрые и/или понятие сервер и его физические диски размыто в современной компьютерной инфраструктуре.
4. Не используйте дедубликацию для бекапов, т.к. вы теряете контроль за самими бекапами и возрастает вероятность потери. Лучше задайте себе вопрос "Зачем мне так много копий базы?" и ответом на этот вопрос сохраните место.
5. Бекапы журналов транзакций это отдельная большая тема. При активном использовании 1С журналы транзакций растут как грибы, а откат больше чем на 1 сутки очень редкое явление, не говоря уже о скорости восстановления из журналов транзакций.
6. Не сказано не слово о самом главном, о тестировании созданных резервных копий. Само по себе резервное копирование это успокоение нервов админа, только проверив возможность восстановления базы из резервной копии можно говорить о сделанной работе.
3. Zebar 64 12.10.16 14:09 Сейчас в теме
(2). 1. Диски рассматриваются как один, но это пока у вас массив не развалился. Если у вас RAID из 10 дисков и контроллер сдох - что вы будете делать со своим массивом?
2. Почти не спорю. Только скорость обычного SATA диска - 100-150 MBps, а гигабит - дает около 100 Mbps. Так что по скорости, если приемник для бэкапов не тормозит, это все сравнимо.
4. А можете обосновать, почему при использовании дедупликации возрастает вероятность потери?
5. Соглашусь. Поэтому и пишу про их удаление через 2 дня. Почему через 2, а не через 1? Случаи разные бывают. Если место позволяет - можно и больше.
6. Да, наверное, надо было добавить. Но это совсем уже общее место.
5. Dragonim 127 12.10.16 15:11 Сейчас в теме
(3)

1. Я хотел сказать что все ваши абзацы про рейд можно заменить одной фразой "С точки зрения резервного копирования данных любой рейд массив надо рассматривать как один физический диск и применять к нему все те правила которые вы бы применили при резервном копировании на физический диск".
4. Во-первых, вы сами написали "Дедуплицированные диски можно подключать только к компьютерам с операционной системой, их поддерживающей. В противном случае мы рискуем разрушить данные на диске и вместо восстановления потерять их.", а это уже значит что идея хранить тут бекапы плоха, т.к. не факт что восстанавливать данные будете именно вы, не факт что в этот момент вы будете трезвы, не факт что вы вспомните про такую особенность, не факт что у вас имеется подходящая система под рукой чтобы быстро развернуть бекапы. Есть такое правило: "Если существует малейшая возможность совершить ошибку при востановлении данных, то она будет совершена", в вашем случае ошибок можно совершить множество. Во-вторых, если у вас попадётся битый сектор, то будут потеряны все бекапы, а не один. В-третьих, я не встречал ещё не одной системы в которой бы простое "посидеть и подумать о давности бекапах" не приводило бы к их сокращению до приделов существующего пространства, если вы исключение, то пойдите и купите ещё 1 диск, это точно надёжнее чем дедубликация.
6. Это самое интересное место. Бекапы научились делать многие, а вот проверять возможность восстановить данные из сделаных бекапов за отведённое время со 100% результатом, единицы.
7. v3rter 13.10.16 08:12 Сейчас в теме
Считаю, что на фоне всеобщей бэкапной безграмотности статьи об архивации надо выкладывать еженедельно, чтобы начинающие админы и пользователи не расслаблялись )

Например: "Резервное копирование 1С средствами MS SQL" http://infostart.ru/public/173494/

У меня в качестве тестирования полного рабочего архива используется его загрузка на тестовую копию на резервном сервере.
Если выгрузка в dt происходит за разумное время, можно использовать ее как дополнительную меру архивации.
В качестве заданий на недельные, месячные, квартальные и годовые архивы я бы использовал "художественное" переименование соответствующий ежедневных, недельных и т.д.
9. Zebar 64 13.10.16 09:39 Сейчас в теме
(7) Роберт! Насколько я помню, по заявлению самой 1С выгрузка в dt копией не является.
10. v3rter 13.10.16 10:36 Сейчас в теме
(9) разумеется не является. Но удобно, когда есть под рукой для тестовых и вспомогательных целей.
11. Zebar 64 13.10.16 13:58 Сейчас в теме
(10) Ну, так-то да. Просто мне проще копию восстановить как новую базу, и на сервере 1С ее зарегать.
Заодно и работоспособность копий тестируется.
AlexGroovy; +1 Ответить
Оставьте свое сообщение

См. также

Скрипт удобного восстановления базы MSSQL при дифференциальном резервировании Промо

Архивирование (backup) v7.7 v8 1cv8.cf 1cv7.md Россия Бесплатно (free)

Если у Вас база на MSSQL и Вы пользуетесь разностными бекапами, то, скорее всего, столкнулись с тем, что поднять базу/копию базы из имеющихся резервных файлов не столь удобно, как того хотелось бы. В этой статье приведен скрипт по теме.

20.01.2011    30713    Ivon    12    

Классическое резервное копирование

Архивирование (backup) v8 1cv8.cf Бесплатно (free)

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

04.02.2021    911    creatermc    10    

Управление конфигуратором в режиме агента с помощью python

Администрирование данных 1С Архивирование (backup) Скрипты автоматизации v8 1cv8.cf 1С:Франчайзи, автоматизация бизнеса Россия Бесплатно (free)

Управление конфигуратором 1С:Предприятие в режиме агента. Опыт применения с реализацией на языке python. Результат получен с использованием интерактивной сессии оболочки через invoke_shell().

06.08.2020    1406    Alex10166    2    

Выгрузка в dt на сервере 1С по расписанию с завершением соединений и подключением к консоли сервера через com

Архивирование (backup) Администрирование данных 1С v8 Россия Бесплатно (free)

Была задача настроить по расписанию выгрузку серверной базы в dt, готового решения не нашел, делюсь, может, кому пригодится.

16.04.2020    6505    karamazoff    47    

Восстановление SQL базы 1С 8.2. рухнувшей во время сохранения конфигурации. Промо

Тестирование и исправление Архивирование (backup) v8 1cv8.cf Россия Бесплатно (free)

При обновлении конфигурации вылетела 1С. После чего наотрез отказалась входить в базу. При этом в конфигураторе выдавалось сообщение "Внимание!!! При обновлении данных, после последней реструктуризации, произошла критическая ошибка. Повторить обновление?" Потом выходило сообщение "Обнаружена незавершённая операция сохранения конфигурации. Для продолжения необходимо завершить операцию". Горела кнопка Ок - на этом работоспособность конфигуратора и базы заканчивалась.

08.02.2012    131695    VanDiesel1    139    

Тонкая настройка ежедневного резервного копирования базы данных 1С средствами SQL ver. 2014 (SP3) - 12.0.6024.0 (X64)

Архивирование (backup) v8 Россия Бесплатно (free)

Хочу вам предложить небольшой пример, как можно реализовать резервное копирование 1С-ых баз данных средствами SQL. Данный материал не претендует на пулитцеровскую премию. Но возможно кому-то будет интересно узнать, что-то новенькое. Данный материал для резервного копирования только одной базы данных. А именно, если у вас 20-ть баз, то вам придется создавать 20-ть планов обслуживания для каждой базы индивидуально. (Слава разработчикам SQL, они разрешили копировать блоки из одного плана в другой, вам остается только произвести небольшую настройку для каждого скопированного блока - некоторые настройки блоков сбрасываются и выставляются значением по умолчанию и остаются неактивными)

07.10.2019    12328    DrZombi    49    

Быстрое копирование таблиц большого размера и/или с большим числом строк, на примере регистра сведений (для MS SQL)

Архивирование (backup) v8 Бесплатно (free)

Моментальное восстановление затертого регистра сведений из бекапа посредством SQL.

11.08.2019    6939    Zlohobbit    25    

Настройка резервного копирования (резервирования) баз данных 1С: Предприятие на MS SQL Server

Архивирование (backup) v8 1cv8.cf Россия Бесплатно (free)

Настройка резервного копирования (резервирования) баз данных на "бюджетной" версии 1С Предприятие под MS SQL Server. Используется пример MS SQL Server 2008 R2 под Windows. Для малых и средних предприятий, исключая производственные и торговые, так как тестирование на них не проводилось.

30.10.2018    12687    unclevad    16    

К вопросу об архивации баз 1С (и снова, и снова...) Промо

Архивирование (backup) v8 1cv8.cf Россия Бесплатно (free)

Из своего опыта хочу напомнить о самом простом способе архивации баз типовыми средствами 1С и планировщика Windows.

08.01.2010    26521    grum01    14    

Работа с конфигуратором по протоколу SSH (не в режиме агента)

Архивирование (backup) Администрирование данных 1С v8 Бесплатно (free)

Рабочее решение запуска пакетного скрипта конфигуратора 1С через SSH-клиента.

28.04.2018    10883    vsbronnikov    2    

Резервное копирование "онлайн" клиент-серверных баз в dt (не отключая пользователей)

Архивирование (backup) v8 Бесплатно (free)

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

03.10.2017    25199    konstanta_online    81    

Настройка зеркалирования базы для MS SQL

Архивирование (backup) Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Очень удобный способ, когда нам нужна не просто резервная копия, а "горячая" замена серверов.

19.05.2017    32282    MsDjuice    14    

Резервное копирование и восстановление базы 1С средствами PostgreSQL

Архивирование (backup) v8 Бесплатно (free)

Алгоритм резервного копирования баз 1С: 8 средствами PostgreSQL.

01.08.2016    72318    dimisa    35    

Как я восстанавливал разрушенную базу

Архивирование (backup) Распределенная БД (УРИБ, УРБД) Тестирование и исправление v8 1cv8.cf Бесплатно (free)

УТ10.3 на Платформе 8.2 на базе MSSQL была разрушена после попытки её восстановить после неудачного динамического обновления. Таблица Config целевой базы была заменена на содержимое таблицы Config от другой рабочей базы. Но на самом деле конфигурации у них существенно отличались, поэтому после таких действий целевая база рухнула окончательно. Что же делать?

21.08.2015    30101    METAL    25    

Просто и сердито. Архивирование (backup) типовых конфигураций 1С 8.2, 8.3

Архивирование (backup) v8 1cv8.cf Бесплатно (free)

После эксплуатации различных "бесплатных" обработок и скриптов решил написать свой cmd-файл для ежедневного архивирования баз 1С. Работает на конфигурациях, где есть процедуры "ЗавершитьРаботуПользователей" и "РазрешитьРаботуПользователей" (т.е. во всех типовых, в нетиповые данные модули можно скопировать из типовых). Сохраняет файлы как локально так и на удаленном файловом сервере. Автоматически удаляет старые архивы и копирует на удалённый сервер отсутствующие. Расписание задается установкой соответствующего задания (запуска cmd-файла по времени) в планировщике задач Windows. Для борьбы с зависшими сеансами, рекомендуется настроить в режиме конфигуратора параметры информационной базы: "Время засыпания пассивного сеанса" и "Время завершения спящего сеанса".

18.06.2015    18470    Prelude    14    

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

Архивирование (backup) Администрирование данных 1С v8 1cv8.cf Бесплатно (free)

В 1С:Предприятии 8.2 есть ограничение на выгрузку базы в формате DT. Выгрузить базу можно, только если в ней нет активных пользователей. В этой статье поделюсь способом, как обойти это ограничение и сделать невозможное.

16.09.2013    50677    yurega    55    

Восстановление SQL базы 1С 8.2. после неудачного сохранения конфигурации

Архивирование (backup) Администрирование данных 1С v8 Россия Бесплатно (free)

При динамическом обновлении, в процессе сохранения конфигурации, вылетела база 1С и отказалась заходить в режим Конфигуратора, выдавая сообщение "Внимание!!! При обновлении данных, после последней реструктуризации, произошла ошибка. Повторить обновление?", если ответить утвердительно, то появлялось сообщение "Обнаружена незавершенная операция сохранения конфигурации. Для продолжения работы необходимо завершить операцию.", после чего Конфигуратор закрывался.

18.07.2013    37116    lord_soth    45    

Резервное копирование 1С средствами MS SQL.

Архивирование (backup) v8 1cv8.cf Бесплатно (free)

В этой статье описано самое обычное резервное копирование ИБ 1С при помощи инструментов MS SQL Server 2008 R2, объяснено почему следует делать именно так, а не иначе, и развеяно несколько мифов.

17.02.2013    265576    speshuric    84    

Хранение удаленных документов в отдельной базе. Часть 1.

Администрирование данных 1С Архивирование (backup) v8 1cv8.cf Бесплатно (free)

Резервное хранение данных. Пример работы с внешними источниками данных. Работа с файлами. Подписка на событие. Работа с XML файлами. Сериализатор XDTO.

12.12.2012    16314    egorovntn    10    

Восстановление файловой версии базы данных *.1CD после ошибки динамического обновления.

Сервисные утилиты Архивирование (backup) Администрирование данных 1С Тестирование и исправление v8 1cv8.cf Бесплатно (free)

Восстановление работоспособности файл-серверной базы данных (файл *.1CD) после критической ошибки, возникшей в результате динамического обновления с последующим предупреждением "Внимание!!! При обновлении данных, после последней реструктуризации, произошла ошибка. Повторить обновление?".

02.10.2012    52206    djserega    78    

Автоматическое регулярное разворачивание оперативных бэкапов (совсем просто) в MS SQL 2008

Архивирование (backup) v7.7 v8 1cv8.cf 1cv7.md Россия Бесплатно (free)

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

10.08.2012    18670    sergiobargio1    6    

Регулярные оперативные копии рабочих баз 1С с помощью MS SQL 2008

Администрирование данных 1С Архивирование (backup) v8 1cv8.cf Россия Бесплатно (free)

В течение дня необходимо производить отладку "допилов" на свежих копия рабочих баз. Также необходимы актуальные копии и для экспериментов, в том числе и пользователям. На этом замечательном ресурсе есть много полезных публикаций с различными вариантами, как это сделать. В одном из них предлагается использовать инструмент мгновенных снимков баз, которые возможно выполнить только в версии Express Edition. В этом посте очень простой вариант, не требующий дорогостоящей версии MS SQL

01.08.2012    19277    sergiobargio1    8    

Пошаговая инструкция по процедуре восстановления базы SQL. SQL Server 2008

Архивирование (backup) Администрирование данных 1С v8 1cv8.cf Россия Бесплатно (free)

Пошаговая инструкция по по процедуре восстановления бэкапа SQL 2008.

23.07.2012    131667    Vint88    19    

Автоматизация создания резервных копий в MS SQL Express Server

Архивирование (backup) v8 1cv8.cf Россия Бесплатно (free)

В версии Microsoft SQL Server 2005/2008/2008R2 Express Edition серверах нет стандартных средств создания резервных копий баз данных по расписанию. Восполнить этот пробел поможет простое решение

18.06.2012    30631    LexSeIch    4    

Бэкап 1С:Предприятие 8.х

Архивирование (backup) v8 1cv8.cf Россия Бесплатно (free)

Рекомендации по резервному копированию. Бесплатные программы для бэкапа Egida Backup, Effector saver 3, xStarter.

09.11.2011    27422    sinjevla    10    

Резервное копирование чеков во внешние файлы и их восстановление

Архивирование (backup) v8 Розница Россия Бесплатно (free)

Решение проблемы восстановления потерянных кассовых чеков после восстановления поврежденной базы розницы.

21.10.2011    11425    elizarovs    3    

Архивное копирование 1С8 автоматически и ежедневно

Архивирование (backup) v8 1cv8.cf Россия Бесплатно (free)

Выложил ввиду "молодости и горячести" ХД и критики со стороны, дабы не спотыкаться в дальнейшем =)

19.04.2011    7761    AActor    15    

1С и Postgres: Бэкап

Архивирование (backup) v8 1cv8.cf Россия Бесплатно (free)

Для начала пару слов о том, зачем и когда он нужен. Ни для кого не секрет, что сервер это не просто компьютер, а надежный компьютер! Поэтому, если он не сломался в первую неделю после запуска, то не сломается еще очень долго. И поэтому у вас всегда есть возможность какое-то время оставаться вовсе без резервной копии

17.12.2010    22746    alexcid    5    

Выгрузка ИБ 1С8 на сервере 1С:Предприятие

Архивирование (backup) v8 1cv8.cf Россия Бесплатно (free)

Выгрузка ИБ 1С8 на сервере 1С:Предприятие стандартными средствами ОС и 1С. Без всяких хитростей.

25.10.2010    19848    daulberg    7    

Как выгрузить не всю конфигурацию в файл, а только изменения?

Архивирование (backup) v8 1cv8.cf Россия Бесплатно (free)

Хочу поделиться одним способом сохранения не всей конфигурации в файл, а только изменений. Способ довольно заморочный, но он позволяет сохранить любые изменения конфигурации в файл, размер которой уменьшится, скажем, к 300 KB, по сравнению с размером конфигурации в 60 MB. Этот способ эффективен, когда у клиента очень слабое соединение с интернетом или оплачивается помегабайтно.

19.02.2010    34490    modul    78    

Архивирование баз данных 1С и не только... (настройка бесплатной программы Cobian Backup 9)

Архивирование (backup) v7.7 v8 1cv8.cf 1cv7.md Россия Бесплатно (free)

В данной статье описывается создание системы архивирования на основе бесплатной программы Cobian Backup 9 (http://www.cobiansoft.com/cobianbackup.htm)

14.01.2010    62372    Mx00    146    

SQL2005. Выгружаем базу средствами 1С не выгоняя пользователей.

Архивирование (backup) v8 1cv8.cf Россия Бесплатно (free)

Очередной велосипед на тему архивации баз данных 1С средствами 1С.

21.09.2009    22725    IamAlexy    26