Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
где хранить бэкапы?
|
|||
|---|---|---|---|
|
#18+
И тестовые базы можно поднимать за секунды вне зависимости от размера. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.08.2017, 22:32 |
|
||
|
где хранить бэкапы?
|
|||
|---|---|---|---|
|
#18+
klichСмысл резервной копии именно в том, чтобы с неё максимально быстро восстановиться.Для высокой доступности данных применяют несколько другие технологии, нежели бэкап. Когда базы маленькие, есть еще иллюзия, что "да за пару часов отресторю, если что". После достижения базой размера где-то 10 Тб "быстро" ресторится становится проблематично почти при любом железе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.08.2017, 01:36 |
|
||
|
где хранить бэкапы?
|
|||
|---|---|---|---|
|
#18+
klich>>> Более того, для особо важных ресурсов раз в неделю делается полная копия, лента извлекается и отправляется в архив в другое здание. И сколько времени уйдёт на восстановление такого бэкапа? Пока вы привезете его из другого здания, пока прочитаете ленту, пока убедитесь в целостности данных... А если на полную копию придется ещё накатывать инкрементальные копии? А они тоже на лентах... Нет, для бэкапов ленты не годятся. Разве что для бэкапов совсем уж маловажных данных. Эээм. А понятие "Disaster recovery" вам знакомо? Лента - это самый главный бекап. Причем с ротацией двух-трех комплектов кассет. И в библиотеку ничего последовательно засовывать не надо руками - у неё внутри хранилище кассет. У 2024 - 24 кассеты, у 4048 - 48 кассет. Есть и на большее количество. Загрузил кассеты скопом, а система сама разберется, в каком порядке их подавать. По штрих-коду. А есть библиотеки уровня ЦОД ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.08.2017, 08:57 |
|
||
|
где хранить бэкапы?
|
|||
|---|---|---|---|
|
#18+
alexeyvgХраните одну копию бакапа на непосредственно серверных дисках каждого рабочего сервера, для быстрого восстановления. Другую копию бакапа - в отдельном хранилище (ленты или СХД), притом хранение этой копии должна организовывать другая команда, со своим отдельным (не управляемым централизованно) доступом на чтение, и она же должна отвечать за состояние этих бакапов, то есть верифицировать бакапы путём восстановления их на свои, опять же независимые и управляемые отдельно, серверы. +100 Последнюю копию - на диске, её же потом сбрасывать на ленту в свободное время. И волки сыты, и овцы целы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.08.2017, 11:32 |
|
||
|
где хранить бэкапы?
|
|||
|---|---|---|---|
|
#18+
CrazyDr1v3r, У нас это тоже выглядит довольно круто :) вот тока админы не дадут мне снимать я думаю. Библиотека у нас тоже большая, помимо БД есть еще террабайта 3-4 разной инфы, и это все может хранится от недели до трех лет прежде чем быть перезаписаным. to defragmentator, ага, последнию на диске, а потом когда время будет ее скопируем, разумеется. Сделали мы себе backup и сидим счастливые, а у нас БАЦ, и все летит, включая наш сервер с последней копией которую мы еще никуда не скопировали. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.08.2017, 11:50 |
|
||
|
где хранить бэкапы?
|
|||
|---|---|---|---|
|
#18+
Гавриленко Сергей АлексеевичklichСмысл резервной копии именно в том, чтобы с неё максимально быстро восстановиться.Для высокой доступности данных применяют несколько другие технологии, нежели бэкап. Когда базы маленькие, есть еще иллюзия, что "да за пару часов отресторю, если что". После достижения базой размера где-то 10 Тб "быстро" ресторится становится проблематично почти при любом железе. например? у нас несколько баз подбираются к 10 Тб. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.08.2017, 15:14 |
|
||
|
где хранить бэкапы?
|
|||
|---|---|---|---|
|
#18+
odissseyнапример? у нас несколько баз подбираются к 10 Тб. Always On Availability Groups (SQL Server) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.08.2017, 15:31 |
|
||
|
где хранить бэкапы?
|
|||
|---|---|---|---|
|
#18+
o-o, AG конечно хорошо, но это не решает проблему логической порчи данных ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.08.2017, 16:29 |
|
||
|
где хранить бэкапы?
|
|||
|---|---|---|---|
|
#18+
CrazyDr1v3ro-o, AG конечно хорошо, но это не решает проблему логической порчи данных ;)Не читатель... :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.08.2017, 18:35 |
|
||
|
где хранить бэкапы?
|
|||
|---|---|---|---|
|
#18+
aleksrovto defragmentator, ага, последнию на диске, а потом когда время будет ее скопируем, разумеется. Сделали мы себе backup и сидим счастливые, а у нас БАЦ, и все летит, включая наш сервер с последней копией которую мы еще никуда не скопировали. Ну куда летит? Сервер может полететь, да. А если там ещё один воткнули, он никуда не улетит, только если пожар или страшный вирус Петя. На такие случаи можно на другой комп бэкап делать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.08.2017, 11:34 |
|
||
|
где хранить бэкапы?
|
|||
|---|---|---|---|
|
#18+
defragmentatoraleksrovto defragmentator, ага, последнию на диске, а потом когда время будет ее скопируем, разумеется. Сделали мы себе backup и сидим счастливые, а у нас БАЦ, и все летит, включая наш сервер с последней копией которую мы еще никуда не скопировали. Ну куда летит? Сервер может полететь, да. А если там ещё один воткнули, он никуда не улетит, только если пожар или страшный вирус Петя. На такие случаи можно на другой комп бэкап делать. * ещё один диск воткнули ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.08.2017, 11:35 |
|
||
|
где хранить бэкапы?
|
|||
|---|---|---|---|
|
#18+
defragmentator, Можно хоть 10 дсков воткнуть, это не спасет. Я видел как горели серверные (точнее все здание включая серверную) или как горел сервер, заходишь, а с него дым как из печки валит, да, это всего два случая, но этого достаточно бизнесу чтобы разориться. Как говорилось выше, копия должна быть на сервере чтобы при восстановлении не ждать пока она скопируется по сети, т.е. сначала копия все таки делается на удаленный носитель, а потом уже на сервер. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.08.2017, 12:00 |
|
||
|
где хранить бэкапы?
|
|||
|---|---|---|---|
|
#18+
aleksrov, позволю себе с Вами не согласиться. Дело в том, что процесс бэкапа жрёт слишком много серверных ресурсов - он практически умирает. Поэтому его делают тогда, когда нагрузка минимальна - ночью или в технологический перерыв. А если, скажем, растянуть процесс на всю ночь, то не успеют выполниться другие регламентные процедуры. Так что сначала - на локалку, а потом уже копировать во вне, на сетевой диск. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.08.2017, 12:24 |
|
||
|
где хранить бэкапы?
|
|||
|---|---|---|---|
|
#18+
defragmentator, Если честно никогда не видел чтобы из-за бекапа сервер умирал. Не, конечно я совсем недавно видел одних кадров которые в 12 дня делали полный бекап 800 ГБ базы на тот же диск где был файл данных и файл лога, там да, все умирало, а так, обычно это не такая проблема, т.к. полный делается как правило раз в неделю, когда нагрузка минимальна, а потом или diff или бекап лога, последнее довольно быстро + с AlwaysOn вообще можно нагрузку убрать, если вам Diff не нужен. Ну каждому свое, мне достаточно представить что со мной сделают если последний бекап окажется на умершем сервере и у меня сразу отпадает желание так делать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.08.2017, 12:39 |
|
||
|
где хранить бэкапы?
|
|||
|---|---|---|---|
|
#18+
Дело в том, что процесс бэкапа жрёт слишком много серверных ресурсов - он практически умирает.По моим наблюдениям производительность просаживается на 20-40%, не более. Это вовсе не смерть. Тем более - не причина для аварии регламентных процедур, выгрузок, обменов и пр. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.08.2017, 14:03 |
|
||
|
где хранить бэкапы?
|
|||
|---|---|---|---|
|
#18+
LSVДело в том, что процесс бэкапа жрёт слишком много серверных ресурсов - он практически умирает.По моим наблюдениям производительность просаживается на 20-40%, не более. Это вовсе не смерть. Тем более - не причина для аварии регламентных процедур, выгрузок, обменов и пр. Значит, мы разные системы наблюдали. Да и потом, это просадка при чтении. А при записи? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.08.2017, 15:35 |
|
||
|
где хранить бэкапы?
|
|||
|---|---|---|---|
|
#18+
defragmentator, А вы не пишите на тот диск, как те "админы" о которых я писал выше, на котором у вас лог или данные. Да и вообще не хранить бекапы вместе с базой на одном диске это наверное первое чему учат админов во всех книгах и курсах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2017, 04:21 |
|
||
|
где хранить бэкапы?
|
|||
|---|---|---|---|
|
#18+
aleksrovdefragmentator, А вы не пишите на тот диск, как те "админы" о которых я писал выше, на котором у вас лог или данные. Да и вообще не хранить бекапы вместе с базой на одном диске это наверное первое чему учат админов во всех книгах и курсах. Собственно, я лично не пишу, как Вы говорите. Да и если пораскинуть мозгами, простое копирование не так времени занимает. Вот поддержание целостности создающегося бэкапа во время работы пользователей - это непростая задача :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2017, 08:48 |
|
||
|
где хранить бэкапы?
|
|||
|---|---|---|---|
|
#18+
defragmentatoraleksrovdefragmentator, А вы не пишите на тот диск, как те "админы" о которых я писал выше, на котором у вас лог или данные. Да и вообще не хранить бекапы вместе с базой на одном диске это наверное первое чему учат админов во всех книгах и курсах.. Вот поддержание целостности создающегося бэкапа во время работы пользователей - это непростая задача :) И почему же это не простая задача? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2017, 09:38 |
|
||
|
где хранить бэкапы?
|
|||
|---|---|---|---|
|
#18+
aleksrovdefragmentatorпропущено... . Вот поддержание целостности создающегося бэкапа во время работы пользователей - это непростая задача :) И почему же это не простая задача? А Вы уже знаете, что делать, если пользователь добавил элемент в справочник, когда таблица справочника уже вошла в бэкап? А потом добавил запись в таблицу со ссылкой на справочник, а это ещё не вошло в бэкап? По - новой куда-то там что-то переписывать. И всё это надо контролировать, транзакции нужные держать. Ну Вы, как вижу, новичок в этой теме. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2017, 10:35 |
|
||
|
где хранить бэкапы?
|
|||
|---|---|---|---|
|
#18+
defragmentator, Разумеется новичок :) https://technet.microsoft.com/en-us/library/2009.07.sqlbackup.aspx читать до полного понимания. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2017, 10:55 |
|
||
|
где хранить бэкапы?
|
|||
|---|---|---|---|
|
#18+
aleksrovdefragmentator, Разумеется новичок :) https://technet.microsoft.com/en-us/library/2009.07.sqlbackup.aspx читать до полного понимания. Да Вы тролль. Тыкаете мне туда, про что я Вам только что рассказывал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2017, 12:36 |
|
||
|
где хранить бэкапы?
|
|||
|---|---|---|---|
|
#18+
defragmentatoraleksrovпропущено... И почему же это не простая задача? А Вы уже знаете, что делать, если пользователь добавил элемент в справочник, когда таблица справочника уже вошла в бэкап? А потом добавил запись в таблицу со ссылкой на справочник, а это ещё не вошло в бэкап? По - новой куда-то там что-то переписывать. И всё это надо контролировать, транзакции нужные держать. Ну Вы, как вижу, новичок в этой теме.Это вы рассказываете какие-то сказки про то, что более ранняя транзакция в бэкап не попала, а более поздняя попала? В этой СУБД так не бывает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2017, 12:37 |
|
||
|
где хранить бэкапы?
|
|||
|---|---|---|---|
|
#18+
defragmentatoraleksrovdefragmentator, Разумеется новичок :) https://technet.microsoft.com/en-us/library/2009.07.sqlbackup.aspx читать до полного понимания. Да Вы тролль. Тыкаете мне туда, про что я Вам только что рассказывал. Вы рассказываете не это, а какие-то сказки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2017, 12:42 |
|
||
|
где хранить бэкапы?
|
|||
|---|---|---|---|
|
#18+
Гавриленко Сергей Алексеевичdefragmentatorпропущено... А Вы уже знаете, что делать, если пользователь добавил элемент в справочник, когда таблица справочника уже вошла в бэкап? А потом добавил запись в таблицу со ссылкой на справочник, а это ещё не вошло в бэкап? По - новой куда-то там что-то переписывать. И всё это надо контролировать, транзакции нужные держать. Ну Вы, как вижу, новичок в этой теме.Это вы рассказываете какие-то сказки про то, что более ранняя транзакция в бэкап не попала, а более поздняя попала? В этой СУБД так не бывает. Собственно, я не утверждаю, что точно знаю, как это происходит. Я привожу пример сложности задачи. В точности знать, какой алгоритм используется, не требуется. В любом случае указанную ситуацию требуется как-то обрабатывать, резервируя под это ресурсы, создавая транзакцию, то есть разделяя то, что было в БД до бэкапа и то, что "накапало" туда в процессе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2017, 12:45 |
|
||
|
|
start [/forum/topic.php?fid=46&msg=39509192&tid=1688823]: |
0ms |
get settings: |
9ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
50ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
66ms |
get tp. blocked users: |
2ms |
| others: | 269ms |
| total: | 429ms |
| 0 / 0 |
