Имя: Пароль:
IT
Админ
При восстановление bak базы sql в другую базу, забыл поменять пути
0 asd123
 
07.01.25
06:15
Привет! При восстановление bak архива sql в другую базу SQL server 2008, забыл поменять пути, и в основной базе видимо восстановились старые файлы, сохраннные вчера, потом пользователи поработали один день. Как можно восстановить один день?

Или вообще если забыл поменять пути при восстановления bak архива sql в другую базу, что будет с базой bak архива, откуда она сохранялась?
1 Тындр
 
07.01.25
11:11
Интересно, как так получилось. Сколько не пытался так накосячить, всегда выдавалось сообщение "файл используется", ведь даже если юзеры не работают, как минимум одно соединение с базой SQL от сервера 1с открыто
2 bolder
 
07.01.25
12:09
(0) Ничего хорошего не будет.А ты думал, просто так 1с никам хорошие деньги платят? Реакция будет истерическая. Пиши три конверта и сматывайся.Теперь ты знаешь все про неделание бэкапов, даже если "только восстановить...".
  
PS.А этот день прийдется восстановить.Как - это отдельный вопрос.
3 AAA
 
07.01.25
12:44
Случиться может с каждым, хотя ляп весьма грубый. Но как никто не заметил:
- Рабочая база неактуальная, но в нее день колотили документы
- База, в которую хотели восстановить, осталось в прежнем состоянии. Значит эта база никому не нужна была?

Как вариант - честно признаться, восстановить самую последнюю актуальную копию и день перебить
4 AAA
 
07.01.25
12:49
плюсом - Автору (если не уволят) запретить восстанавливать базы из бекапов. Могу ошибаться, ну путь он не заметил, а просто нет опыта в таком восстановлении. Забыть задать куда восстанавливать это значит скорее всего не знать этого процесса. Возможно это вообще впервые было
5 bolder
 
07.01.25
13:17
(4) Плюсую.В MSSQL Management Studio  при восстановлении довольно просто накосячить, если не знать что по умолчанию там будет именно косячное предложение.Поэтому каждую опцию надо выверять а потом уже восстанавливать.И кто помешал сделать автору полный бэкап рабочей базы?Вот он то как раз зачастую по умолчанию все отлично делает, но лучше лишний раз проверить.
6 asd123
 
07.01.25
16:04
я сделал как здесь https://infostart.ru/1c/articles/170486/ ,и  галочку replace не ставил, может не перезаписи не было?
7 shuhard
 
07.01.25
16:09
(6) что-то мешает посмотреть лог сиквела и наличие записи restore ?
8 asd123
 
07.01.25
16:37
(7) да есть только одна такая запись за 5.01.2025 Database was restored: Database: zik_31_old_1 Restored is complete on database "zik_31_old_1". The database is now available

Да это база в которую я хотел восстановить, архив из другой
базы zik_31_main
больше записей нет, значит база zik_31_main не перезаписалась?
9 Krendel
 
07.01.25
16:36
(7) Думаешь это религиозное?
10 asd123
 
07.01.25
17:10
(9) ага да похоже пронесло, спасибо
11 youalex
 
07.01.25
18:57
(1) Одно время было галка "Разорвать все текущие соединения" или вроде того. Не знаю, от версии студии зависит или от настроек, но точно была)
12 MWWRuza
 
гуру
07.01.25
20:36
(6) - (11) Ух ты.... Во скока сложностей...
А я и не знал :-)

У меня есть в одной кассовой программе (не 1С), база SQL, для учета продаж (исключение дублей) маркировки, и для продаж разливного пива, с "постановкой на кран" из 1С и потом продажи в разлив, пока кега не кончится, без сканирования марки, но при этом с передачей продажи в ЧЗ, с возможно нескольких касс...
Всегда у клиентов забирал базу по методу описанному в (6), без всяких чтениев "талмудов", там и так инуитивно понятно все, и восстанавливал себе, для тестов и отладки.
А оказывается, вон там сколько нюансов...
13 d4rkmesa
 
гуру
07.01.25
21:25
В более-менее современном SQL такой фигни нет, пути не восстанавливаются при restore по дефолту.
14 Builder
 
09.01.25
10:32
(13) Да уж, сколько лет понадобилось MS что-бы доделать очевидную фигню. Бесило это жутко - не забыть поменять пути....
15 Адинэснег
 
10.01.25
07:16
🤦‍♂️