Comments 51
Я бы посоветовал еще никогда не проверять бэкапы на валидность. Зачем время тратить? бэкап есть — значит рабочий.
Особенно это касается (раньше так было, незнаю как сейчас) продуктов Acronis, когда там ОБЯЗАТЕЛЬНО нужно делать бекап бекапов!
Двойная трата дискового пространтсва и времени.
В свое время это меня очень бесило и не понимал зачем делать двойной бекап, потом забыл о нем навсегда.
Есть и другие системы резервного копирования.
Двойная трата дискового пространтсва и времени.
В свое время это меня очень бесило и не понимал зачем делать двойной бекап, потом забыл о нем навсегда.
Есть и другие системы резервного копирования.
Мне кажется в основной части этих вопросов проблема даже не в админах, а в руководителях, которые не хотят тратиться на РК, считая что их это никогда не коснётся. Сталкивался с таким несколько раз в небольших компаниях.
да, это отдельная проблема. Вот одна из таких историй, где после того, как прижгло, руководство решило таки инвестировать в инфраструктуру для резервного копирования. https://www.reddit.com/r/sysadmin/comments/63gs2s/update_to_got_hit_bad_tonight/
Вы знаете я как безумный ходил и жаловался КАЖДЫЙ день, что у меня нет диска для резервного копирования. Писал письма. Руководство отмахивалось. И вот в один прекрасный день грохнулся диск. Фирма с оборотом 7млн в день только в 1 офисе встала. Паника была неимоверная. И что вы думаете? Мне сказали: «Это твоя вина. Ты не сумел донести важность».
Про рейд. У знакомого была логика, что рейд это надежно. И что вы думаете? Слетает контроллер. Данные на дисках, но формат рейда никто не понимает (китайский какой, то почти софт рейд)…
Про рейд. У знакомого была логика, что рейд это надежно. И что вы думаете? Слетает контроллер. Данные на дисках, но формат рейда никто не понимает (китайский какой, то почти софт рейд)…
Когда случилось непоправимое на одном из мест моей работы (в рамках политики резервного копирования, впрочем), я задал вопрос про разницу между бэкапом и точкой времени, на которую были потеряны данные и услышал в ответ: «А разницу руками забьют. Сегодня не будут пить чай и обслуживать клиентов, сейчас повесим распечатку и уведомим охрану, чтобы всех приглашали на завтра» оО.
Да, многим руководителям проще заставить кучу людей перепахивать, чем потратить несколько тысяч на простенькую систему, что бы прикрыть тылы. Грустно это.
бизнес ничего личного. зп платится, простой не стоит ничего. а за систему бекапа денег хочет админ. нафиг оно
Это то меня и грустит. А я тут про какие то veeam'ы, datadomain'ы, репликацию резервных копий статьи пишу.......:)
UFO just landed and posted this here
Везде нужно экономические обоснование, которое и есть тот самый "cool factor" для руководства.
А что вас удивляет? — это как раз и есть правильный подход: совместно с руководством определить допустимое время простоя.
Проблема в руководителях только отчасти. Потому что часто проблема в админах, которые на пальцах не могут обосновать необходимость затрат на резервное копирование.
UFO just landed and posted this here
Обновлял периодически 1С на одном военном заводе. Не админ, админа у них нет, просто раз в несколько месяцев обновлял релизы и ставил свежую отчетность.
Периодически говорил: а вот хорошо бы вам под 1С отдельный сервер… Меня не слышали. Зачем? Все же и так работает…
Умер жесткий диск на ПК, где лежала
Периодически говорил: а вот хорошо бы вам под 1С отдельный сервер… Меня не слышали. Зачем? Все же и так работает…
Умер жесткий диск на ПК, где лежала
… где лежала база. Хорошо так умер, похоронив все данные.
Вызывают меня. Я нахожу на другом ПК свой бэкап базы, которую делал перед обновлением. Полугодовой давности.
вызывают директора завода, полковника. Тот смотрит на бухгалтеров и говорит: а мне-то что? Хоть умрите тут. Сидите и восстанавливайте, чтоб все было восстановлено. Настоящий полковник, да.
Бухгалтерия — 5 человек две недели до глубокой ночи забивала в старую базу данные за пол-года с бумажных носителей.
После этого был куплен сервер и настроено автоматическое резервное копирование каждую ночь.
Все замечательно доходит через руки.
Вызывают меня. Я нахожу на другом ПК свой бэкап базы, которую делал перед обновлением. Полугодовой давности.
вызывают директора завода, полковника. Тот смотрит на бухгалтеров и говорит: а мне-то что? Хоть умрите тут. Сидите и восстанавливайте, чтоб все было восстановлено. Настоящий полковник, да.
Бухгалтерия — 5 человек две недели до глубокой ночи забивала в старую базу данные за пол-года с бумажных носителей.
После этого был куплен сервер и настроено автоматическое резервное копирование каждую ночь.
Все замечательно доходит через руки.
Бухгалтерия — 5 человек две недели до глубокой ночи забивала в старую базу данные за пол-года с бумажных носителей.
Сейчас знакомая контора (просто знакомая, я их не обслуживаю) как раз этим самым и занимается, шифровальщика словила, а он им файловые базы 1С обработал.
Бэкапы, теневые копии? Не, мы таких слов не знаем.
Да даже если далеко не ходить — на моей основной работе деньги на сервер бэкапов, про который я говорил и писал два или три года дали только после того, как шифровальщик добрался до главбуха.
UFO just landed and posted this here
Для бекапа файловой 1С вообще достаточно любого архиватора и простейшего скрипта.
Да и SQL-версию можно просто архивировать, если штатно останавливать SQL-сервер перед архивацией и запускать после.
Да и SQL-версию можно просто архивировать, если штатно останавливать SQL-сервер перед архивацией и запускать после.
1С беэкапится несколькими халявными скриптами, не обязательно за них деньги платить.
У файловой просто файлы базы копируешь куда-нибудь, у sql'ной я делаю дампы средствами sql плюс выгрузку в dt'шки средствами 1С.
У файловой просто файлы базы копируешь куда-нибудь, у sql'ной я делаю дампы средствами sql плюс выгрузку в dt'шки средствами 1С.
UFO just landed and posted this here
Вообще по копированию файловых баз я специалист небольшой, у меня их мало и по ночам там никого не бывает, так что всё нормально копируется.
Из sqlной же базы я народ не выгоняю, сперва делаю дамп средствами БД, потом его восстанавливаю рядышком и оттуда уже средствами 1С сливаю dt. В основной базе при этом спокойно продолжают работать.
А вторая копия базы часто пригождается, когда народ хочет поиграться, не трогая основную базу.
На счет версий скрипта — ну разве что при обновлении платформы меняю путь к исполняемому файлу 1С. А sql'ные скрипты вообще не трогаю, там ничего менять не нужно.
Из sqlной же базы я народ не выгоняю, сперва делаю дамп средствами БД, потом его восстанавливаю рядышком и оттуда уже средствами 1С сливаю dt. В основной базе при этом спокойно продолжают работать.
А вторая копия базы часто пригождается, когда народ хочет поиграться, не трогая основную базу.
На счет версий скрипта — ну разве что при обновлении платформы меняю путь к исполняемому файлу 1С. А sql'ные скрипты вообще не трогаю, там ничего менять не нужно.
UFO just landed and posted this here
Не так давно на рынке было полно материнских плат с софт-рейдами и даже NAS-ов, в которых можно было собрать зеркало из дисков. При отказе одного из дисков вы, что логично, меняли дохлый диск на живой, и… ребилда не следовало, потому что функция ребилда рейда реализована не была!
Это в плюс того, что нужно тестировать :)
Это в плюс того, что нужно тестировать :)
Складывайте бэкапы на ту же СХД, где находятся исходные данные
Прямо рекламный слоган NetApp и прочих любителей снепшотов.
Для третьих – после потери базы остается только обратиться к техподдержке вендора (Commvault).
Есть четвёртые, у которых все метаданные хранятся в базе (TSM/Spectrum Protect) и при её утрате даже поддержка не спасёт. RPO базы приходится учитывать задавая срок хранения объёктов в пуле (REUSEDelay), чтобы после её восстановления остались данные на диске.
Все важные обновления, изменения, установки и настройки делайте в пятницу после обеда, а ещё лучше — перед какими-нибудь длинными праздниками (типа новогодних каникул). И со спокойной совестью поезжайте куда-нибудь отдохнуть. Желательно туда, где нет телефонной связи и интернета. :-)
Поделюсь одной весьма полезной штукой, появившейся в последних файловых системах, о которых почему-то пока ещё редко упоминают, говоря о backup.
Преположил, что вы настроили backup, и делаете две копии, и даже offsite, и проверяете их.
Но случилось так, что часть этих данных была удалена / испорчена / отредактирована… НО ЭТО СРАЗУ НЕ ОБНАРУЖИЛИ.
И backup забэкапил скомпроментированные данные. Приплыли…
Так вот в ZFS, BTRFS есть снэпшоты — крутая штука. Позволяет вернуться к состояниям любых файлов в прошлом, для которых есть спэпшоты. Я делаю снэпшоты каждую неделю (хотя можно делать хоть каждые пять минут).
Конечно, совсем правильно делать снэпшоты не на продуктиве, а на бэкапе, но на современных файловых системах снэпшоты практически не тормозят систему и очень удобны.
И да, конечно, снэпшоты — это не бэкап, может быть только полу-бэкап (решает проблему компроментации данных, но не решает потерю физического носителя — дисков или контроллера).
Преположил, что вы настроили backup, и делаете две копии, и даже offsite, и проверяете их.
Но случилось так, что часть этих данных была удалена / испорчена / отредактирована… НО ЭТО СРАЗУ НЕ ОБНАРУЖИЛИ.
И backup забэкапил скомпроментированные данные. Приплыли…
Так вот в ZFS, BTRFS есть снэпшоты — крутая штука. Позволяет вернуться к состояниям любых файлов в прошлом, для которых есть спэпшоты. Я делаю снэпшоты каждую неделю (хотя можно делать хоть каждые пять минут).
Конечно, совсем правильно делать снэпшоты не на продуктиве, а на бэкапе, но на современных файловых системах снэпшоты практически не тормозят систему и очень удобны.
И да, конечно, снэпшоты — это не бэкап, может быть только полу-бэкап (решает проблему компроментации данных, но не решает потерю физического носителя — дисков или контроллера).
Интересный момент с RAID 10 — как конкретный контроллер понимают эту 10-ку,
0+0=1 или 1+1=10 этот момент не описывается в документации. иногда может быть важен.
0+0=1 или 1+1=10 этот момент не описывается в документации. иногда может быть важен.
Обычно видно в админке. Но особой разницы нет, всё равно вылет двух винтов может пережить только с определенными оговорками, просто на оба варианта оговорки будут разные. :)
Не совсем так raid10 переживает вылет 2-ух дисков в разных парах, а raid 01 — при вылете одного. Второй вылет в другой паре для него фатален, так как первый страйп уже развалился.
10 — страйп зеркал, информация переживёт вылет одного диска в каждой паре, умрёт, если вылетят оба диска в одной паре.
01 — зеркало страйпов, информация переживёт вылет двух дисков в одной паре, умрёт при вылете двух дисков в разных парах.
PS. Это про четыре диска в массиве, конечно. При большем количестве дисков математика уже немного другая начинается.
01 — зеркало страйпов, информация переживёт вылет двух дисков в одной паре, умрёт при вылете двух дисков в разных парах.
PS. Это про четыре диска в массиве, конечно. При большем количестве дисков математика уже немного другая начинается.
Написал потому, что видно одно, а по факту другое. Документация хорошо, а эксперимент — всему голова. Накатил систему, потом проверь. У меня был сервак, который не пережил вылет одного из четырех дисков.
А как проверить? Вот у меня в админке видны два зеркала в страйпе. Как мне убедиться, что всё устроено именно так, а не два страйпа в зеркале?
Со временем почти все приходят к мысли сначала тестировать на тестовой сборке, а уж потом выносить в продакшн. Т.е. условно говоря — взяли сервер, собрали RAID, накатили боевые базы и софт (из бэкапа, хе-хе), прогнали на все возможные варианты крэша, потом снесли начисто всё, и заново установили, настроили, перенесли базы… и в продакшн. ))
По стандарту RAID10 — это RAID0 из RAID1, а RAID01 — наоборот.
У меня как раз на днях вылетел один из дисков в десятом рэйде, а менеджер рейдов мне не сообщил. Заметил случайно, когда память в сервере добавлял. Посмотрел потом в менеджере — он видел, что диск вылетел, но считал это нормальным состоянием, зеленые галочки и всё такое. Похоже, что софтовый глюк в старой версии. После обновления сразу заорал о том, что всё плохо, диск снимают, клиент уезжает.
Во вредном совете 4 случай из реальной жизни (чистейшая административная ошибка/несогласованность действий) не имеет ни малейшего отношения к системам автоматизированной проверки корректности бэкапа. В частном случае к Veeam Sure Backup.
В этом случае из жизни проверка корректности бэкапа будет пройдена успешно.
Это примерно как рассчитывать на устранение пользовательской ошибки работы с БД средствами RAID'а
В этом случае из жизни проверка корректности бэкапа будет пройдена успешно.
Это примерно как рассчитывать на устранение пользовательской ошибки работы с БД средствами RAID'а
К 4-му пункту еще одна история:
Упал интернет-магазин, есть бекап месячной давности (!), но из него восстановить базу не получается — что-то как-то сильно ругается и процесс обрывается даже не воссоздав всю схему данных. Клиент обратился ко мне — выяснил, что в бекапе 4 или 5 таблиц закольцованы по foreign key. Кто, где, когда и почему так сделал — неизвестно, т.к. модернизацией магазина занимались за все его жизнь несколько команд «разработчиков» с Upwork и никто документацию не вел. Отдельного бекапа схемы данных конечно тоже нет.
Пока вытащил схему данных из бекапа (к упавшему продакшену доверия нет), руками закомментировал эти ключи, восстановил схему, восстановил закольцованные ключи (зачем они? пусть разработчики разбираются — я тикет оставил), накатил данные из бекапа… Магазин не работал больше 16 часов (из них на меня пришлось почти 6 часов, из которых 2,5 часа ушло на операцию восстановления данных).
Через 4 месяца заглянул на тот сервер: бекапы собираются примерно раз в месяц в ручном режиме, закольцованные ключи на месте… Скорее всего этот магазин станет моим постоянным клиентом :)
Упал интернет-магазин, есть бекап месячной давности (!), но из него восстановить базу не получается — что-то как-то сильно ругается и процесс обрывается даже не воссоздав всю схему данных. Клиент обратился ко мне — выяснил, что в бекапе 4 или 5 таблиц закольцованы по foreign key. Кто, где, когда и почему так сделал — неизвестно, т.к. модернизацией магазина занимались за все его жизнь несколько команд «разработчиков» с Upwork и никто документацию не вел. Отдельного бекапа схемы данных конечно тоже нет.
Пока вытащил схему данных из бекапа (к упавшему продакшену доверия нет), руками закомментировал эти ключи, восстановил схему, восстановил закольцованные ключи (зачем они? пусть разработчики разбираются — я тикет оставил), накатил данные из бекапа… Магазин не работал больше 16 часов (из них на меня пришлось почти 6 часов, из которых 2,5 часа ушло на операцию восстановления данных).
Через 4 месяца заглянул на тот сервер: бекапы собираются примерно раз в месяц в ручном режиме, закольцованные ключи на месте… Скорее всего этот магазин станет моим постоянным клиентом :)
Sign up to leave a comment.
Вредные советы по настройке резервного копирования и несколько баек