Только нужно учесть, что бэкапов происходит несколько параллельно и ресурсы для одного процесса нужно как-то лимитировать, а также мониторить все это дело. В нашем случае сеть можно проапргрейдить с 10G на более производительную и получить понятный прирост. В общем именно увеличение скорости самое эффективное для нас на данный момент.
По-умолчанию 10, и мы столько же и используем. rbd cp и rbd import в этом плане конфигурируются одинакого, разница лишь в том, что из pipe нет возможности читать многопоточно.
Мы используем Ceph, он тоже умеет делать "моментальные снэпшоты", но снэпшот не равно бэкап. К тому же, без относительно бэкапов, сталкивались с тем, что при определенном количетсве снэпшотов (кажется было 14) начинаются задержки в операциях диска (не знаю как с этим в ZFS).
Также мы используем OpenStack и придерживаемся его подходов бэкапирования, скорее поэтому схема именно такая. После того как снэпшот оригинального диска создали, уже его копируем в другой пул в отдельный диск. А при восстановлении из бэкапа создаем новый диск по мима оригинального и копируем в него данные из пула бэкапов, а не откатываемся до снэпшота.
Думаю можно, но это усложнит логику бэкапирования и начнет потреблять другие ресурсы (CPU, RAM). В нашем случае было много сетевого ресурса, нам нужно было утилизировать его. Если бы его не было, можно было думать в сторону сжатия.
В нашем случае, кажется, что не приемлем. Потому что с одной стороны сжатых данных передать нужно меньше, с другой стороны rbd import не ожидает на вход сжатых данных и их нужно будет распаковать. Как верно заметили ранее, накладные расходы на сжатие/распаковку замедлят процесс. К тому же копирование происходит на одном сервере (при этом пулы дисков подключены к нему по сети) и потоки данных в любом случае приходят и уходят несжатыми, поэтому здесь это смысла не имеет. В иных конфигурациях, без возможности использовать другие инструменты, может стоит посмотреть в сторону сжатия.
В моём колледже, такие ученики получают оценки отлично. Учитель показывает выполнение задания, они конспектируют в тетрадь, а на практике без своей тетради ничего не могут. Мы, с моим другом, поступаем противоположно. Мы не записываем «Как объявить переменные в Visual Basic» в тетрадь. А сразу переходим к практике и выполняем ее, но из-за того что у нас нет конспектов, нам ставят оценку 2. Справедливо?
Меня примерно по тому же отчисляли :). Но институт я в итоге закончил.
Это тут совсем не причём. Хоть я и не игрок уже давненько, но могу смело сказать, что этот ярлык вешать не стоит. У меня одногруппник переиграл за нас всех, но он лучше всех разбирается в программировании и спокойно может сделать простенькую игру на мобильном приложение.
Я не про то, что геймерство — зло. Я про то, что со мной учились люди, которые в свободное время играли, приходили в институт и только и дело что говорили об играх, и ждали когда же кончатся пары, чтобы поиграть. Обычная школота, которая, была бы возможность, пошла бы в 12 и 13 класс…
Тут не только в образовании дело, но и в человеке. У меня 90% одногруппников сидели и весь институт ждали пока их чему-нибудь научат (правда в их ожиданиях это было так: им показывают — они повторяют). Показали им как на Си объявить структуру данных, которая описывает спортсменов, например, и записать спортсменов в массив. Затем их просят сделать то же самое, но с актерами, и тут начинается: «Да как же так?! Нам же только про спортсменов объясняли, а про актеров нет». И вот всё им было сложно по институту, и линуксы, и СУБД, отличные от MS SQL (потому что препод только её показывал). И кстати стоит ли говорить, что в большинстве своем одногруппники мои были дотерами, каэсерами и прочими геймерами.
Конечно, мне попадались и пятидесятилетние тетки, которые могли только в Word и Excel. Но если тебе действительно интересно, многие преподы готовы уделить тебе время, дать доп.задания и скинуть материал для их выполнения.
Естественно, я не говорю что в универе вас научат самым модным фишкам в ИТ-индустрии, но основы для самостоятельного изучения дадут, если сами того захотите.
Когда был оффициальный апдейт на 10.3 у меня телефон постоянно грелся и разряжался на глазах. Читал на форумах о том, что это связанно с шифрованием и индексированием файловой ситсемы. Потом прошил сам на 10.3 по-свежее — батарею жрать перестал. В принципе 1.5 суток сейчас могу с телефоном проходить.
И в списке звонков и в BlackBerry Hub. Первую минуту при загрузке — это норм. А бывает всё время, но как я и сказал, крайне редко.
АКБ год, как и телефону:
— Энергосбережение при 20% и ниже включается автоматически (И вот от 0% до 20% телефон может выключиться в любой момент).
— Ну и в настройках при энергосбережении урезается всё что можно.
Я как понимаю считали уникальных человек. Так что не факт, что за раз посещает мало.
Очень «удобно», CTRL + F по ключевым словам, но фиг тебе, это же картинки.
Только нужно учесть, что бэкапов происходит несколько параллельно и ресурсы для одного процесса нужно как-то лимитировать, а также мониторить все это дело. В нашем случае сеть можно проапргрейдить с 10G на более производительную и получить понятный прирост. В общем именно увеличение скорости самое эффективное для нас на данный момент.
Видимо есть какое-то несогласие?
Сейчас 9.25 TB данных копируется за 11.4 часа со скоростью 1.8 ГБит/с. Что-то не так?
По-умолчанию 10, и мы столько же и используем.
rbd cpиrbd importв этом плане конфигурируются одинакого, разница лишь в том, что из pipe нет возможности читать многопоточно.Мы используем Ceph, он тоже умеет делать "моментальные снэпшоты", но снэпшот не равно бэкап. К тому же, без относительно бэкапов, сталкивались с тем, что при определенном количетсве снэпшотов (кажется было 14) начинаются задержки в операциях диска (не знаю как с этим в ZFS).
Также мы используем OpenStack и придерживаемся его подходов бэкапирования, скорее поэтому схема именно такая. После того как снэпшот оригинального диска создали, уже его копируем в другой пул в отдельный диск. А при восстановлении из бэкапа создаем новый диск по мима оригинального и копируем в него данные из пула бэкапов, а не откатываемся до снэпшота.
Думаю можно, но это усложнит логику бэкапирования и начнет потреблять другие ресурсы (CPU, RAM). В нашем случае было много сетевого ресурса, нам нужно было утилизировать его. Если бы его не было, можно было думать в сторону сжатия.
Не пробовали. Как-нибудь гляну и отпишусь.
Все верно, в таблице мегабиты.
9ТБ данных сейчас мы бэкапим за 11 часов в продакшене у реального клиента.
В нашем случае, кажется, что не приемлем. Потому что с одной стороны сжатых данных передать нужно меньше, с другой стороны
rbd importне ожидает на вход сжатых данных и их нужно будет распаковать. Как верно заметили ранее, накладные расходы на сжатие/распаковку замедлят процесс. К тому же копирование происходит на одном сервере (при этом пулы дисков подключены к нему по сети) и потоки данных в любом случае приходят и уходят несжатыми, поэтому здесь это смысла не имеет. В иных конфигурациях, без возможности использовать другие инструменты, может стоит посмотреть в сторону сжатия.Меня примерно по тому же отчисляли :). Но институт я в итоге закончил.
Я не про то, что геймерство — зло. Я про то, что со мной учились люди, которые в свободное время играли, приходили в институт и только и дело что говорили об играх, и ждали когда же кончатся пары, чтобы поиграть. Обычная школота, которая, была бы возможность, пошла бы в 12 и 13 класс…
Конечно, мне попадались и пятидесятилетние тетки, которые могли только в Word и Excel. Но если тебе действительно интересно, многие преподы готовы уделить тебе время, дать доп.задания и скинуть материал для их выполнения.
Естественно, я не говорю что в универе вас научат самым модным фишкам в ИТ-индустрии, но основы для самостоятельного изучения дадут, если сами того захотите.
АКБ год, как и телефону:
— Энергосбережение при 20% и ниже включается автоматически (И вот от 0% до 20% телефон может выключиться в любой момент).
— Ну и в настройках при энергосбережении урезается всё что можно.