В дополнении к посту от Оптимизайка, после создания туннеля в putty необходимо использовать соксификатор, например Proxifier. И пустить весь трафик через туннель.
admak: У нас это решалось разделением прав доступа и бюрократией(в электронном виде),
Я вам про одно, вы мне про другое, думаю вы не поняли мысль, которую я пытался вам донести.
Перечитайте цитату. Как ваше разделение полномочий помогло бы в данной ситуации?
1с не зависла бы во время обновления?
Но да, в целом с идеей разделения согласен. у нас доступ к обновлению тоже имеет только 2 человека.
admak: БД - только на аппаратных рейдах. Я еще застал несколько серверов-старичков на которых диски периодически выпадали из рейда или дохли, покупали новые(или выдергивали из соседнего сервера), меняли, фоновый ребилд и так до следующего раза. Потерь данных при таких операциях не было ни разу.
И что, наличие рейда на 100% гарантирует сохранность БД ?
Я вот знаю одних ребят, они тоже считают, что с их дорогим ноутбуком (там БД в файловом варианте) ничего случится не может
И резервными копиями они не заморачиваются.
Подведем итог. admak, у вас в той фирме используется простая или полная модель восстановления?
---------- Добавлено 17.08.2017 в 07:54 ----------
У меня с вами разные взгляды на ситуацию.
Вы смотрите и думаете, что и как сделать, для сведения к минимуму форс-мажорных ситуаций.
Что конечно очень важно.
А я думаю как правильно настроить резервное копирование, что бы максимально быстро и просто восстановить работы БД, если форс-мажор всё-таки наступил.
И мне, как человеку который будет поднимать БД, не важно человеческий фактор (чей то косяк) привел к аварии или сбой в железе. Главное я восстановлю за 15-20 минут без потери данных.
Вот о чем я. И именно по этому я совету модель full.
admak: тут другой вопрос, почему кто то способный накосячить имеет доступ к конфигуратору?
А причем тут "кто то", тут самих 1Сков хватает.
Не могу назвать дату, но года 2 назад 1Сники выпустили обновление ЗУП 2,5 ( и при определенных условиях, а именно наличия каких-то проводок) обновление конфигурации приводило к полной не работоспособности конфигурации.
Был случай, 1С зависла на ровном месте, в момент обновления.
Благодаря полной модели восстановления, я откатывал за минуту до начала обновления. Не утруждая себя полными бэкапами которые весят значительно больше 1,3ГБ.
лучше лечить причину, а не следствия
Если сможете вылечить причину (кудрявые руки разработчиков 1С), то с меня ящик пива.
Для справки, грохнуться база может по разным причинам, а не только в момент обновления, например помрет диск на котором она расположена, да мало ли чего.
При модели simple - восстановление только с того момента как создана.
При модели full - позволяет восстановить на нужный момент времени (благодаря логам которые автор делает через каждые 15 мин), при условии, что бэкап и база хранятся на разных дисках, а еще лучше на разных машинах. (ну это прописная истина)
И самое главное в полной модели есть возможность доставки журналов если вы понимаете о чем я.
Спасательный круг на случай если сервер БД решит прилечь и откажется просыпаться.
Каждый сам выбирает, что ему важнее , скорость и простота бэкапирования или надежность.
admak: по времени у ТС это занимает 20 секунд и дальше крутите, что хотите.
Значит лог выполнится за пару секунд, а может быстрее.
Кроме того, со временем база разрастется и к этому вопросу придется вернуться.
Четверьг: Когда его создаешь с нуля, то он вообще 1,3 гб, но уже через несколько дней 4,5.
А вы измените
BACKUP DATABASE [ЙЙЙЙ] TO DISK = N'D:\MSSQL\Backup\ЙЙЙ' WITH RETAINDAYS = 14, NOFORMAT, INIT
Тем самым Ваш файл с бэкапом будет перезаписываться.
Лично я усечение (shrink) базы не практикую, зачем мне лишняя фрагментация... Глядишь нагрузка на диски снизится...
Кроме того, если и регулярно бэкапить логи транзакци, то файл логов при Вашем размере базы сильно не разрастется. И переживать об этом не стоит.
Ставить режим simple для базы 1с, не самая лучшая идея, мало ли кто то сильно накосячит (особенно в конфигураторе) и нужно будет откатить базу на некоторое время назад (например 15 минут), а в режиме simple это не возможно (толь восстановление на момент создание полного бэкапа).
redfox1986: На хостинге не заводил почту, но вот завел почту info@domin.ru и отправил письмо и оно пришло! но не хотелось бы зависит от внутреней почты хостера а слать все на сам яндекс почту для домена.
А где зависимость от хостера?
Почта будет идти туда, куда указывает MX (в данном случае это яндекс), и не важно где вы еще создадите ящики (на маил.ру, гугле, у другого хостера).
А ящик нужен для корректной работы почтовика, что и пытался вам донести miketomlin,
Есть физический сервер, надо туда кидать. Изучаем rsync для винды
Вопрос еще актуальный?
Если да, то cwrsync (это rsync для винды) https://ru.wikipedia.org/wiki/CwRsync
Можно использовать pac файл.
https://securelist.ru/pac-fajl-avtokonfiguratsii-problem/242/
Или использовать https://www.proxifier.com/
В дополнении к посту от Оптимизайка, после создания туннеля в putty необходимо использовать соксификатор, например Proxifier. И пустить весь трафик через туннель.
Из крупных проектов, у которого две версии сайта, знаю только 4pda.
Еще есть banki.ru. У них тоже 2 версии.
У нас это решалось разделением прав доступа и бюрократией(в электронном виде),
Я вам про одно, вы мне про другое, думаю вы не поняли мысль, которую я пытался вам донести.
Перечитайте цитату. Как ваше разделение полномочий помогло бы в данной ситуации?
1с не зависла бы во время обновления?
Но да, в целом с идеей разделения согласен. у нас доступ к обновлению тоже имеет только 2 человека.
БД - только на аппаратных рейдах. Я еще застал несколько серверов-старичков на которых диски периодически выпадали из рейда или дохли, покупали новые(или выдергивали из соседнего сервера), меняли, фоновый ребилд и так до следующего раза. Потерь данных при таких операциях не было ни разу.
И что, наличие рейда на 100% гарантирует сохранность БД ?
Я вот знаю одних ребят, они тоже считают, что с их дорогим ноутбуком (там БД в файловом варианте) ничего случится не может
И резервными копиями они не заморачиваются.
Подведем итог. admak, у вас в той фирме используется простая или полная модель восстановления?
---------- Добавлено 17.08.2017 в 07:54 ----------
У меня с вами разные взгляды на ситуацию.
Вы смотрите и думаете, что и как сделать, для сведения к минимуму форс-мажорных ситуаций.
Что конечно очень важно.
А я думаю как правильно настроить резервное копирование, что бы максимально быстро и просто восстановить работы БД, если форс-мажор всё-таки наступил.
И мне, как человеку который будет поднимать БД, не важно человеческий фактор (чей то косяк) привел к аварии или сбой в железе. Главное я восстановлю за 15-20 минут без потери данных.
Вот о чем я. И именно по этому я совету модель full.
А у меня же вроде и поставлено перезаписываться через 14 дней?
За 14 дней ваш Бэкапфайл разрастется (14 полных бекапов + логи), а так каждый день - новый файл.
Дык чего в итоге? Полный + журнал будет оптимальным?
Я бы выбрал его. Но если рост базы не ожидается и не потребуется преимуществ полной модели, то можно выбрать простую модель.
тут другой вопрос, почему кто то способный накосячить имеет доступ к конфигуратору?
А причем тут "кто то", тут самих 1Сков хватает.
Не могу назвать дату, но года 2 назад 1Сники выпустили обновление ЗУП 2,5 ( и при определенных условиях, а именно наличия каких-то проводок) обновление конфигурации приводило к полной не работоспособности конфигурации.
Был случай, 1С зависла на ровном месте, в момент обновления.
Благодаря полной модели восстановления, я откатывал за минуту до начала обновления. Не утруждая себя полными бэкапами которые весят значительно больше 1,3ГБ.
Если сможете вылечить причину (кудрявые руки разработчиков 1С), то с меня ящик пива.
Для справки, грохнуться база может по разным причинам, а не только в момент обновления, например помрет диск на котором она расположена, да мало ли чего.
При модели simple - восстановление только с того момента как создана.
При модели full - позволяет восстановить на нужный момент времени (благодаря логам которые автор делает через каждые 15 мин), при условии, что бэкап и база хранятся на разных дисках, а еще лучше на разных машинах. (ну это прописная истина)
И самое главное в полной модели есть возможность доставки журналов если вы понимаете о чем я.
Спасательный круг на случай если сервер БД решит прилечь и откажется просыпаться.
Каждый сам выбирает, что ему важнее , скорость и простота бэкапирования или надежность.
по времени у ТС это занимает 20 секунд и дальше крутите, что хотите.
Значит лог выполнится за пару секунд, а может быстрее.
Кроме того, со временем база разрастется и к этому вопросу придется вернуться.
Когда его создаешь с нуля, то он вообще 1,3 гб, но уже через несколько дней 4,5.
А вы измените
Тем самым Ваш файл с бэкапом будет перезаписываться.
Лично я усечение (shrink) базы не практикую, зачем мне лишняя фрагментация... Глядишь нагрузка на диски снизится...
Кроме того, если и регулярно бэкапить логи транзакци, то файл логов при Вашем размере базы сильно не разрастется. И переживать об этом не стоит.
Ставить режим simple для базы 1с, не самая лучшая идея, мало ли кто то сильно накосячит (особенно в конфигураторе) и нужно будет откатить базу на некоторое время назад (например 15 минут), а в режиме simple это не возможно (толь восстановление на момент создание полного бэкапа).
Понятное дело, что свой код в HTTPS сайт провайдер пока еще встроить не может
Зато некоторые левые плагины (читать вирусы) могут.
Все работает у них просто - вставляют JS файл: http://wn.netbynet.ru/wn.js?v=1
Именно для этого и нужен CSP.
На хостинге не заводил почту, но вот завел почту info@domin.ru и отправил письмо и оно пришло! но не хотелось бы зависит от внутреней почты хостера а слать все на сам яндекс почту для домена.
А где зависимость от хостера?
Почта будет идти туда, куда указывает MX (в данном случае это яндекс), и не важно где вы еще создадите ящики (на маил.ру, гугле, у другого хостера).
А ящик нужен для корректной работы почтовика, что и пытался вам донести miketomlin,