Комментарии 18
Первый абзац поражает глубиной безответственности сотрудников и глупостью реализации.
Я не знаю тонкости записи информации на магнитные ленты, но нельзя просто так взять и не проверить войдет или нет бекап на ленту.
Я не знаю тонкости записи информации на магнитные ленты, но нельзя просто так взять и не проверить войдет или нет бекап на ленту.
Скорее всего когда настраивали систему файлов было гораздо меньше и всё работало.
Это само собой, но ведь можно сделать простейшую проверку оставшегося свободного места. Хотя вот это наверно и есть тонкости записи на ленту )
Почти наверняка так и было. Скрытая опасность автоматизированных систем — они расслабляют. У меня был такой косяк: работала себе спокойно система резервного копирования (на диск, Bacula), всё вроде бы было нормально, бекап в «окно» влезал с запасом, расписание «дед-отец-сын», места было не то чтобы очень много — но хватало. Как вдруг старый «дед» оказался заблокирован (а там был полный, на 700 гигов, бекап), система его удалить не смогла и тупо сделала ещё один файл. Получилось три деда, и перерасход места на носителе — что вскоре вылилось в невозможность впихивания «отца». А не заметил я тупо потому, что привык смотреть на заголовки писем с логами — если BackupOK — то я дальше и не смотрел.
НЛО прилетело и опубликовало эту надпись здесь
Что меня удивляет в нынешней ситуации — так это некая незаконченность.
Вот смотрите: есть Гугль, есть Андроид, есть Гугльдрайв. Гугль умеет бэкапить контакты и пароли вайфай. И все. Даже СМСки умирают вместе с телефоном.
Что мешает сделать последний шаг и добавить регулярный бекап всего телефона в гугльдрайв? Вместо этого в маркете 100500 разной степени кривости приложений, предлагающих этот функционал за деньги.
Где логика?
Вот смотрите: есть Гугль, есть Андроид, есть Гугльдрайв. Гугль умеет бэкапить контакты и пароли вайфай. И все. Даже СМСки умирают вместе с телефоном.
Что мешает сделать последний шаг и добавить регулярный бекап всего телефона в гугльдрайв? Вместо этого в маркете 100500 разной степени кривости приложений, предлагающих этот функционал за деньги.
Где логика?
Может Гугль дает возможность работать сторонним разрабам? Или не хочет связываться с приватностью смс и иных данных?
Хотя — в iOS бекапится все, и это иногда очень сильно выручает
Хотя — в iOS бекапится все, и это иногда очень сильно выручает
Что мешает сделать последний шаг и добавить регулярный бекап всего телефона в гугльдрайв?
Зная гугл, это будет ещё один сервис, включенный по умолчанию. И не факт, что с возможностью отключения.
НЛО прилетело и опубликовало эту надпись здесь
Да, пост изначально был помечен как «tutorial», и поэтому содержит предельно упрощенные примеры. Мы пытаемся писать различный по уровню контент, — например, см. наш предыдущий пост по теме бэкапа и отказоустойчивости сервисов высокой доступности: "Архитектура BigData-инфраструктуры сервиса Pandorama и защита ее данных от сбоев"
По процитированному примеру — согласен с замечанием о его неясности — у меня оказалось пропущено описание «исходной ситуации». Речь шла о случае, когда в продуктивном сервере установлен один диск, и его отказ влечет необходимость восстановления данных из резервной копии. Backup-сервер — это управляющий сервер продукта резервного копирования. На нем тоже один диск. Речь шла о случае, когда происходит одновременный сбой этих двух дисков — в результате чего продукт резервного копирования не может функционировать и процесс восстановления продуктивной системы будет зависеть от времени восстановления Backup-сервера. Конечно, в реальной системе, скорее всего будет установлен RAID массив (и/или применены другие методы обеспечения отказоустойчивости), и проблема будет носить менее выраженный характер.
И, в целом, вы очень хорошо сформулировали основную мысль этого примера — я бы только добавил, что еще идея была в том, чтобы показать, что бэкап-инфраструктура должна рассматриваться как часть продуктивной инфраструктуры, так как от нее, в определенных случаях, зависит RTO при восстановлении продуктивной системы.
По процитированному примеру — согласен с замечанием о его неясности — у меня оказалось пропущено описание «исходной ситуации». Речь шла о случае, когда в продуктивном сервере установлен один диск, и его отказ влечет необходимость восстановления данных из резервной копии. Backup-сервер — это управляющий сервер продукта резервного копирования. На нем тоже один диск. Речь шла о случае, когда происходит одновременный сбой этих двух дисков — в результате чего продукт резервного копирования не может функционировать и процесс восстановления продуктивной системы будет зависеть от времени восстановления Backup-сервера. Конечно, в реальной системе, скорее всего будет установлен RAID массив (и/или применены другие методы обеспечения отказоустойчивости), и проблема будет носить менее выраженный характер.
И, в целом, вы очень хорошо сформулировали основную мысль этого примера — я бы только добавил, что еще идея была в том, чтобы показать, что бэкап-инфраструктура должна рассматриваться как часть продуктивной инфраструктуры, так как от нее, в определенных случаях, зависит RTO при восстановлении продуктивной системы.
Кстати, в ролике они немного иначе описывают «спасение» мультфильма — копии оказались у сотрудницы, которая работала из дома по причине недавних родов малыша. Это позволило получить наиболее свежий бэкап. В ролике ничего про то, что несколько месяцев кропотливо сравнивали файлы из разных версий бэкапа!
НЛО прилетело и опубликовало эту надпись здесь
Процесс восстановления в Pixar был подробно описан Oren Jacob в его комментарии к этому же ролику (что приведен выше), на этом ресурсе. См. по ссылке самый верхний комментарий. " I'm the Oren Jacob in the video. Hopefully I can offer some first person color commentary about the video above that might serve to answer the questions here.". Ролик же просто не стали перегружать деталями.
В частности, там есть такой момент: "With Galyn's machine now back in the building, we dupe'd that data immediately, then set about the task of trying to verify and validate this tree, which we thought might be about 2 weeks old. We compared Galyn's restoral with a much older one (from 2 months prior) and couldn't determine a clear winner, there were too many inconsistencies. So, instead, we set about the task of assembling what effectively amounted to a new source tree, by hand, one file at a time. The total number of files involved was well into the six figures, but we'll round down to 100,000 for the sake of the rest of this discussion to make the math easier."
В частности, там есть такой момент: "With Galyn's machine now back in the building, we dupe'd that data immediately, then set about the task of trying to verify and validate this tree, which we thought might be about 2 weeks old. We compared Galyn's restoral with a much older one (from 2 months prior) and couldn't determine a clear winner, there were too many inconsistencies. So, instead, we set about the task of assembling what effectively amounted to a new source tree, by hand, one file at a time. The total number of files involved was well into the six figures, but we'll round down to 100,000 for the sake of the rest of this discussion to make the math easier."
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Случай в Pixar или еще раз о важности тестирования резервных копий