|
перенос большой базы на новый сервер
|
|||
---|---|---|---|
#18+
Всем привет. Кто может подсказать идеи подать. Сдохло пару Lun на СХД. СХД сама старая не на поддержки. Инженер от вендора сказал скоро вся помрет, там и платы погарели и куча дисков. Цену назвали за ремонт можно такую же купить, только новую и современную. У меня критичная база на этой СХД, 24 тера. И пользаки ей активно пользуются. Один бэкап ее идет полтора дня. Денег руководство сказало нет. В этом году ничего не купят. Но у нас есть кусочек места в облаке арендованный. Планируем перенести туда. если тащить бэкап в облако по сети калькулятор передачи данных посчитал 50 дней. Как можно залить полную копию по сети без бэкапа, кластер из always on group не могу создать у нас лицензия не та. Хрен с ним пускай перекачивает в сеть 50 дней и пользаки паралельно работают. Только вот не знаю как реализовать. Я думал нас купить, сделать бэкап, залить бэкап на нас, принести в контору и развернуть прямо в конторе которая нам облако дает но все равно получается по моим расчетам дней на 6 отключить базу надо. Сервер у нас MS SQL server 2014. Может есть какая то встроенная утилита или кто знает полезную статью на такой случай. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.08.2021, 13:51 |
|
перенос большой базы на новый сервер
|
|||
---|---|---|---|
#18+
dolya, Кроме полных бакапов есть же еще дифференциальные и бакапы логов. 1. Сделать полный, и копировать его на облако. На базе пока в это время обойтись без полных (либо делать их с copy_only), выполняя только разностное копирование и бакапы логов. 2. Как скопируется и развернется фулл на облаке, сделать очередной дифф-бакап и заливать его на облако. На сервере ограничения на выполнение фулл-бакапов можно снять, но главное не потерять непрерывность цепочки бакапов логов. 3. Как скопируется и развернётся дифф, последовательно накатывать бакапы логов. И так пока не догонится рабочая база 4. В момент переключения отключаем пользователей, делаем финальный бакап лога, копируем и разворачиваем его на облаке, базу переводим в рабочий режим на облаке, переключаем пользователей туда. В итоге простой будет только на шаге 4. Но нужно предварительно оценить, а сколько вообще изменений происходит в базе, есть ли шансы догнать по такой схеме. В принципе можно и без диффов, только бакапами логов, всё упирается в активность работы с базой, сколько изменений в ней генерируется. Ваша версия sql к сожалению еще не умеет modified_extent_page_count в sys.dm_db_file_space_usage, предсказать размер диффов спустя неделю помогут только натурные эксперименты. P.S. ну и не забывать про сжатие бакапа, в вашем случае это будет дюже полезно, если до сих пор не используется по каким-то причинам. P.S.2 почитать про Log Shipping. но на ваших объёмах восстанавливать всё равно придется без визардов, вручную ... |
|||
:
Нравится:
Не нравится:
|
|||
17.08.2021, 15:33 |
|
перенос большой базы на новый сервер
|
|||
---|---|---|---|
#18+
РядомСтоял, Бэкап практически не жмется. В базе куча документов, так система реализована. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.08.2021, 16:21 |
|
перенос большой базы на новый сервер
|
|||
---|---|---|---|
#18+
РядомСтоял, И я заметил. Что дифф бэкап растет очень странно. первые 2 недели он добавляет к дифу по 200 гб в день. А потом начинает больше и больше как то раз дифу не хватило 5 теров свободного места за раз. То есть если я от фула делаю ежедневно дифы, то через месяц у меня 1 дифф занимает тера 2 - 3. Фуловый бэкап делается раз в месяц. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.08.2021, 16:26 |
|
перенос большой базы на новый сервер
|
|||
---|---|---|---|
#18+
РядомСтоял, И получается по сети тянуть надо месяц фулл а через месяц куча дифов по объему фула. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.08.2021, 16:28 |
|
перенос большой базы на новый сервер
|
|||
---|---|---|---|
#18+
dolya Всем привет. Кто может подсказать идеи подать. Сдохло пару Lun на СХД. СХД сама старая не на поддержки. Инженер от вендора сказал скоро вся помрет, там и платы погарели и куча дисков. Цену назвали за ремонт можно такую же купить, только новую и современную. У меня критичная база на этой СХД, 24 тера. И пользаки ей активно пользуются. Один бэкап ее идет полтора дня. Денег руководство сказало нет. В этом году ничего не купят. Но у нас есть кусочек места в облаке арендованный. Планируем перенести туда. если тащить бэкап в облако по сети калькулятор передачи данных посчитал 50 дней. Как можно залить полную копию по сети без бэкапа, кластер из always on group не могу создать у нас лицензия не та. Хрен с ним пускай перекачивает в сеть 50 дней и пользаки паралельно работают. Только вот не знаю как реализовать. Я думал нас купить, сделать бэкап, залить бэкап на нас, принести в контору и развернуть прямо в конторе которая нам облако дает но все равно получается по моим расчетам дней на 6 отключить базу надо. Сервер у нас MS SQL server 2014. Может есть какая то встроенная утилита или кто знает полезную статью на такой случай. Делая полный бэкап в несколько файлов, можете ускорить этот процесс. После того, как сделаете полный бэкап на боевой, настройте джоб, котрый будет делать бэкапы логов транзакций и сохранять результаты в таблицу. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59.
После того, как развернете полный бэкап на резерве, линкуетесь к этой таблице и курсором идете по этой таблице и применяете логи на копии. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21.
Это избавит вас от удовольствия делать всё руками. Скрипт таблички: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25.
Не забудьте поправить имена баз и линка под себя. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.08.2021, 16:34 |
|
перенос большой базы на новый сервер
|
|||
---|---|---|---|
#18+
dolyaСервер у нас MS SQL server 2014.Редакция какая? dolyaНо у нас есть кусочек места в облаке арендованный. Планируем перенести туда.А как база будет жить в облаке никто опытов не ставил? А приложение тоже в облаке будет? Как бы не получилось что база неприемлимо работает, но ценник облачный конский. вышел из зоны комфорта, так ничего не добился, но теперь и некомфортно (с) dolyaкластер из always on group не могу создать у нас лицензия не та.Кластеру ТОЖЕ нужен полный бакап dolyaЯ думал нас купить, сделать бэкап, залить бэкап на нас, принести в контору и развернуть прямо в конторе которая нам облако даетСовершенно согласен dolyaно все равно получается по моим расчетам дней на 6 отключить базу надоНе надо. В таких условиях только Log shipping Если у вас база в simply recovery mode переводите в полный. Выделяйте кучу места для логов и бакапов логов. Бакапьте логи каждые 5 минут (пусть предыдущий джоб не завершен), да хоть каждую минуту. Пересылайте логи (маленькие) в облако. Там в облаке можно будет открыть базу на чтение чтобы хоть как-то проверить network latency. dolyaЦену назвали за ремонт можно такую же купить, только новую и современную.Купите новую и современную. Это будет самый надежный вариант. dolyaДенег руководство сказало нет. В этом году ничего не купят.Прикрывайте пятую точку. Все заявления только под запись чтобы не оказаться крайними. Привлекайте внимание вышестоящего начальства, будьте готовы что вас подставят. Обновляйте резюме ... |
|||
:
Нравится:
Не нравится:
|
|||
17.08.2021, 17:10 |
|
перенос большой базы на новый сервер
|
|||
---|---|---|---|
#18+
SERG1257, Что-то мне говорит, что автор под облаком имеет ввиду чужую площадку. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.08.2021, 21:13 |
|
перенос большой базы на новый сервер
|
|||
---|---|---|---|
#18+
Критик, Можно и так сказать. Руководство это облаком. Ну и в статьях это называют облаком. У нас там арендовано место дисковое пространство и серверные мощности. Я это все вижу как сервера. а пользакам вообще пофиг. Главное работает ... |
|||
:
Нравится:
Не нравится:
|
|||
17.08.2021, 21:37 |
|
перенос большой базы на новый сервер
|
|||
---|---|---|---|
#18+
dolya, Договаривайтесь о перетаскивании на дисках, потом выбираете какие-нибудь праздничные даты и вкалываете все праздники. Но учтите, как только у вас отвалится канал - все пользователи будут курить ... |
|||
:
Нравится:
Не нравится:
|
|||
17.08.2021, 22:26 |
|
перенос большой базы на новый сервер
|
|||
---|---|---|---|
#18+
dolyaИ я заметил. Что дифф бэкап растет очень странно. первые 2 недели он добавляет к дифу по 200 гб в день. А потом начинает больше и больше как то раз дифу не хватило 5 теров свободного места за раз. То есть если я от фула делаю ежедневно дифы, то через месяц у меня 1 дифф занимает тера 2 - 3. Фуловый бэкап делается раз в месяц. Безотносительно к переносу большой базы на новый сервер. Зачем вы вообще делаете бакапы? Наверное для того чтобы провести восстановление.
... |
|||
:
Нравится:
Не нравится:
|
|||
17.08.2021, 23:27 |
|
перенос большой базы на новый сервер
|
|||
---|---|---|---|
#18+
dolya РядомСтоял, И получается по сети тянуть надо месяц фулл а через месяц куча дифов по объему фула. кстати почему куча диффов? тянуть надо будет один последний дифф, они кумулятивные. Но конечно тянуть месяц не вариант, у вас за месяц и СХД уже может совсем загнуться. Надо договариваться о переносе на дисках. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.08.2021, 07:36 |
|
перенос большой базы на новый сервер
|
|||
---|---|---|---|
#18+
dolya И я заметил. Что дифф бэкап растет очень странно. первые 2 недели он добавляет к дифу по 200 гб в день. Вам же в алгоритме написали "сделать дифф бакап", а не "делать дифф бакап каждый день". Вполне рабочий вариант, если есть деньги на НАС (или он уже есть), с относительно небольшим временем простоя. dolya То есть если я от фула делаю ежедневно дифы Но что то надо и с железом делать, если полный бакап делается несколько дней, иначе слишком долгий простой получается, случись что. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.08.2021, 22:07 |
|
перенос большой базы на новый сервер
|
|||
---|---|---|---|
#18+
авторДенег руководство сказало нет. Нет ручек - нет и варенья (с) анек Перечислить руководству все риски и ждать у моря погоды. Сдохнет так сдохнет. Это же не ваш бизнес. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.08.2021, 09:13 |
|
перенос большой базы на новый сервер
|
|||
---|---|---|---|
#18+
alexeyvg Делайте фулл раз в месяц, и ежедневно бакап лога. Что вообще за любовь у людей у дифф бакапам??? Есть у меня база, ~20 ТБ, запись данных идет очень активно, приходится выполнять backup transaction log file каждые 5 минут , каждый файл ~500 МБ, это с учетом сжатия. Вот и представь, в среднем 12 файлов в час, за сутки - 280 файлов общим размером 14 ГБ. За неделю - около 1600 файлов размером 98 ГБ. Full backup делаю раз в неделю, в ночь с пятницы на субботу, т.е. если мне вдруг понадобится восстановить эту базу по состоянию на утро пятницы, мне придется накатывать около 1500 transaction log файлов. Я же делаю по другому - как уже сказал, full backup раз в неделю, храню неделю. Раз в день diff backup, храню 3 дня, и каждые 5 минут transaction log backup, храню 24 часа. Если придется восстанавливать базу по состоянию на утро пятницы, то мне придется обработать 1 full backup, 1 diff backup и около 120 transaction log backup файлов. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.08.2021, 21:01 |
|
перенос большой базы на новый сервер
|
|||
---|---|---|---|
#18+
flexgen если мне вдруг понадобится восстановить эту базу по состоянию на утро пятницы, мне придется накатывать около 1500 transaction log файлов. Чего бояться больших цифр? 1500 файлов? А в байтах это вообще сума сойти :-) Ну и вопрос к-ва изменений одних и тех же данных - если интенсивно меняются одни и те же данные, то согласен, дифф очень даже ничего. Но обычно жалобы на то, что к концу недели дифф становится ненамного меньше полного бакапа. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.08.2021, 23:45 |
|
перенос большой базы на новый сервер
|
|||
---|---|---|---|
#18+
alexeyvg Чего бояться больших цифр? 1500 файлов? А в байтах это вообще сума сойти :-) ну, в общем случае, быстрее восстановить дифф, чем 1000+ лог бекапов (RTO) имхо, при большом кол-ве файлов выше вероятность/риск получить битый файл ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2021, 10:05 |
|
перенос большой базы на новый сервер
|
|||
---|---|---|---|
#18+
L_argo авторДенег руководство сказало нет. Перечислить руководству все риски и ждать у моря погоды. Сдохнет так сдохнет. Это же не ваш бизнес. Не удастся ТС ждать "сдохнет так сдохнет" и "это же не ваш бизнес" . Судя по его месыджям - его е сделают на всю голову крайним. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2021, 13:11 |
|
перенос большой базы на новый сервер
|
|||
---|---|---|---|
#18+
Ролг Хупин L_argo пропущено... Нет ручек - нет и варенья (с) анек Перечислить руководству все риски и ждать у моря погоды. Сдохнет так сдохнет. Это же не ваш бизнес. Не удастся ТС ждать "сдохнет так сдохнет" и "это же не ваш бизнес" . Судя по его месыджям - его е сделают на всю голову крайним. если он раб лампы , значит заслужил ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2021, 13:50 |
|
перенос большой базы на новый сервер
|
|||
---|---|---|---|
#18+
komrad alexeyvg Чего бояться больших цифр? 1500 файлов? А в байтах это вообще сума сойти :-) ну, в общем случае, быстрее восстановить дифф, чем 1000+ лог бекапов (RTO) имхо, при большом кол-ве файлов выше вероятность/риск получить битый файл ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2021, 18:56 |
|
перенос большой базы на новый сервер
|
|||
---|---|---|---|
#18+
авторНе удастся ТС ждать "сдохнет так сдохнет" и "это же не ваш бизнес" . Судя по его месыджям - его е сделают на всю голову крайним. И чо ? Перейдет в нормальную компанию. Делов то. Почему сотрудники должны ломать голову из-за лютого безденежья говнокомпании ? ... |
|||
:
Нравится:
Не нравится:
|
|||
25.08.2021, 15:48 |
|
|
start [/forum/topic.php?fid=46&msg=40091275&tid=1684375]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
5ms |
check topic access: |
5ms |
track hit: |
133ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
58ms |
get tp. blocked users: |
1ms |
others: | 14ms |
total: | 256ms |
0 / 0 |