Comments 27
А что будет с бэкапами, если что-то случится с EMC Avamar у вас в цоде — взрыв/пришельцы/цунами...?
Есть ли резервирование самой EMC-шки?
Есть ли резервирование самой EMC-шки?
Интересно, зачем такая избыточность? И еще интересно, почему на узлах Raid 1 а не 10? При той же избыточности он по-моему даст бОльшую надежность.
Пробовали ли уже восстанавливаться из этих бэкапов? Как скорость восстановления, если что-то сломалось?
А как на счет шифрования бэкапа? Ведь вроде как получается решение не индивидуальное, да еще и удаленное, имеет смысл шифровать бэкапы, нет?
И, если я правильно понимаю, то в случае, если бэкап шифруется, дедупликация, по сути своей, перестает работать?
И, если я правильно понимаю, то в случае, если бэкап шифруется, дедупликация, по сути своей, перестает работать?
Шифрование, действительно, крайне негативно сказывается на дедупликации, поэтому нет смысла ее применять – вся фишка пропадает и решение будет дорогим. Да и смысла в этом нет – сохраняются блоки данных, из которых, при хищении дисков, на практике невозможно собрать что-то без функционала Avamar. Однако, есть возможность шифрования данных при передаче уже после дедупликации во избежание их кражи из канала.
Дорого и неэффективно. НетАпп выглядит более привлекательно на этом фоне.
1) Какой размер блока для дедупликации? Если он переменный, то как определяются блоки, которые уже имеют дубликаты?
2) Дедупликация на источниках — какой footprint возникает на источнике?
2) Дедупликация на источниках — какой footprint возникает на источнике?
Длина блока переменная. Алгоритм разбиения на блоки работает таким образом, что результат разбиения одних и тех же данных идентичен. Новые данные образуют новые блоки. На источнике хранится кэш уже переданных файлов и блоков, сначала сравнение идет с ним, потом с глобальным кэшем (на сервере), если данные не найдены ни там ни там, то они передаются по сети. Размер кэша изменяется по итогам каждого бэкапа. Использование оперативной памяти в момент бэкапа для выполнения расчетов по умолчанию ограничено, так как решение рассчитано в том числе для бэкапа рабочих станций.
Средний размер 24К. Точки «разреза» потока данных определяются патентованным алгоритмом, который при вставлении в середину новых данных с большой вероятностью разрежет блоки так, что новые данные образуют один или несколько новых блоков, а границы старых при этом не изменяются, поэтому их не нужно заново бэкапить.
Денег-то сколько?
Не нашел в топике случаев успешного и сверхудачного восстановления.
Можно зарейдить-1 хоть миллион зеркал, но смысла из этого будет ноль, если нет методики восстановления. Вы базу MSSQL забэкапите? А MySQL? А редулоги? А накатите обратно? А контроллер домена авторитативно? А виртуальные машины vSphere, Hyper-V? А 1С в конце-то концов?
Миллион скорости и миллиард емкости это прекрасно, но не тогда, когда под рукой нет дизэстер рекавери плана.
Можно зарейдить-1 хоть миллион зеркал, но смысла из этого будет ноль, если нет методики восстановления. Вы базу MSSQL забэкапите? А MySQL? А редулоги? А накатите обратно? А контроллер домена авторитативно? А виртуальные машины vSphere, Hyper-V? А 1С в конце-то концов?
Миллион скорости и миллиард емкости это прекрасно, но не тогда, когда под рукой нет дизэстер рекавери плана.
Sign up to leave a comment.
Правильный бэкап в ЦОДе