Уважаемые специалисты, скажите пожалуйста, какие подводные камни есть у такого решения:

Рабочий сервер с трудом справляется с текущей работой, если на нём же сделать обновление базы, то он с трудом шуршит полтора дня (свободного времени-только ночь). Если рабочую базу выгрузить в DT и загрузить на другой, быстрый комп, провести там все процедуры обновления и вернуть через выгрузку DT назад - что может пойти не так? Регламентное задание обмена с бухгалтерией я приостановлю, а что будет с логом - будут ли видны старые события в обновленной базе? Велика ли вероятность порчи данных?

База файловая?

Нормально все будет при прямых руках. Что же это за сервер такой что обновление поставить не может. Как на нем работает все?

(1) на обоих серверах - клиент-сервер. Разница у компов только в железе, версии ОС и скуля.

(2) Старый сервер (т.е. и проц и память не фонтан для 1С), плюс все засунуто в виртуалку. Новый сервер в ближайших планах.

(3) если там скуль, то нафига тогда выгрузка в dt ?
Зачем этот изврат ?

И что загрузка из дт медленнее обновления?

(5) у меня прав на скуль нету на рабочем сервере (да и вообще админских прав там же), приходится извращаться.

+(7) да и версии у них разные - это же влияет? Или выгрузка у скуля как DT в 1С - универсальная?

(0) подними на своей тачке сервер 1С и обновляйся онлайн

(7) жесть какая, ну так, добудь их сам, сделай себя админом

(9) именно это я и делаю - меня интересует - что может потеряться / сломаться при этом - например данные и логи одинэсные.

(10) этот сервер на ладан дышит, не хочу за чужие глюки отвечать. Вот когда новый сервер настроят - попрошу.

(8) Не совсем. Зависит от того, какие версии скуля.

(11) А зачем тебе логи одинэсные?

+(13) Ну а данные могут сломаться, только если DT криво выгрузится/загрузится.

(11) у тебя там сервер еле дышит, а ты о логах паришься

(14) я не понимаю чего он боится, бекапы же ему никто не запрещал делать перед всем этим. Или сервер и бекапы не тянет?

(11) выгрузка тогда зачем?
Зарегай существующую  базу на сервере 1С локальной тачки. И обновляйся на здоровье. Нагрузка на sql сервера тут минимальна.
Для порядку на время обновления отключи регл. задания базы на сервере 1С дохлого сервака.

(16) Я тоже не понимаю, что его смущает.

(17) "Зарегай существующую  базу на сервере 1С локальной тачки" - Для этого надо дополнительный серверный ключик иметь :)

(19) его можно с остановленного сервера на дохлом сервачке взять (правда если он железный там)

(19) ТС говорит что у него уже сервант 1С уже поднят второй.

(15) это вопрос к админу, а не к одинэснику.

(16) бекапы я конечно делать буду, на каждом шаге, но мне в итоге нужны не бекапы с откатом, а успешное обновление

(18) смущает то, что я делаю это впервые в жизни.

(23) Стаж: 9 лет 6 месяцев 9 дней

и ты впервые обновляешь базу? ооооо

(24) я на 7.7 все это время сидел, а теперь осваиваю восьмерку в боевой обстановке. Обновление кстати у меня уже второе, но первое, которое затягивается больше чем на ночь.

(23) >>смущает то, что я делаю это впервые в жизни.
Все бывает в этой жизни в первый раз - первый шаг, первый поцелуй, первый секс...

Нет там ничо страшного, поставь скуль локально потренируйся.
Сделай бэкап и тут же его разверни.
Не получится - снеси все нах и попробуй еще раз.
Потом когда "на кошках потренируешься", сделаешь на рабочем серваке.

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

Была ситуация, когда при загрузке dt вылетела 1C. Пришлось удалять и поднимать новую базу.

Еще надо, чтобы платформы были одинаковые.

На логи 1С-ные все это никак не должно повлиять. Эти логи хранятся в файлах. Способы нахождения файлов легко можно найти в интернете.
У меня как-то раз логи гронулись. Был один огромный лог-файл. После этого я стал в больших базах данных ставить
Администрирование -> Настройка журнала регистрации -> Разделение журнала по периодам -> месяц
Теперь если даже грохнется лог-файл, то только за один месяц, а не все полностью.

Спасибо всем за конструктивные советы.

(26) тренировался и тренируюсь, но ведь невозможно проверить целостность всего, вдруг что поломалось, а внешне - как будто все на месте.

(27) выгрузку и загрузку DT я провожу регулярно - т.к. доступа к скулю на боевом нет, то чтобы не дергать админа - я для себя копии делаю через DT. Платформы одинаковые.

(28) извиняюсь - забыл уточнить, логи ведутся в sqlite формате - так уже было до меня и я пока не рискнул менять. Будут ли после переноса базы туда-сюда в логах видны старые события?

(29) >>но ведь невозможно проверить целостность всего, вдруг что поломалось
dt-шка тебя тоже от поломок никак не спасет.
Тут как раз sql-бэкап предпочтительней.
К рабочему серваку, по большому счету тебе и не нужен доступ - озадачиваешь одмина чтобы он тебе вечерком сделал бэкап, разворачиваешь его на своем серваке(ну или где там будешь обновлять), накатываешь обновление, делаешь бэкап и отдаешь его одмину, чтоб он развернул его на рабочем сервере и собственно все. Даже никакой ответственности с твоей стороны за рабочий сервер...

Небольшой вопрос вдогонку - скажите пожалуйста, почему при обновлении на всех этапах процессор съедается и скулем и рпхостом и 1С-кой, но при выполнении дополнительных процедур обработки данных - нагрузка на процессор нулевая, и диск не особо нагружен (при этом процесс тянется очень долго)?

А почему просто один раз не перенести базу со старого сервера на новый и работать/обновляться на новом сервере?

Юзерам же можно просто разослать инструкцию где какие буковки поменять