Pull to refresh

Comments 17

Личные данные свои — давно храню в облаке копию! И на независимом переносном винте! Но это личные…
На работе делаем бакапы разными способами! В основном на библиотеку ленточную! Вернее сначала на полку (для быстрого доступа), затем на библиотеку — для долгосрочного хранения! :) Плюс периодические бакапы образов серверов на всякий случай для себя! Самое критичное — не бакапится, а резервируется в относительно реальном времени — для быстрого выхода в штатный режим функционирования. Хотя, данные в самом критичном — тоже хранятся на стороне — их бакапят другие админы! :) Ну вот как-то так!
А если не секрет, какой давности вы обычно храните резервной копии? Пару дней, неделя, месяц? И как часто вообще делаете бэкап?
Вопрос относится к личному или к корпоративному?
Если к первому — то просто сервисы аля дропбокс — реально спасли недавно — когда мак ссд свое спалил!
А если к корпоративному — то тут по разному! Написан подробный бакап-план — по нему — файлопомойки и базы данных еженочно, критические системы — раз в 15 минут! А храним — файлопомойки долго — до 1,5 месяцев (вдруг — пользователю чего понадобится) — все остальное — около недели, не больше! Виртуалки на vmware — раз в неделю тоже копируем! То есть еженочно снимаем данные с этих виртуалок, А еженедельно — копируем сами виртуалки! Софт — hp dataprotector — гибко, удобно!
Как раз недавно у меня был разговор с про-фотографом и я поинтересовался — а как и где хранит. Оказалось — на домашнем NAS-е с RAID1. Следующий вопрос «а если в форточку залезут и сопрут?» позволил мне оседлать своего конька )
Вообще, для фотографов, я считаю, недорогой «домашний» двудисковый Raid1 NAS от Qnap или Synology, где есть возможность настоить синхронизацию отдельных фолдеров с Амазоновским S3 и другими облаками — идеальное решение для домашнего хранения. Масса небольших файлов идеально подходит для такого механизма синхронизации. Периодическое пополнение архива не создает большой нагрузки на траффик синхронизации.

Второе условие, описанное в статье — идеал, конечно, но от «магнитного импульса» и прочих страстей спасет обычная герметичная железная коробка. Такую я и вожу в багажнике, соблюдая пункт 3 )
Да не смешите мои тапки, s3 довольно дорог на большие объемы, заходил к знакомой фотографше, так у неё жестких дисков больше чем у меня во время жесткого увлечения аниме, фоток террабайты, если не десятки террабайт. Такое хранить в облаке себе дороже.
Не хочу смешить ваши тапки, но я говорил именно про эти самые террабайты…
И если у фотографа нет десятки американских денег за хранение терабайта на Glacier — поверьте, там терять действительно нечего )
s3 и glacier все таки разные штуки, ну а залить в glacier не так уж и просто технически. Это вам все таки не сисадмин, а фотограф.
В s3 10 террабайт хранить 652 доллара ежемесячно, проще в аренду дедики брать.
Почитайте все-таки что такое lifecycle — как автоматом S3 умеет через указанное ему время после закачки в S3 папку все уносить на Glacier.
Когда я тестил гласиер такой возможности точно не было.
Спасибо за наводку.
Плюсанул ваши комменты, жалко карму не могу.
Спасибо что направили на путь истинный, был не прав, исправлюсь.
>> Если вирус заражает файл на одном диске массива, сразу же происходит заражение второй копии на зеркальном диске.

а так же заразится третья копия, удаленная. в чём прикол тогда делать вторую локальную копию, когда реально хватит одной локальной, и одной удаленной?

от вирусни спасет только дифференциальный бэкап, и ничто другое
Полагаю, вы имеете в виду ситуацию, когда дифференциальный бэкап делается (как он описан в классике), скажем, 6 дней в неделю, а на 7 день проходит полный бэкап (назовем это схемой «6+1»). В этом случае мы имеем историю изменения данных за неделю (фактически 7 исторических копий данных), и, конечно, такой способ намного надежнее, чем случай с тремя копиями. Однако, если администратор не заметит заражения файла за неделю, или если дифференциальный бэкап делается не по описанной схеме 6+1, а скажем, 3+1, или 2+1, то и этот способ может не помочь избежать потери оригинальной (не зараженной вирусом) копии файла.

В статье я хотел описать некий минимальный уровень количества резервных копий. Хотел показать, что две — точно мало. По сути, описана следующая концепция: когда у вас есть постоянно меняющиеся оригинальные данные, нужно как можно чаще делать их дубликат (реплику, вторую копию) на другом физическом носителе. Чем чаще будете снимать дубликат данных, тем лучше будет RPO (то есть будет меньше потерянных новых изменившихся данных в случае, если произойдет сбой оригинального диска). Т.о. хранилище «второй копии» д.б. быстрым — то есть лучше всего на эту роль подходит дисковое СХД. Вторым аргументом в пользу быстрого дискового СХД является RTO (скорость восстановления после сбоя). Но у такого подхода есть и «обратная сторона».

Минусом такого подхода по организации «максимально быстрого регулярного создания второй копии», является тот факт, что все искаженные или испорченные данные, будут точно также очень быстро продублированы. Т.о. «вторая копия» — это по сути не средство резервного копирования, а средство обеспечения лишь отказоустойчивости.

По сути, только третья копия (и последующие) является средством резервного копирования, если она создается уже по другому, более «медленному», расписанию (скажем, не мгновенно, а раз в день), а сохранение идет в другую среду, чем диски (то есть, например, в облако или на ленты). Эта третья копия (и последующие) хранят по сути историю изменений за период времени, чем их больше -конечно тем лучше. Тем больше у администратора возможностей заметить заражение файла и откатится к той версии файла, когда он был еще не заражен.
я специально перечитал ещё раз Ваш топик, и всё равно не понял, для чего необходим третий бэкап. что в нём волшебного? как он спасает от вирусов?
если речь идёт конкретно о вирусах, то любой уважающий себя админ имеет в сетке сканер, который, при аномальной активности хотя бы на одном компьютере, завалит алертами почтовый ящик или сотовый телефон. напомню, время реагирования на вирусную активность — 15 минут. о какой НЕДЕЛЕ может идти речь? точнее, что за такой администратор, который за неделю не может обнаружить вирусы в локальной сети?
ОК, может, я ответил, немного неверно поняв ваш изначальный вопрос: итак, на вопрос «зачем нужна вторая локальная копия?», могу дать такой ответ: «для отказоустойчивости и уменьшения RTO и RPO (так как процесс восстановления В/ИЗ удаленного хранилища обычно не быстрый)». Если в этом нет большой необходимости, то, конечно, согласен с вами,- вторая локальная копия данных не нужна.

Еще могло быть терминологическая неточность. Первой копией данных я называю сами оригинальные данные, второй локальной их копией — первую резервную локальную копию.
«То есть, когда вы делаете три копии вместо одной, то получаете утроение вероятности сбоя данной совокупности копий»

Именно совокупности? Т. е. всех сразу?
Да, я имел в виду, что, когда мы имеем совокупность (в смысле «группу объектов»), скажем, из двух зеркалируемых копий данных, расположенных на двух одинаковых по характеристикам дисках, то вероятность сбоя отдельного диска в целой группе будет больше, чем в случае единственного диска, просто за счет того, что объектов больше. При этом надежность такой группы выше, чем у единственного диска, потому что сбой отдельного диска в такой зеркалированной группе не является критическим событием (ведь копия данных осталась на втором диске), а вероятность одновременного сбоя всех дисков в группе — меньше пропорционально степенной функции (то есть квадрату, кубу и т.д. вероятностей сбоя отдельных дисков).

Говоря проще: когда у вас два автомобиля, а не один, то вы среднестатистически за год в два раза чаще посещаете сервис (то с одной, то с другой машиной), при этом вероятность остаться вообще без средства передвижения в некий день у вас квадратично ниже, чем в случае одного автомобиля. (Иными словами за надежность группы машин выше)

Нашел небольшую статью на эту тему (англ. яз.): "RAID1 increases chances of disk failure".
Да, так, но тогда приведенная мной цитата из вашего поста некорректна.

Сравните.
"… то получаете утроение вероятности сбоя данной совокупности копий" vs «то вероятность сбоя отдельного диска в целой группе будет больше, чем в случае единственного диска, просто за счет того, что объектов больше.»
Ко второй цитате претензий нет, первую можно понять так, что сбой элемента группы фатален для всей группы, что, конечно же не так.

Было бы точней что-то типа "… то получаете утроение вероятности сбоя отдельного элемента из данной совокупности копий", но вероятность для совокупности как единого объекта не растет, а уменьшается по такой-то зависимости.

А точно ТРИ резервные копии? Или достаточно иметь просто три копии данных, сам оригинал и две его резервные копии?

Sign up to leave a comment.