Комментарии 26
С литературной точки зрения, мне понравилось.
с оформительской точки зрения — все это надо немедленно отправить под кат!
НЛО прилетело и опубликовало эту надпись здесь
С технической точки зрения — пустовато.
Бэкап БД средствами sql: BACKUP DATABASE 1C TO DISK = @f WITH INIT, NAME = N'1C', SKIP, NOREWIND, NOUNLOAD, STATS = 10;
Бэкап БД средствами 1С: 1cv8.exe CONFIG %server% /N%login% /P%password% /DumpIB"%backup_path%1Cv8_%dd%_%hh%.dt" /Out%backup_path%Error_%dd%_%hh%.txt
Сдобрить переменными до полноценных скриптов, положить в планировщик, запускать по вкусу.
Средствами 1С я копию делаю раз в сутки и складываю в чемодан на черный день (для восстановления с нуля), а средствами БД — по мере надобности и держу на сервере БД для быстрого восстановления (хотя копия в чемодан тоже идёт).
Еще думаем (давно думаем :)) на счёт ежечасных копий БД, реализовать несложно, но пока не особо нужно.
Бэкап БД средствами 1С: 1cv8.exe CONFIG %server% /N%login% /P%password% /DumpIB"%backup_path%1Cv8_%dd%_%hh%.dt" /Out%backup_path%Error_%dd%_%hh%.txt
Сдобрить переменными до полноценных скриптов, положить в планировщик, запускать по вкусу.
Средствами 1С я копию делаю раз в сутки и складываю в чемодан на черный день (для восстановления с нуля), а средствами БД — по мере надобности и держу на сервере БД для быстрого восстановления (хотя копия в чемодан тоже идёт).
Еще думаем (давно думаем :)) на счёт ежечасных копий БД, реализовать несложно, но пока не особо нужно.
Я не спец, но мне 1Сники озвучили, что бэкап SQL 1С базы силами 1С (/dumpIB) — это плохо при нарушенной целостности. кстати, может кто подробнее подскажет, почему?
НЛО прилетело и опубликовало эту надпись здесь
Бэкап базы при нарушенной целостности всегда не слишком хорошо.
упс… забыл написать — «логической» целостности базы 1С (документы с левыми ID и т.п.). В этом случае, дамп силами SQL идет нормально.
НЛО прилетело и опубликовало эту надпись здесь
Если у вас проблемы в базе, то их надо решать, а не думать «а почему это оно у меня плохо бэкапится» и искать альтернативные способы.
У меня — НЕТ проблем в базе (надеюсь). А вот ЕСЛИ они возникнут, и ДО их исправления будет сделан бэкап через /DumpIB, шансов из него нормально восстановиться будет значительно меньше, чем из SQL дампа…
так мне вежливо объяснили.
так мне вежливо объяснили.
НЛО прилетело и опубликовало эту надпись здесь
Смысл дампов в том, что они штука самодостаточная и развертываются где угодно и кем угодно. Хоть на линуксе с postgres, хоть на винде с mssql, хоть в файловом режиме. Потому не делать их всё же нельзя.
Другое дело, что используются они довольно редко, а основная работа действительно идёт с бэкапами, сделанными средствами sql-сервера.
Другое дело, что используются они довольно редко, а основная работа действительно идёт с бэкапами, сделанными средствами sql-сервера.
Таки и я о том же
Так вставьте в скрипт бэкапа проверку базы. Какой-то там был ключ на тему /checkandrepair
Ого. Даже «Хоронитель V» тут затесался. Во времена моей работы в Гэндальфе я даже пытался реанимировать это существо — безрезультатно. Можно закапывать. Последние коммиты в него были сделаны, наверное, лет 10 назад уже и тайные знания о нем (как и о его оригинальных разработчиках) скрыты под тостым слоем пыли.
Удивительно, как Вы его, вообще, нашли.
Удивительно, как Вы его, вообще, нашли.
Я использую 2 варианта:
1. Бекап с помощью MSSQL (каждые 4 часа T-LOG в течении раб. дня и в конце дня полный, хранится 2 недели).
2. Ночью скрипт выгрузки в dt (нужно скорее для возможности передать дамп разработчикам либо для хранения долгих бекапов).
Скрипт писал сам, перед выгрузкой блокирует фоновые задания, блокирует возможность подключения, отключает сессии, так как если одно из них есть то выгрузка в dt не будет выполнена. Кстати под сервер 8.3 пришлось в скрипт добавить выбивание через объект консоли сервера, так как почему то не всегда срабатывал метод отключения через ИБ.
Часто по работе требуется разворачивать из бекапа тестовые базы, для этого обычно использую SQL бекап так как он работает быстрее чем из dt.
Зачем нужны все эти левые бекаперы — не пойму.
1. Бекап с помощью MSSQL (каждые 4 часа T-LOG в течении раб. дня и в конце дня полный, хранится 2 недели).
2. Ночью скрипт выгрузки в dt (нужно скорее для возможности передать дамп разработчикам либо для хранения долгих бекапов).
Скрипт писал сам, перед выгрузкой блокирует фоновые задания, блокирует возможность подключения, отключает сессии, так как если одно из них есть то выгрузка в dt не будет выполнена. Кстати под сервер 8.3 пришлось в скрипт добавить выбивание через объект консоли сервера, так как почему то не всегда срабатывал метод отключения через ИБ.
Часто по работе требуется разворачивать из бекапа тестовые базы, для этого обычно использую SQL бекап так как он работает быстрее чем из dt.
Зачем нужны все эти левые бекаперы — не пойму.
перед выгрузкой блокирует
Я просто делаю копию базы средствами sql (backup, restore), а потом выгружаю в dt эту копию. Возможно, правильнее было бы через снапшоты, но вторая полноценная копия базы иногда пригождается.
Зачем нужны все эти левые бекаперы — не пойму.
Должны же люди на жизнь зарабатывать. :)
Можете поделиться скриптом? Интересует в части отключения пользователей и блокировки фоновых заданий (сейчас столкнулся с необходимостью работы с 1с, разбираюсь что к чему).
Уважаемые комментаторы!
Начну с извинений; сбросив в пятницу пост, я ушёл из института на фотосессию в студии, которая продлилась (с перерывами на обеды и сон) все выходные. Поэтому ответить раньше не мог.
По содержательной части статьи: этот текст родился вслед за двумя чисто техническими обзорами программ бэкапа, один из которых я представил в дирекцию, а другой, с… гм… диаграммами и таблицами, намерен разместить через институтских админов на специалимзированных сайтах. Если его там пропустят, я непременно дам ссылку.
Этот же текст был изначально посвящён именно пользовательским впечатлениям, причём впечатлениям не простым. а сформировавшимся под влиянием нескольких лети тесного профессионального и личного общения с девушками-гуманитариями (вопреки известным заблуждениям, они прекрасно разбираются в Линуксе и могут сами сменить полетевший проц, но впечатлительность сохранили в полной мере!).
Вообще, я стараюсь держаться «публицистической» позиции, хотя на чисто техническом ресурсе это может быть воспринято неправильно. Но, по моему мнению, глазами пользователя профессионалу смотреть можно и нужно.
Вспоминаю в связи с этим анекдот из нашей институтской жизни: пригласили молодых девелоперов на подработку, надо было написать пакет для подавления шумов в записях из экспедиций (там шумы специфичные, отдельная утилита стоила своих мелких денег). Я сидел среди девелоперов и слушал, как они пудрят мозги. Потом встал тогдашний замдиректора и сказал: «Пишем на Intel Fortran, используем наши готовые наработки на основе пакета LINPACK!». Такой заявки в гуманитарном НИИ никто не ожидал. Такими вот бывают потребности пользователя.
Здесь я пытался оценить бэкаперы 1С с точки зрения приходящего админа, которому надо разобраться быстро-быстро и в 1С, и в SQL-совместимых СУБД, и что там с конфигурацией сети, и с пользовательскими файлами-папками напутано… У нас таких админов было четверо в разное время. Мы все знаем, сколько платят приходящему админу и сколько от него хотят :(, поэтому в выборе софта он, пожалуй, будет больше ориентироваться на соображения удобства и комфорта, чем на чисто технические параметры. Или напишет свой скрипт, если он упёртый «красноглазик» :). Но, например, бухгалтерша скрипт не напишет. Она будет ориентироваться только и исключительно на личные впечатления. А представления о том, что бухгалтерши не ходят на Хабр, глубоко устаревшее и ошибочное.
Относительно технических ошибок и огрехов оформления — я принял замечания к сведению и постараюсь исправиться. Но тут ещё прошу учесть, что бэкап для меня ассоциируется в первую очередь не с 1С, а с фотоархивами; с 1С я вынужден с некоторым отвращением иметь дело в институте, и всё. Поэтому буду внимательно прислушиваться к мнениям других пользователей. Всем спасибо за внимание!
Начну с извинений; сбросив в пятницу пост, я ушёл из института на фотосессию в студии, которая продлилась (с перерывами на обеды и сон) все выходные. Поэтому ответить раньше не мог.
По содержательной части статьи: этот текст родился вслед за двумя чисто техническими обзорами программ бэкапа, один из которых я представил в дирекцию, а другой, с… гм… диаграммами и таблицами, намерен разместить через институтских админов на специалимзированных сайтах. Если его там пропустят, я непременно дам ссылку.
Этот же текст был изначально посвящён именно пользовательским впечатлениям, причём впечатлениям не простым. а сформировавшимся под влиянием нескольких лети тесного профессионального и личного общения с девушками-гуманитариями (вопреки известным заблуждениям, они прекрасно разбираются в Линуксе и могут сами сменить полетевший проц, но впечатлительность сохранили в полной мере!).
Вообще, я стараюсь держаться «публицистической» позиции, хотя на чисто техническом ресурсе это может быть воспринято неправильно. Но, по моему мнению, глазами пользователя профессионалу смотреть можно и нужно.
Вспоминаю в связи с этим анекдот из нашей институтской жизни: пригласили молодых девелоперов на подработку, надо было написать пакет для подавления шумов в записях из экспедиций (там шумы специфичные, отдельная утилита стоила своих мелких денег). Я сидел среди девелоперов и слушал, как они пудрят мозги. Потом встал тогдашний замдиректора и сказал: «Пишем на Intel Fortran, используем наши готовые наработки на основе пакета LINPACK!». Такой заявки в гуманитарном НИИ никто не ожидал. Такими вот бывают потребности пользователя.
Здесь я пытался оценить бэкаперы 1С с точки зрения приходящего админа, которому надо разобраться быстро-быстро и в 1С, и в SQL-совместимых СУБД, и что там с конфигурацией сети, и с пользовательскими файлами-папками напутано… У нас таких админов было четверо в разное время. Мы все знаем, сколько платят приходящему админу и сколько от него хотят :(, поэтому в выборе софта он, пожалуй, будет больше ориентироваться на соображения удобства и комфорта, чем на чисто технические параметры. Или напишет свой скрипт, если он упёртый «красноглазик» :). Но, например, бухгалтерша скрипт не напишет. Она будет ориентироваться только и исключительно на личные впечатления. А представления о том, что бухгалтерши не ходят на Хабр, глубоко устаревшее и ошибочное.
Относительно технических ошибок и огрехов оформления — я принял замечания к сведению и постараюсь исправиться. Но тут ещё прошу учесть, что бэкап для меня ассоциируется в первую очередь не с 1С, а с фотоархивами; с 1С я вынужден с некоторым отвращением иметь дело в институте, и всё. Поэтому буду внимательно прислушиваться к мнениям других пользователей. Всем спасибо за внимание!
что то меня раздирает сомнения в написании текста админом у которого болит голова как сделать бекап 1С данных…
PS
может конечно я и ошибаюсь… Но текст и вправду как фэнтези…
PS
может конечно я и ошибаюсь… Но текст и вправду как фэнтези…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Бэкап 1С: Семь маленьких путешествий в поисках одной большой утилиты