Можно ли делать шринк лога транзакций при инкрементной архивации БД? #697798

Подскажите, пожалуйста, ситуация такая, что баз довольно много, а вот  места мало всего 40-50 ГБ, начальник поручил вместо полного бэкапирования с простой моделью восстановления соответственно, делать инкрементный бэкап. У меня в плане обслуживания логи транзакций резались, чтобы места не кушать. Хотел спросить при инкрементном бэкапе как себя будут вести логи транзакций  и можно ли их периодически резать?

Полное бэкапирования я делал на сетевое хранилище, ну а лог транзакций соответственно на системных дисках, где места очень немного

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

извиняюсь, не совсем Вас понял

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

тишина...(

Если вы делаете бэкап логов (модель фулл) - то никаких шринков  делать низзя , ибо есть вероятность что часть транзакций просто потеряется. Либо после шринка сразу делайтье полный бэкап , а дальше пошла цепочка бэкапа логов. Если часто делать бэкап логов - то есть вероятность что файл лог транзакций расти не будет , и при этом бэкапы будут маленькими по объему.

фулл бекап недельной давности и инкремент за неделю, падает сервер с 1С и инкрементными бекапами  - протеряли неделю работы.:)

Сначала предлагаю разобраться с тем как восстанавливать из таких бэкапов Потренируйся А то выяснится, что место сэкономили, но базы потеряли И вообще смешно... купите обычных пару хардов за 70 бачков и пишите туда

Куда транзакции потеряются??? Шринк режет только закрытые. ткрытые он не трогает. В Мелкософте сидят не настолько дураки, как многие думают.

Добавочное резервирование Incremental Backup При добавочном ("инкрементальном") резервировании происходит копирование только тех файлов, которые были изменены с тех пор, как в последний раз выполнялось полное или добавочное резервное копирование. Последующее добавочное резервирование добавляет только файлы, которые были изменены с момента предыдущего добавочного резервирования. В среднем, добавочное резервирование занимает меньше времени, так как копируется меньшее количество файлов. Однако, процесс восстановления данных занимает больше времени, так как должны быть восстановлены данные последнего полного резервирования, плюс данные всех последующих добавочных резервирований. При этом, в отличие от дифференциального резервирования, изменившиеся или новые файлы не замещают старые, а добавляются на носитель независимо.

я лог никогда не сохранял, просто базу данных сжатую переносил на сетевое хранилище через план обслуживания. А вот сейчас при инкрементном плане не знаю обрезать его или не трогать, чтобы потом базы могли нормально восстановиться.

журнал транзакций нафиг не нужен теоретически. Поставьте Симпл вобще, раз постоянно делаете инкременты. восстанавливать только долго будете если что случится

Maxus43, т.е. при инкрементном, архив сам по себе один не будет нарастать, вместе с ним будет куча изменений в виде отдельных файликов, которые тоже будут места занимать?

а сколько база будет восстанавливаться при инкременте если она весит на скуле 14-15 гб?

при инкрементном куча файликов после последнего Полного бэкапа восстанавливать нужно последний полный + все последующие инкременты после полного

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

а вообще намного ли места больше сэкономится от инкрементного бэкапирования?

лучше скажи зачем логи режешь в простой модели?

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

ВСе просто очень много баз, а м еста мало, бухгалтер запустить ОСв или перепроведения и лог уже пару гигов весит. Я  понимаю ,что резать лог не совсем корректно, но места совсем нет. Начальник купил в шараге сервер по частям за откат, а мучится естественно подчиненным (

на системном диске С, где ОС и скуль там места 40 гб осталось. на других где базы - примерно также 40-60. вот так (

дак процесс закончится и лог автоматом порежется, он же Симпл, фиксированные транзакции уничтожает жеж

В общем спасибо ВАМ ВСЕМ большое за советы

Спасибо, Maxus43, я понял, будем резать))

смешно еще, что сервер на 1 проце

начальник считает, что для 75 баз 1 проца хватит, общий вес баз кстати уже больше сотни гигов и 50 бухов сидят в них

начальник красава! респект, подари ему бублик с шоколадной крошкой, и пусть идёт работать в РОСНАНО, там таких любят

У меня уже сил нет, думаю маляву писать на увольнение и бежать отсюдова (

Спасибо тебе большое Maxus43, ты меня очень-очень выручаешь !

у нас терабайтные сервера с оперативой больше 100 гигов... и то тормозит, ну там быдлокод конечно

так еще на этом же серваке и сервер терминалов и сервер 1с,три в одном, 64 оперативы

И самое интересное системный диск, который три в одном обслуживает держится на одном ssd 120 гб intel без рэйда, потому что софтовый встроенный рэйд контроллер походу сдох А все базы данных на adapteke без 7805 ,который без кэша на запись

я вообще не понимаю, как это еще все работает, но по приказу вот разбираюсь))

а у меня под КОПИЮ зики 8 процессоров.. и хотелось бы больше, но приходится мириться с жадностью админов.

на adapteke без 7805  - т.е. adaptek 7805 без max cashe 3.0

не перевелись на руси нищеброды начальники короче. Да ничо страшного, 1 раз всё наипнётся - сразу передумает...

тут походу на него управы нет, он какой-то родственник учредителей и  чувствует себя Аменхатэпом

обычно везде используют sas винты, а ssd как кэш для рэйд-контроллера, а вот сами ssd как основные я не видел и люди добрые так тоже не  советуют

ну а через PCI-E, пока еще дорого получается

да ну, ssd винты прекрасны под всё, старые модельки может и неустойчивы были, современные промышленные ssd норм

согласен, но на кривом железе, они показывают скорость чтения 120 мб в секунду в raid 10, на одном, на котором система, чуть больше 200-220. Тестил через HDTUNE PRO 5.0

мне кажется, что для БД скорость чтения должна быть на порядок больше

Еще раз большое спасибо, пойду дальше воевать))