Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 133
Какой-то уж ну очень вольный перевод.
Название статьи конечно провокационное :)
> FAT32… 2 Гб
Лимит размера файла на FAT32 — 4 Гб, а не 2.
> FAT32… 2 Гб
Лимит размера файла на FAT32 — 4 Гб, а не 2.
В оригинале так и было, а я не обратил внимание. Поправил, спасибо вам за замечание!
В оригинале, скорее всего, имелась ввиду FAT16. Может, он на SD-карту копировал :)
Я бы не желал никому восстанавыливать бекапы. Лучше это сформулировать как «Научитесь делать бекапы, которые вы потом сможете восстановить».
На самом деле, когда-то тут проскальзывала статья с похожей тематикой и там напрямую советовали регулярно проводить, так сказать, «учения» — восстанавливать последний бэкап на некую специально выделенную машину. Вы считаете, что это излишне?
Я считаю что цель — научиться восстанавливать бекапы быстро и с минимизацией негативных последствий, а не восстанавливать бекапы просто так.
Естественно, для обучения надо бы несколько раз прогнать процедуру, но это не цель, это задача.
Естественно, для обучения надо бы несколько раз прогнать процедуру, но это не цель, это задача.
В идее регулярных учений, возможно, может крыться задача не только научиться восстанавливать (это, естественно, в любом случае, на первом месте), но и регулярно проверять — а собственно, бэкапится ли все как нужно или все бэкапы за последний месяц (полгода? год?) битые и из них восстановиться нельзя, как мне кажется.
Вообще, хорошо бы настроить автоматические процедуры бекапа и восстановления и время от времени прогонять юнит-тесты: «сделали бекап — восстановили на другую машину — проверили доступность сервисов (открываются ли странички, есть ли доступ к базе и т.д.)». Потому что просто один или даже несколько раз прогнать процедуру — не панацея, завтра может что-то измениться в сервере (или его окружении) и когда-то проверенные и работающие процедуры бекапа\восстановления могут оказаться нерабочими.
Не знаю, существую ли такие решения, но идея весьма интересная.
«Не знаю, существую ли такие решения»
На самом деле, написать скрипт, который ежедневно собирает на другом сервере копию сайта из бэкапа базы и файлов, не так уж сложно.
У меня на бэкапах, кстати, основана система «билдов» для программистов. Через веб-интерфейс программист выбирает ветку svn, которую надо накатить поверх чистой копии сайта и, вуаля, появляется build_number_.sitename.com.
И вот, первый билд, собирается ежедневно из копии боевого сайта. В случае, если что-то в бэкапе не так, програмисты и тестеры сразу видят и сообщают админу.
На самом деле, написать скрипт, который ежедневно собирает на другом сервере копию сайта из бэкапа базы и файлов, не так уж сложно.
У меня на бэкапах, кстати, основана система «билдов» для программистов. Через веб-интерфейс программист выбирает ветку svn, которую надо накатить поверх чистой копии сайта и, вуаля, появляется build_number_.sitename.com.
И вот, первый билд, собирается ежедневно из копии боевого сайта. В случае, если что-то в бэкапе не так, програмисты и тестеры сразу видят и сообщают админу.
иногда единственный способ проверить работоспособность — это восстановить бекап
Хороший пример — Firebird: может быть так, что вы базу успешно забекапите (gbak отрабатывать без ошибок), а при попытке восстановления этого бекапа этот же самый gbak будет падать. Это значит, что база, которую бекапили, была чуток битая.
И поэтому пришлось писать скрипт, который бекапит, разворачивает, присоединяется к временной базе, выполняет кой-какие тесты там, и только если всё произошло без ошибок — архивирует бекап и удаляет временную базу.
Хороший пример — Firebird: может быть так, что вы базу успешно забекапите (gbak отрабатывать без ошибок), а при попытке восстановления этого бекапа этот же самый gbak будет падать. Это значит, что база, которую бекапили, была чуток битая.
И поэтому пришлось писать скрипт, который бекапит, разворачивает, присоединяется к временной базе, выполняет кой-какие тесты там, и только если всё произошло без ошибок — архивирует бекап и удаляет временную базу.
Давно хочу в виде теста прогнать тушение какого-то объекта из огнетушителя. Многие тут что-то тушили огнетушителем? )
Процедура похожа на процедуру учения по восстановлению из бекапа.
Процедура похожа на процедуру учения по восстановлению из бекапа.
У нас иногда проводятся учения по безопасности. Всем желающим предлагается поюзать огнетушитель. Мне лично не интересно, но мои коллеги развлекались.
Насколько я знаю, у пожарных регулярно проводятся не только учения, но и соревнования по тушению огня с помощью огнетушителя — это их работа, по-моему, ровно такая же, как работа админа (и примерно с таким же акцентом на «лучше бы этой работы не было») восстанавливать бэкапы.
Огнетушителем должен уметь на практике пользоваться любой и каждый. У каждого автовладельца в транспортном средстве есть огнетушитель. Но в экстренных ситуациях можно даже забыть, как его открыть или взяться рукой за то, за что браться нельзя, также можно причинить огнетушителем вред себе. Даже в каждом доме должен быть огнетушитель, и посерьезнее, чем в автомобиле.
Кстати, для справки — когда машина начинает гореть, то штатный огнетушитель зачастую бессилен.
Кстати, для справки — когда машина начинает гореть, то штатный огнетушитель зачастую бессилен.
Насчет пользоваться каждому — да, согласен, но это не требует проведения ежемесячных учений и сводится скорее к «не хвататься рукой вот за это» и «в огонь направлять этим». А у специализированных служб, я думаю, диапазон знаний по применению даже обычного, для машины, огнетушителя гораздо шире и используют они его гораздо эффективнее.
Теории тут недостаточно. Когда человек видит и чувствует пожар, он все забывает, даже телефон пожарной службы.
Я имел в виду практику как раз. Скорее заострял внимание на отсутствии глубоких знаний о тушении различных пожаров наиболее эффективным путем, которым учат специалистов.
Именно для этого вешаются информационные таблички с телефонами пожарных служб, планом эвакуации, направления выходов, местоположения средств связи и тушения.
Так же и с бэкапами. Админ не должен начинать паниковать в случае даже самого эпичного фейла, он должен следовать отработанной инструкции.
Так же и с бэкапами. Админ не должен начинать паниковать в случае даже самого эпичного фейла, он должен следовать отработанной инструкции.
Огнетушители во всех организациях, как и прочие средства тушения и эвакуации периодически проверяются специальным гос.органом, и это документируется. Делается это не потому что кому-то хочется быть готовым к пожару, а потому что за неисполнение закона грозит крупный штраф. И бэкапы грамотно делать и проверять будут видимо только тогда, когда будут серьезно наказывать за их отсутствие или непригодность. Это проблема менталитета.
>Это проблема менталитета.
Что Вы к менталитету привязались? Проблема никакого отношения к менталитету не имеет. Менталитет у нас отличный. Была бы проблема в этом, Гагарин не долетел бы в космос — там ого-го сколько всего надо было проверить.
Что Вы к менталитету привязались? Проблема никакого отношения к менталитету не имеет. Менталитет у нас отличный. Была бы проблема в этом, Гагарин не долетел бы в космос — там ого-го сколько всего надо было проверить.
Менталитет тут, действительно, вряд ли причем. Скорее просто общечеловеческая лень — лень изучать новое, менять какие-то процессы, делать лишнюю работу, пока «итак все хорошо». Но регулируется это действительно только одним — серьезными штрафами за неисполнение (ну, положим, на государственном уровне, как с огнетушителями — перебор, а вот на уровне компании — возможно). Но тогда, опять же, должен быть некий «гуру бэкапов», минимум один на уровень, на котором введены штрафы, который создаст эту спецификацию.
Кроме штрафов надо прививать осознание серьезности ситуации. Как пример — пристегивание ремнями безопасности («а сзади зачем пристегиваться?»). Надо донести, а там уже штрафы будут как сопровождающая мера. Люди оторваны от реальности и не верят, что ппц может наступить в любую минуту ).
>… лень изучать новое, менять какие-то процессы, делать лишнюю работу, пока «итак все хорошо».
Именно это я и подразумеваю под менталитетом.
>… должен быть некий «гуру бэкапов», минимум один на уровень, на котором введены штрафы, который создаст эту спецификацию
Специалист по защите информации. Это ведь тоже вопрос информационной безопасности.
Именно это я и подразумеваю под менталитетом.
>… должен быть некий «гуру бэкапов», минимум один на уровень, на котором введены штрафы, который создаст эту спецификацию
Специалист по защите информации. Это ведь тоже вопрос информационной безопасности.
Менталите́т (фр. Mentalité, нем. Mentalität от позднелат. mentalis — умственный) — в традиционном значении «менталитет» синонимичен слову «ментальность» и подразумевает (как правило, в социологических контекстах) тот или иной «склад ума», то есть устойчивые интеллектуальные и эмоциональные особенности, присущие тому или иному индивиду (обычно как представителю некоторой социальной группы). Однако чаще всего слово употребляется в контексте именно социальной общности (нация, народ, этнос, и т. д.). ©Wiki
Лично для меня менталитет это отсылка к различным фразам стиля «только русские/американцы/..», к которым эта ситуация все-таки мало относится. Поэтому и возразил, пытаясь уточнить формулировку.
Лично для меня менталитет это отсылка к различным фразам стиля «только русские/американцы/..», к которым эта ситуация все-таки мало относится. Поэтому и возразил, пытаясь уточнить формулировку.
Заранее прошу меня простить, но боюсь, я уже перехожу на личности. Проверка бэкапов по времени соразмерима с выполнением полного бэкапа, более того, этот процесс автоматизирован чуть менее, чем полностью. Если для Вас это «ого-го», то для меня это стандартная рабочая задача. Не нужно просто лениться и надеяться на «авось».
Гагарин, слава всему, слетал успешно, но были проблемы. Например, скафандр был ему немного не по размеру, великоват. Это привело к тому, что при выходе из спускаемого аппарата он на пару минут остался без воздуха, т.к. снять скафандр самостоятельно было очень трудно, и его внутренняя система воздухообмена была в тот момент штатно отключена. Если бы это проверили заранее, проблем бы не возникло.
Гагарин, слава всему, слетал успешно, но были проблемы. Например, скафандр был ему немного не по размеру, великоват. Это привело к тому, что при выходе из спускаемого аппарата он на пару минут остался без воздуха, т.к. снять скафандр самостоятельно было очень трудно, и его внутренняя система воздухообмена была в тот момент штатно отключена. Если бы это проверили заранее, проблем бы не возникло.
Все же чтобы время проверки бэкапа было соизмеримым со временем его создания, надо много времени потратить на эту автоматизацию проверки. Для Вас это не «ого-го», потому что Вы уже «занесли пальцы над нужными клавишами».
У Гагарина не все гладко было, да, и проблемы были посерьезнее скафандра, была проблема ухода с орбиты. Но вы осознайте масштаб трагедии — все должно было заработать с первого раза в условиях, где ничего исправить уже нельзя было. И заработало.
У Гагарина не все гладко было, да, и проблемы были посерьезнее скафандра, была проблема ухода с орбиты. Но вы осознайте масштаб трагедии — все должно было заработать с первого раза в условиях, где ничего исправить уже нельзя было. И заработало.
Есть такая поговорка:«Велика беда — начало». В любом случае, организовать бэкапы не просто. На прошлом месте работы я потратил на организацию резервного копирования два дня (выходные) с полной остановкой всех сервисов, потом еще неделю на отладку в рабочем режиме. Так вот, за первые пару дней я настроил только копирование рабочих данных и слил образы системных томов. Еще неделю я потратил на проверку работоспособности этих бэкапов и поиск наилучшего метода их развертывания. Тогда внезапно появилась проблема восстановления системных томов из образа, утилита резервного копирования не видела серверы. Вот это было «ого-го». А сейчас после снятия бэкапов, они тут же выкладываются на запасной сервер, на котором выполняется их проверка целостности, а предыдущая их копия уходит в архивное хранилище. Вот это уже быстро и без напрягов. В случае фейла основного сервера я просто переставлю адрес на запасном)
Проверять устройства — не то же, что проверять умение ими пользоваться.
Да что там огнетушители: у многих представителей «офисного планктона» в резюме значится «уверенное знание компьютера, офиса» и чуть не Corel с Photoshop-ом. А потом этот планктон начинает службу ИТ дергать с просьбами настолько тупыми, что даже приводить не буду примеры.
Так что — учения, учения и учения, и неважно, что кому-то неинтересно огнетушитель брать в руки, важно, чтобы во время пожара им смогли воспользоваться уверенно и грамотно.
То же и с бекапами )
Да что там огнетушители: у многих представителей «офисного планктона» в резюме значится «уверенное знание компьютера, офиса» и чуть не Corel с Photoshop-ом. А потом этот планктон начинает службу ИТ дергать с просьбами настолько тупыми, что даже приводить не буду примеры.
Так что — учения, учения и учения, и неважно, что кому-то неинтересно огнетушитель брать в руки, важно, чтобы во время пожара им смогли воспользоваться уверенно и грамотно.
То же и с бекапами )
Нормальный софт (Veritas, CommVault, Tivoli) после грамотной настройки проверять не нужно, другое дело, что платить за него готовы далеко не все.
Помню скончался винт на серваке с системой, бэкап был сделан давненько. Вот я замучался его восстанавливать на новый винт, т.к. бэкап делался довольно старой версией одной программы, а новые версии не поддерживали этот бэкап-файл, много времени ушло на поиск нужной версии.
Кстати вопрос в тему — что конкретно (и как) бекапить в линуксе, чтобы при смерти сервера быстро восстановить систему со всеми установленными программами и настройками на другом сервере.
Вот у меня например ubuntu server стоит — как забекапить моё web приложение и базу понятно, а вот что делать с программами? Если я забекаплю только конфиги, то мне надо будет на новом все вручную ставить и потом только накатывать конфиги — это долго может быть и проблематично. Нет ли простого решения для восстановления уже установленных приложений?
Важная деталь — делать всё надо без физического доступа к машине)
Вот у меня например ubuntu server стоит — как забекапить моё web приложение и базу понятно, а вот что делать с программами? Если я забекаплю только конфиги, то мне надо будет на новом все вручную ставить и потом только накатывать конфиги — это долго может быть и проблематично. Нет ли простого решения для восстановления уже установленных приложений?
Важная деталь — делать всё надо без физического доступа к машине)
PS: Прошу прощения за нубство в администрировании - я больше по веб разработке
Раз в месяц:
tar -cf /backup.tar / --exclude-path=/backup.tar
:)
tar -cf /backup.tar / --exclude-path=/backup.tar
:)
Что-то мне подсказывает, что всё не так просто)
Серьезно, я так сервер переносил не раз
Ну, еще sys proc и т.д. нужно убрать
И /dev еще наверное?
После такого переноса всяких неприятностей случиться не может, типа разрушения зависимостей или неработоспособности на другом железе?
После такого переноса всяких неприятностей случиться не может, типа разрушения зависимостей или неработоспособности на другом железе?
«записать загрузчик» — можно пояснить? В рамках данной конкретной темы…
Опять же учитывая, что у нас нет физического доступа, а есть только SSH с рутом.
Опять же учитывая, что у нас нет физического доступа, а есть только SSH с рутом.
Я имел в виду, что способ «tar -cf /backup.tar / --exclude-path=/backup.tar» — вполне себе рабочий.Только с оговоркой, что на целевой машине совпадают: конфигурация таблицы разделов диска и соответствующие точки монтирования. Ведь вышеозвученный способ скопирует также и /etc/fstab, и содержимое /boot/grub — всё это может не совпадать с тем, что настроено на целевой машине. Разве нет?
Интересней (универсальней) было бы привести полный листинг команды для бэкапа: с сохранением boot-партиции, MBR и всей информации о логических разделов, только здесь уже будет не обойтись без sfdisk и dd.
Вопрос же звучал конкретно:
что конкретно (и как) бекапить в линуксе, чтобы при смерти сервера быстро восстановить систему со всеми установленными программами и настройками на другом сервере.
А какой способ лучше?
Сейчас из всего вышесказанного я понял, что для бекапа на убунте надо делать так:
1. Строим список установленных прог:
2. Дампим базы данных в файл.
3. Бэкапим все настройки приложений (/etc), данные юзеров (/home), по желанию что-то нужное из (/var), возможно /root (?), а также сдампленные на шагах 1 и 2 данные на удаленный сервер, с помощью того же rsync ( я для себя выбрал rsnapshot).
Для восстановления:
1. Восстанавливаем систему на сервере.
2. Уставливаем все пакеты, которые сграбили на этапе 1 бэкапа коммандой:
3. Восстанавливаем все что мы забекапили на этапе 3.
4. Импортируем бекапы базы данных.
5. Проверяем работоспособность сервера и развернутых приложений.
Поправьте пожалйста, если не прав!
Сейчас из всего вышесказанного я понял, что для бекапа на убунте надо делать так:
1. Строим список установленных прог:
dpkg --get-selections > packages.txt2. Дампим базы данных в файл.
3. Бэкапим все настройки приложений (/etc), данные юзеров (/home), по желанию что-то нужное из (/var), возможно /root (?), а также сдампленные на шагах 1 и 2 данные на удаленный сервер, с помощью того же rsync ( я для себя выбрал rsnapshot).
Для восстановления:
1. Восстанавливаем систему на сервере.
2. Уставливаем все пакеты, которые сграбили на этапе 1 бэкапа коммандой:
dpkg --clear-selections
dpkg --set-selections < packages.txt
aptitude install3. Восстанавливаем все что мы забекапили на этапе 3.
4. Импортируем бекапы базы данных.
5. Проверяем работоспособность сервера и развернутых приложений.
Поправьте пожалйста, если не прав!
Полностью согласен насчет дроблений! Вот только rsync«ом наверное все же выгоднее будет бекапить не архивами, а в живую, чтобы лишнее место не занимать, т.к. система на хардлинках построена.
Спасибо за намётку про бакулу, но пока, как сказал, решил пользоваться rsync, т.к. сервер пока один. Хотя надеемся что после анонса на хабре проект получит бурный рост и придется столкнуться с маштабированием)
Спасибо за намётку про бакулу, но пока, как сказал, решил пользоваться rsync, т.к. сервер пока один. Хотя надеемся что после анонса на хабре проект получит бурный рост и придется столкнуться с маштабированием)
Пункт 1 (дополнение)
Для Gentoo
Для Red Hat / Fedora / Suse / Cent OS
Для Gentoo
qlist -CU > packages.txtДля Red Hat / Fedora / Suse / Cent OS
rpm -qa > packages.txtНа мой скромный взгляд, чтобы восстановиться быстро на «другом» сервере нужно еще добавить (до списка установленных прог):
1. Архивацию /boot
2. Бэкап MBR (Master Boot Record)
3. Бэкап всей информации о разделах
Вот тогда ваш пункт «Восстанавливаем систему на сервере» будет более полным.
1. Архивацию /boot
2. Бэкап MBR (Master Boot Record)
dd if=/dev/sda of=mbr.backup count=1 bs=5123. Бэкап всей информации о разделах
sfdisk -d /dev/sda > partitions.backupВот тогда ваш пункт «Восстанавливаем систему на сервере» будет более полным.
Спасибо! Но насколько я понимаю без отсутствия физ. доступа к серверу это мало что даёт?
Можете по подробнее рассказать, что это даёт и что как потом восстановить от туда?
Я больше программист и пока с таким сталкиваться не приходило просто)
Можете по подробнее рассказать, что это даёт и что как потом восстановить от туда?
Я больше программист и пока с таким сталкиваться не приходило просто)
Точнее с его отсутствием :)
Да, вы правы. И, к тому же, я как и вы разработчик и тоже пытаюсь составить для себя полную картину для переноса веб-приложения вместе с установленным софтом (и с настройками ОС) на другой, удаленный, сервер.
Да, вы правы. И, к тому же, я как и вы разработчик и тоже пытаюсь составить для себя полную картину для переноса веб-приложения вместе с установленным софтом (и с настройками ОС) на другой, удаленный, сервер.
Да, простите, ошибся — с отсутствием доступа)
Ну я пока 2 варианта увидел — либо использовать виртуализацию и оперировать снапшотами системы, что мне не очень нравится идеологически (если только это не облачные вычисления), либо работать по написанной чуть выше схеме в полуавтоматическом режиме)
PS: Наш хостер вроде обещался наш образ системы с VPS перенести на физ. сервер без проблем сам.
Ну я пока 2 варианта увидел — либо использовать виртуализацию и оперировать снапшотами системы, что мне не очень нравится идеологически (если только это не облачные вычисления), либо работать по написанной чуть выше схеме в полуавтоматическом режиме)
PS: Наш хостер вроде обещался наш образ системы с VPS перенести на физ. сервер без проблем сам.
что это даёт и что как потом восстановить от туда?Только если это передать админу, имеющего физический доступ к телу. Чтобы он разбил диск, создал партиции и их примонтировал точно также как это сделано на нашем сервере.
Удалённо я думаю — никак. Это актуально только в случае имеющегося физического доступа к серверу.
Нет, наоборот. Я бывало одну и туже систему несколько раз через тар прогонял :)
Тут можно почитать:
www.aboutdebian.com/tar-backup.htm
И да, /dev убирать не нужно
Тут можно почитать:
www.aboutdebian.com/tar-backup.htm
И да, /dev убирать не нужно
Раз в день!
Выглядит гениально! А как на деле?
Что должно быть установлено на сервере уже, где мы развернем этот архив?
По меньшей мере, ОС и установленный SSH. Должна ли совпадать версия ОС в архиве и на новом сервере? Что будет с автозагрузкой на новом сервере?
Что должно быть установлено на сервере уже, где мы развернем этот архив?
По меньшей мере, ОС и установленный SSH. Должна ли совпадать версия ОС в архиве и на новом сервере? Что будет с автозагрузкой на новом сервере?
Да, и еще вопрос. Разве таким «макаром» перенесётся БД? Насколько я понимаю, просто так эти данные нельзя взять с файловой системы (или я ошибаюсь)?
В GNU/Linux для всех программ обычна файлопомойка, так что однозначного решения нет и не будет кроме как использование сторонних решений по автоматизированному управлению и восстановлению конфигураций.
На FreeBSD для программ есть только одно место — каталог /usr/local. База данных установленных программ — каталог /var/db/pkg. Файловые системы UFS2 или ZFS, которые отводятся под эти каталоги, как правило, обладают способностью иметь снимки, что положительно сказывается на операбельности процедур бэкапа — dump и zfs snapshot && zfs send, так и восстановления — restore и zfs receive || zfs rollback, соответственно.
На FreeBSD для программ есть только одно место — каталог /usr/local. База данных установленных программ — каталог /var/db/pkg. Файловые системы UFS2 или ZFS, которые отводятся под эти каталоги, как правило, обладают способностью иметь снимки, что положительно сказывается на операбельности процедур бэкапа — dump и zfs snapshot && zfs send, так и восстановления — restore и zfs receive || zfs rollback, соответственно.
А посмотрите puppet || chef || cfengine
С помощью них как раз и можно настроить заливку новых образов и управление конфигурацией текущими.
С помощью них как раз и можно настроить заливку новых образов и управление конфигурацией текущими.
Если я забекаплю только конфиги, то мне надо будет на новом все вручную ставить и потом только накатывать конфиги — это долго может быть и проблематично.Во время бакапа:
dpkg --get-selections > packages.txtВо время восстановления:
dpkg --clear-selections
dpkg --set-selections < packages.txt
aptitude install
Конечно, лучший вариант — ставить с нуля и подставлять конфиги.
Но иногда бывает, что перекомпилишь программу с изменением какой-нибудь мелочи (как длина аргументов например в комманде), запишешь поверх пакаджа и забываешь. Для этого либо тар, либо дамп в БСД.
Причем для ускорения процесса лучше использовать мультипроцессорный архиватор.
Но иногда бывает, что перекомпилишь программу с изменением какой-нибудь мелочи (как длина аргументов например в комманде), запишешь поверх пакаджа и забываешь. Для этого либо тар, либо дамп в БСД.
Причем для ускорения процесса лучше использовать мультипроцессорный архиватор.
Собственно, из-за сложности поэтапного восстановления сервера(-ов) и этого растет популярность вирт. серверов — бекап вирт. машины (через снапшот хранилища) прост, а восстановить ее можно на любом, не обязательно точно таком же в смысле «железа» сервере (внутри ВМ все будет то же). Заодно тестирование восстановления куда проще.
Снапшоты не отвечают за консистентность данных внутри ВМ.
Смотря как они делаются. :)
Но Вы учтите, что бекапы отдельных конфигов + экспорты веток реестра/настроек и прочего — все это также с хорошим шансом может оказаться неконсистентно, т.к. делаться они будут также с «живой» системы, и почти наверняка не в один момент. И узнаем мы об этом только в момент восстановления.
Зато образ, даже тупо скопированный со снапшота, почти наверняка позвол после восстановления машину хотя бы просто запустить. А уж если хочется не тупо, то надо смотреть возможности бекапа в конкретной экосистеме гипервизора: у промышленных решений все будет априори нормально, хотя и не задешево, у «наколенных» сборок — пусть сборщик расскажет, как :).
В любом случае здесь есть путь развития, не худший «обычного» бекапа. А уж подробности реализации… от опыта и рук персонала зависят.
Я про то, что вместо, можно сделать (конечно, принятым и возможным для данного гипервизора способом) образ всей системы.
Но Вы учтите, что бекапы отдельных конфигов + экспорты веток реестра/настроек и прочего — все это также с хорошим шансом может оказаться неконсистентно, т.к. делаться они будут также с «живой» системы, и почти наверняка не в один момент. И узнаем мы об этом только в момент восстановления.
Зато образ, даже тупо скопированный со снапшота, почти наверняка позвол после восстановления машину хотя бы просто запустить. А уж если хочется не тупо, то надо смотреть возможности бекапа в конкретной экосистеме гипервизора: у промышленных решений все будет априори нормально, хотя и не задешево, у «наколенных» сборок — пусть сборщик расскажет, как :).
В любом случае здесь есть путь развития, не худший «обычного» бекапа. А уж подробности реализации… от опыта и рук персонала зависят.
Я про то, что вместо, можно сделать (конечно, принятым и возможным для данного гипервизора способом) образ всей системы.
Восстановление из полной копии всё же более стандартная процедура нежели из снапшота СХД, во время создания которого половина файлов может ждать записи в кэше ОС.
Прозвучит банально — но ведь и кошек, в анекдоте, рекомендовалось уметь готовить.
Мне думается, не только СХД и не только ОС можно и нужно готовить, но в умелых руках оно неплохо готовится и позволяет отличные целостные бекапы делать.
Зато, в качестве бонуса, получаем (почти) независимые от содержимого машины бекапы. Причем неважно, какие функции вертятся внутри. В случае с физическими серверами вопросов (может быть) больше.
Мне думается, не только СХД и не только ОС можно и нужно готовить, но в умелых руках оно неплохо готовится и позволяет отличные целостные бекапы делать.
Зато, в качестве бонуса, получаем (почти) независимые от содержимого машины бекапы. Причем неважно, какие функции вертятся внутри. В случае с физическими серверами вопросов (может быть) больше.
[баян моде он]
люди делятся на 3 категории: которые ещё ничего не потеряли, которые делают бэкапы, и 3 категория — которые проверяют как восстанавливаются бэкапы.
[баян моде офф]
люди делятся на 3 категории: которые ещё ничего не потеряли, которые делают бэкапы, и 3 категория — которые проверяют как восстанавливаются бэкапы.
[баян моде офф]
Amazon S3
Я сомневаюсь в том, что «Let's Stop Talking About Backups» уместно перевести как «перестаньте делать бэкапы». Скорее уж «хватит говорить о бэкапах», разве не так?
Унылая тема.
Кому надо тот забекапится и восстановится.
Кому надо тот забекапится и восстановится.
И если вы можете восстановить свой сайт в таких условиях — значит вы правильно делаете бэкапы.
Так что перестаньте просто делать бэкапы. Начните их восстанавливать.
Капитан?
Мысль о том, что «недостаточно делать бэкапы, а быть уверенными в том, что они в нужный момент восстановятся», статьей назвать трудно. Но как напоминание лишний раз не помешает.
Заголовок удивил. Не являясь администратором зашел почитать, а тут такое резюме, аж разочаровался.
Тест на восстановление данных — часть процесса настройки бекапов. Не очень понятно зачем этот материал, еще и неидеально переведенный :)
Еще один совет: оставлять несколько версий бекапов.
Т.е. не только за сегодня, но и за вчера, позавчера и неделю назад, т.к. может произойти что-либо с сайтом, а повреждения будут обнаружены уже когда всё попадёт в бекап и восстановление может оказаться бесмыссленным. Т.е. наличие бекапа за вчера — это не панацея.
Т.е. не только за сегодня, но и за вчера, позавчера и неделю назад, т.к. может произойти что-либо с сайтом, а повреждения будут обнаружены уже когда всё попадёт в бекап и восстановление может оказаться бесмыссленным. Т.е. наличие бекапа за вчера — это не панацея.
Я не понял, делать бэкапы или не делать. Это важно!
Мы для бекапов специально взяли безлимитный хостинг в Штатах, куда сливаются абсолютно все наши сайты. За последний год это спасало не раз. Система бекапов панели ISP позволяет хранить разные версии бекапов сайта. Сейчас у большинства сайтов настроена такая система:
Бекап сайта сливается каждый день. Если начинается новая неделя — удаляется все бекапы кроме одного. Если начинается новый месяц — удаляются все бекапы кроме одного.
Таким образом мы имеем бекап за каждый месяц работы сайта, за каждую неделю текущего месяца и за каждый день текущей недели.
Бекап сайта сливается каждый день. Если начинается новая неделя — удаляется все бекапы кроме одного. Если начинается новый месяц — удаляются все бекапы кроме одного.
Таким образом мы имеем бекап за каждый месяц работы сайта, за каждую неделю текущего месяца и за каждый день текущей недели.
А можно поинтересоваться, проводятся ли проверки тех бэкапов, которые вы оставляете? Если проводится, то сколько времени вы считаете, что бэкап точно рабочий? При каких-то изменениях на серверах вы заново проводите проверку бэкапов?
Примерно раз в месяц-два мы выборочно проверяем работоспособность и целостность нескольких бекапов. Так как в основном наши сайты лежат на разных VPS на Debian с панелью ISP одинаковых версий — можно сказать что проверив даже по 1 бекапу с каждого сервера можно быть уверенным, что остальные рабочие на 99%. За два года работы эта схема ни разу не подвела.
Просьба сменить заголовок статьи с «от балды» на нормально переведенный заголовок типа «перестаньте говорить о бэкапах»
Банальность все-же habrastorage.org/storage1/b8ef9be1/67c1e381/2ca10012/0cdd913b.jpg
По шее надо давать за такие заголовки. Такое только для дешевой газеты простительно.
Газета: Я увидел заголовок. Подумал: фигасе. Купил. Расстроился. Но деньги уже уплачены. PROFIT.
Интернет: Я увидел заголовок. Подумал: фигасе. Расстроился. Теперь я о вас плохого мнения и читать не буду.
P.S.
Да, я знаю, что это перевод. Заметил.
Газета: Я увидел заголовок. Подумал: фигасе. Купил. Расстроился. Но деньги уже уплачены. PROFIT.
Интернет: Я увидел заголовок. Подумал: фигасе. Расстроился. Теперь я о вас плохого мнения и читать не буду.
P.S.
Да, я знаю, что это перевод. Заметил.
Проблем с бекапами практически никогда не возникает, если размер бекапа меньше 10гб…
Но если у тебя каждый день надо делать бекап с продакшен сервера с размером бекапа больше 100гб.
То система бекапов становится самым уязвимым местом. К примеру надо экспортировать из базы данных 100гб данных и нельзя останавливать сервер, то экспорт данных будет длится очень-очень долго и может не закончится за несколько часов… Пример: Надо сделать выгрузку базы данных размером в 50гб из 1с: Предприятие 8(такие базы существуют в крупных промышленных компаниях), стандартными средствами 1с, то за ночь можно не дождаться пока сделается бекап… А теперь представим, что надо нам бекапить несколько терабайт данных каждый день… Тут кроме того, что мы с трудом и долго сделаем бекап на нас обрушатся еще 2 проблемы:
1. Где хранить такие большие бекапы и сколько копий?
2. Обычно такие резервные копии делаются по сети, и для бекапов нужно будет отдельное оборудование и отдельная подсеть, иначе можно таким объемом данных положить сеть загрузив всю пропускную способность сети…
Но если у тебя каждый день надо делать бекап с продакшен сервера с размером бекапа больше 100гб.
То система бекапов становится самым уязвимым местом. К примеру надо экспортировать из базы данных 100гб данных и нельзя останавливать сервер, то экспорт данных будет длится очень-очень долго и может не закончится за несколько часов… Пример: Надо сделать выгрузку базы данных размером в 50гб из 1с: Предприятие 8(такие базы существуют в крупных промышленных компаниях), стандартными средствами 1с, то за ночь можно не дождаться пока сделается бекап… А теперь представим, что надо нам бекапить несколько терабайт данных каждый день… Тут кроме того, что мы с трудом и долго сделаем бекап на нас обрушатся еще 2 проблемы:
1. Где хранить такие большие бекапы и сколько копий?
2. Обычно такие резервные копии делаются по сети, и для бекапов нужно будет отдельное оборудование и отдельная подсеть, иначе можно таким объемом данных положить сеть загрузив всю пропускную способность сети…
Простите за глупый вопрос, но почему в вашем примере не используется резервное копирование журнала транзакций, если для полной копии не получается уложиться в окно?
Остановите сервер на минуту. Дайте БД команду притормозить работу с диском — в каждой из них это делается своими средствами, но делается. Сделайте снапшот диска с базами. Запускайте все в работу — а потом тихонько тяните себе копию снапшота.
Вы же не на IDE винтах под Windows XP держите 100 Гб базу? А у нормальных хранилищ подобный функционал не то что есть, а часто встроен и реализован через агентов, которые и дают команду БД затормозиться, причем все так аккуратно, что и 1С не надо выключать.
Вы же не на IDE винтах под Windows XP держите 100 Гб базу? А у нормальных хранилищ подобный функционал не то что есть, а часто встроен и реализован через агентов, которые и дают команду БД затормозиться, причем все так аккуратно, что и 1С не надо выключать.
А если у тебя сервер в интернете на продакешене стоит и какой-нибудь крупный социальный ресурс, то тоже будете останавливать и делать снапшот?)
Все зависит какой ценой обойдется этот бекап, и чем больше данных бекапить тем бекап обходится дороже.)
Все зависит какой ценой обойдется этот бекап, и чем больше данных бекапить тем бекап обходится дороже.)
Даже не нужно базу останавливать. Многие СУБД имеют функционал, который позволяет уложить бэкап (а уж тем более снапшот) в одно транзакционное окно.
Тру стори. Восстановление бэкапов время от времени на чистую, запасную машину позволяет узнать много нового и интересного — о бэкапах, операционках, их создателях, их родственниках до пятого колена :)
Всякий раз читая статью про бэкапы вспоминаю это: http://www.taobackup.com/
Как-то отвечал за TFS и Redmine.
Раз в три месяца я устраивал армагеддон в четверг (в Израиле пятница и суббота выходные) – опускал сервера и говорил админу – а теперь пожалуйста накати мне эти серваки из бекапов.
Один даже расстроился и ушел. Зато второй это дело заценил и поднимал все где-то за часик.
Раз в три месяца я устраивал армагеддон в четверг (в Израиле пятница и суббота выходные) – опускал сервера и говорил админу – а теперь пожалуйста накати мне эти серваки из бекапов.
Один даже расстроился и ушел. Зато второй это дело заценил и поднимал все где-то за часик.
Есть три категории людей: те которые ещё не делают бекапы, те кто уже делает бекапы и те кто проверяет сделанные бекапы
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Джоэль Спольски: перестаньте делать бэкапы