С одной из фирм стал работать удаленно.
База клиент-серверная, Постгрес. Бэкап базы под 30 Гб.
Дали доступ к этой базе через ВПН.
Перед внесениями изменений делать архив вообще не вариант, ждал выгрузку в dt на свой локальный 1.5 часа, так и не дождался. Попросил дать доступ к расшаренной папке, дали доступ через шлюз к общей папке, туда также выгрузка шла 1.5 часа, дальше не стал.
Уже не знаю что спрашивать, но работать без возможности сделать бэкап и в случае чего откатиться - ну его нафиг.
Кто-то работает через ВПН, какие советы ?

(0)

Вопросы как по мне очень странные.

1) Вас в RDP-сеанс то пускают ?
Тогда какая хрен разница ВПН, не ВПН ?
2) Средствами Постгрес бэкап делается ?
3) Почему вы вообще делаете бэкапы ?
4) Допустим  случился факап. У вас есть знания и уменя восстановить базу Постгрес из бэкапа?


P.S.

>>Бэкап базы под 30 Гб.
>>ждал  выгрузку в dt на свой локальный

на свой локальный
Тебя посОдят, а ты не воруй (с)

Только мне кажется, что это уже клиника, или я слишком добр ?

1) РДП нету. Включаю ВПН, со своей платформы запускаю 1С.
2) Делаю выгрузкой в DT.
3) А кто должен делать перед тем как мне нужно внести изменения ?

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

(0) А pg_basebackup админы делают? Может согласовать окно для обновления, когда штатный бэкап сделан? Расширениями можно пользоваться (без изменений в СУБД)?

(2) >>А кто должен делать перед тем как мне нужно внести изменения ?

Скрипт, например.

(4) Делают. В 12 ночи. Днем вносить изменения не могу, только вечером. Получается, что если накосячил, до утра никто не исправит, а там молиться, чтобы какой-нибудь трудоголик не стал работать в базе до 9 утра.
Конфигурация сильно изменена. Я конечно расширениями пользуюсь, но противник того, чтобы туда пихать метаданные.
(3) Все упирается в безопасность. Хотел РДП.
(5) Я бы рад запускать его, но у меня нет прав.

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

(0) Хм. Делать бэкап на свой локальный ПК?... Это да, прикольно.
Вариантов на самом деле много, и ВПН тут вообще не при чем в принципе.
Конфигуратор то с открытой конфигурацией открывается нормально или тоже час ждать надо?

(8) Да, прикольно. Какие другие решения ?
Конфигуратор открывается отлично.

(0) Совет простой, действовать профессионально, а не через жопу
Выгрузка в dt фирмой 1С не расценивается как создание бекапа, тем более надежного

(0) Через VPN я бы базы не обновлял (а если у тебя кот роутер перезагрузит пока ты делал реструктуризацию, оно тебе надо?). только РДП сервер на стороне заказчика.

(10) Я поэтому и создал тему. У меня на данный момент других вариантов ведь нет. Разве что через скрипт, но никто не даст ни логина ни пароля.

(8) "Вариантов на самом деле много, и ВПН тут вообще не при чем в принципе."
Так что за варианты ?

А почему выгрузка в dt так долго длится, с другой стороны? Админы не могут дать шару на том же серваке, где и кластер PG находится?

(13) Думаю, здесь в любом случае нужно безопасникам объяснить, что именно нужно и что это не нарушит безопасную безопасность.
Например, тот же скрипт, который только делает бекап в специальную папку на диске сервера или в локальной сети, вообще не может никак повлиять на безопасность. Запускаться он вообще может без доступа в сеть, по триггеру какому-нибудь.
Оптимальный по скорости вариант, конечно, RDP, но не обязательно в сервер, пусть организуют виртуалку в локальной сети сервера с правами обычного пользователя без доступа к внешним ресурсам, чтобы можно было только 1С запустить и место для выгрузки ДТ было. Я не думаю, что если у них бэкапы по 30 ГБ, то не найдется 200 ГБ на рабочее место.

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

РДП, Анидеск, ТимВиевер, РАдмин и еще куча вариантов.
У тебя тестовая копия базы для работы и тестирования им отправляешь выполненную работу они сами обновляют.
С современным интернетом у меня по инету файлы быстрее копируются чем по локальной сети и это с учетом ВПН.

(6) >>но противник того, чтобы туда пихать метаданные.

Метаданные метаданным рознь. Все, кроме того что вызывает изменения в СУБД, ИМХО, добавлять в расширение можно (даже, о ужас, расширять формы интерактивно - вообще почти никаких проблем с ERP). Другое дело, если это противоречит методологии разработки в компании (скрипты CI/CD не учитывают расширение, например).

(11) Обновление базы через инет (а не локально, крайне желательно вообще не в ЛВС, а на самом сервере 1С) — это вообще сразу говорит о профнепригодности

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

(15) "чтобы можно было только 1С запустить и место для выгрузки ДТ было"
А выгружать опять же через dt ?

(21) см (10)
>> Выгрузка в dt фирмой 1С не расценивается как создание бекапа, тем более надежного

(22) Нет доступа к постгресу.

(23) Нас не ебёт

В общем, или РДП или бежать оттуда :(

(25) Или наладить отношения с админами, поставить девопс.

(23) Ты совсем читать не умеешь?
Зачем ты тогда спрашиваешь на форуме, что делать, если все-равно не читаешь советы?

(27) Я читаю. Просто некоторые советы мне знакомы и эти варианты уже были обговорены и получил отказ.
РДП-это было первое, что я попросил. Отказались.
Самостоятельное создание бэкапа и восстановление из него-тоже отказ.

(21) Можно в ДТ, можно скулем. Еще раз - даже чтобы запустить процесс скулевого бэкапа тебе лично не нужны права и пароли админа, нужно просто это настроить, например в шедулере создается задача по наличию файла в определенной папке запустить скрипт бэкапа. Кидаешь в папку файл - бэкап сохраняется.
Ну или по команде боту в телеграм, если по-модному.

(28) Ну так прочитай последнюю строку в (20) что ли

(28) РДП нужно правильно обосновать.
Самостоятельное восстановление из бэкапа - правильный отказ, мало ли что ты восстановишь. Тебе достаточно создавать бэкап, а восстанавливать можно по запросу.

(22) Вот здесь https://infostart.ru/1c/articles/2160746/ пишут, что консистентность базы 1С, восстановленной из дампа pg вообще под вопросом.

(28) "РДП-это было первое, что я попросил. Отказались.
Самостоятельное создание бэкапа и восстановление из него-тоже отказ." Если есть пруфы на отказ,
тогда вообще должно быть пхуй, от слова совсем, они ССЗБ, я бы даже не парился

(31) Да, наверное вот про это спрошу
"Оптимальный по скорости вариант конечно РДП, но не обязательно в сервер, пусть организуют виртуалку в локальной сети сервера с правами обычного пользователя"

(34) Даже если Вам дадут доступ по RDP, то бэкапы — это не Ваша зона ответственности.

(0) беги оттуда нахрен!

(32) консистентность базы 1С в произвольный момент в принципе под вопросом, ибо подтвердить её может только ТиИ

(0) ещё из вариантов - чем-то(скриптом, прогой) сразу лить бэкап в облако (гугл драйв, яндекс диск, vps-сервер свой), куда согласятся админы. А не себе на локальную машину.

Бэкап базы под 30 гигов - это через dt?
Тогда не факт, что скульный бэкап поможет (ведь там постгрес) ...

У меня выгрузка в dt одной из баз 90 Гб.
Когда база была на МССКЛ бэкап штатными средствами выполнялся минут 20, теперь база на Постгре - бэкап штатными средствами выполняется 4 часа.

(28) После отказа в RDP можно было слать нахрен.
Ибо неадекваты.

детский сад, штаны на лямках
с такой организацией как контора до сих пор существует?

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

дичь какая. я думал только у меня такие клиенты (

(42) если у тебя база десятки-сотни гиг, тебе не получится сделать файловую.

(0) "Перед внесениями изменений делать архив вообще не вариант, " - А ты что, сразу на продуктиве меняешь?

(39) >>теперь база на Постгре - бэкап штатными средствами выполняется 4 часа
Многопоточность штатных средств может скрасить долгое (мучительное) ожидание.
max_parallel_maintenance_workers=4, хотя бы( это для create index при восстановлении) и pg_dump -Z 0 -j=N(разумное желаемое число потоков). Сжать выгрузку потом можно тоже многопоточно, архиватор - по вкусу. Конечно, это все требует больше памяти на сервере, но что делать...

(46) Игрался я этими параметрами - все равно в разы медленнее ... + жрет и процессор и память - во время бэкапа работать невозможно, поэтому бэкап теперь 1 раз и ночью ...

Суть не в этом, а в том, что бэкап большой базы - это тоже долго и отнимет у автора кучу времени

(47) Более того, это даже уголовно наказуемо, потому что здесь налицо:
1) Превышение должностных полномочий, статья 286 УК РФ
2) Неправомерный доступ к компьютерной информации, статья 272 УК РФ
А если в базе персональные данные, то ещё Статья 272.1 УК РФ

до 10 лет

(0) Найти нормальную фирму, с нормальными админами

(44) а я и не говорю, что поднимаю полноценный архив, делаю пустую, данные для теста ввожу руками

(39) Нет, именно bak, а сколько будет весить dt-не знаю.

"Когда база была на МССКЛ бэкап штатными средствами выполнялся минут 20"
Что-то дофига. Я делал бэкап этой базы, только на старом месте работы, примерно 2 минуты.
(42) Нет, специализированная , измененная конфигурация.
(45) Я пока еще ничего там не делал. На старом месте ест-но на копии.

(51) Скуль бэкапит быстро даже со сжатием, а постгрю утопить вместе с создателями. За бэкапы через жопу.

(0) У меня была фигня, шифрованный ВПН передачу файла делал ООООЧЕНЬ МЕДЛЕННО. Мож у них избыточное шифровние на всратом микротике.

(10) Бэкап постгреса тоже может оказаться битым.

(18) Чего плохого, добавить в расширении какой-то регистр или справочник или документ? Главное, он не должен делать движений в регистрах основной конфигурации, и на него не должно быть ссылок там. То есть, потеря расширения должна быть абсолютно безболезненной для основного функционала. Ну отвалится доработка, и хрен с ней. Если программиста нет в штате, то и дорабатывать не надо.

(55) "То есть, потеря расширения должна быть абсолютно безболезненной для основного функционала"
В той типовой конфигурации есть регистр "Ставки".
Изначально туда писались ставки при заключении договора, доп.соглашения. Потом клиенту потребовалось, чтобы эти ставки начинали действие только после акта приема-передачи. После консультаций с разработчиком было принято решение при заключ. договора туда писать без самой величины (число или график) ставки, а потом Акт делает движения и пишет ставку. Т.е. в регистраторы добавлен Акт.
А теперь представь если регистр будет перенесен в расширение, там добавим регистратор и вдруг это расширение "отвалится".
При очередном начислении программа нифига не начислит, ставок то нет.

(56) Если так глубоко, то конечно придется корежить конфигурацию.

(55) "Чего плохого, добавить в расширении какой-то регистр или справочник или документ" - Регистр пофиг, а вот со справочниками и документами не очень. Например, если у тебя в базе есть реквизиты типа "любая ссылка" или "ДокументССылка", "СправочникССылка" (как в любой базе на основе БСП).
К этому, если у тебя есть тяжелые регистры с миллионами записей, то добавление справочника или документа в расширение повлечёт длительную реструктуризацию базы.
При отключении расширения - будет новая реструктуризация.

(0) Так админам вопросы задавай. Мы то чем поможем?

(56) Что все так запуганы Волшебником по поводу расширений? Использую с момента из появления, ничего никуда не исчезло и не отвалилось, руки ровняйте)

(60) Многие обновляют базу динамически и у них тоже пока всё работает...

(61) Я обновляю динамически когда это возможно. Двести баз на основной работе и сотня в сумме на подработках, ЧЯДНТ? Ровные руки, чистый кэш, бэкап перед обновлением. 3 слагаемые успеха)

(62) Проверку бэкапа забыл
Они не всегда восстанавливаются и работают

(60) А пробовал ТиИ запускать, когда в расширении есть добавленные реквизиты/метаданные?

(0) Решение для настоящих айтишников:
Программно на сервере запустить (из другой базы 1С например) выгрузку в dt в темп, http-сервисом забрать dt
Но можно и микросервис на Go ))

Правильное решение:
Напрячь админов чтобы подняли RDP

(62) Ты просто везунчик.

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

(63) За 25 лет ни разу не было такого, чтобы бэкап не восстановился. Скулевый контроль бэкапа включен всегда.

(64) Примерно раз тысячу) Вот последний раз на прошлой неделе пару конф., там тяжелое расширение с кучей метаданных (доки, справочники, реквизиты, константы, все что можно в расширении).

(66) Думаешь, стоит прикупить пару лотерейных билетов?))

(69) Помнишь анекдот про еврея, который ежедневно молил Бога, чтобы выиграть в лотерею? Наконец, Господь ему с небес громогласно заявил: "Ну купи ты хоть один лотерейный билет!"
Анализируй это.

(70) Я не еврей, мне и без билета норм)

(51) Вот и начни работу на новом месте с организационно-технических мероприятий. Надо создать тестовый контур в котором ты вносишь изменения, аналитик тестирует, потом юзеры тестируют. После того как все сказали что норм - перенос в рабочие базы. И не надо бояться, что что-то сломается, вопросы бэкапа исчезают.
Корежить продуктив напрямую - ну так себе идея, для мазохистов

(72)

Это было что-то "на богатом", да  ?

У него не новое место работы.
Человек фрилансер.  Пришёл, сделал, ушёл.
Ему RDP - не могут дать.

А вы про -- аналитик, юзеры тестить будут, контуры-шмонтуры.

(72) Думаешь там есть аналитики? ТС же похоже просто фришник, работающий на контору где из айтишников только админы, разве нет?

(73) (74) Чел начал работать с новой конторой, значит новое место работы. Если там постгри, то и поддержка этого всего должна быть, значит не нищие. Потом работу надо принять, это в любом случае кто то должен протестить. Не сам же он скажет что все гуд, гоните бабло.
Если предполагается не разовая халтура, то все мной сказанное имеет смысл сделать

(0) Зачем забирать базу на свой ПК все таки объясните? Это НЕ ваше. Пусть выделят вам место в сети компании и туда делайте бекапы. Вменяемым админам, ИБшникам вполне легко это объяснить.

(75) Вот совсем не факт. Буквально пару месяцев назад сталкивался - большая контора на 50 тыс персонала, филиалы по всей стране, Постгре ля ля тополя, при этом на 1Ске ни консов, ни аналитиков, только проги одни, работающие напрямую с бизнесом. При этом к тестовым базам доступ только из Московского офиса, то есть пользователь из какого нить Орла посмотреть что получается тупо не может до того, как это попадет в прод. При этом только на зупе под 300 активных пользюков было, а на ЕРП база в 10 Тб...

(77) Так тоже бывает, но это крайне тупой способ организации работы. Вряд ли будете спорить, что это удобно и правильно.
Кто ставит задачи на разработку, кто их принимает ? Кто обучает сотров новому функционалу ?
Дичь и жлобство