Pull to refresh

Comments 80

UFO just landed and posted this here
UFO just landed and posted this here
Я вот тут подумал, на сколько бы увеличилось качество кода если бы за ошибки делалось юбитсуме.
Опыт работы бы сразу был бы виден, безо всяких там сиви, гитхабов и прочей мишуры. Наверное выпускались бы и клавиатуры для матерых программистов, с подушечками специальными.
К сожалению программисты вымирали бы слишком быстро ;(
Нету пальцев — ничем не рискуешь. Уже б давно был нейроинтерфейс или хотя б нормальный голосовой ввод.
И насколько бы уменьшилось его количество, а также количество программистов в целом :)
Я вот тут подумал, на сколько бы увеличилось качество кода если бы за ошибки делалось юбитсуме.
Навеяло — «я знаю циркулярку как свои 7 пальцев!»©
Точнее, «технику безопасности при работе с циркуляркой / токарным станком я знаю как свои 3 пальца».
Юбитсуме
В русский язык этот термин был заимствован в форме «юбицумэ», извлекающей пользу от наличия буквы «ц» в кириллице (в отличие от латиницы), а также от различия букв «э» и «е».

(В этой форме ужé никому не покажется отчасти возможным происхождение от слова «сумá» в дательном падеже, например.)
Против оябуна возражений нет? :-)
UFO just landed and posted this here
Согласен, в частном случае с БД такой вариант довольно популярен. Как я оговорился, нюансов и ухищрений можно вспомнить много.
Время бэкапа все равно нужно минимизировать. В системах с большим потоком транзакций есть требования к максимальному отставанию слейва/стендбая. Кроме того у слейва обычно ниже производительность (дешевле железо) и он может братьна себя часть read-only нагрузки.
Есть мнение, что со слейва бекапить в общем случае нельзя, поскольку данные там могут быть весьма неактуальными.
Он знает свой станок как свои три пальца…
Ставлю процесс бекапа на мониторинг, наравне с остальными сервисами. На практике бывало, что бекап настроен, проверен и запущен в работу. А потом что-нибудь тихо отваливается, и бекапы уже не делаются… Узнаешь об этом, как правило, когда нужно восстанавливать данные.
Все на эти грабли наступали.
А просто надо устраивать тренировки по восстановлению. Ну хотя бы раз в квартал.
Есть 2 типа админов — те, кто ещё не делают бекапы, и те, кто уже делают.
… в стороне стоит третий тип, который проверяет сделанное.
Некоторые считают, что 3 типа. 3-й — те, которые начали проверять консистентность бэкапов :)
Как когда-то сказал один человек на тренинге: «Если у вас нет бекапа — у вас нет данных. Если у вас один бекап — у вас нет бекапа.»
Хочу запустить просветительскую кампанию для обычных пользователей, которые хранят все свои фоточки на одном древнем винчестере пыльного системника. Но решение для пользователей должно быть исключительно адекватным и простым. Пока что рекомендую купить внешний диск и раз в месяц синхронизировать его с выбранными папками на основном компе, сравнивая каждый раз, много ли файлов будет изменено и где. Это для того, чтобы если вирус попортил файлы, или что-то иное их испортило (если просто удалило, то программа синхронизации спросит, что делать), можно было как-то отследить. Может, кто-то знает решение, чтобы программа сама определяла, что изменилось слишком много файлов, или, например, изменились файлы в папках, помеченных как «архивные», не предполагающие изменения, и адекватно реагировала на изменение структуры папок?
Троим юзерам данные восстанавливал гигабайты фоточек из единственной копии на убитом жестком, объяснял, почему плохо хранить все в одном месте без бекапов — в итоге они решили, что на внешний жесткий их душит жаба. Так и живем.

Но за идею плюсую, однозначно. Быть может, сяду написать такую программку :)
Если брать большинство, то достаточно встроенного виндового бэкапа, он шустр и прост.
Как на счет облачных хранилищ: Dropbox, OneDrive, Google диск и т.д.? Для хранения фоточек вполне подходящий вариант, пользователю даже задумываться не надо о синхронизации и прочих вещах, при наличии интернета все происходит автоматически. Если у пользователя несколько компьютеров, то, помимо копии в облаке, будут и копии на всех устройствах (при желании конечно), опять же смартфоны могут сразу фоточки и выгружать туда автоматически. Ну и риск одновременной порчи жесткого диска и исчезновения копии в облаке весьма мал и им можно пренебречь для данной задачи.
Когда фоточек 700 гигабайт — не оч вариант :(
Bittorrent sync
еще и историю хранит
Ну таки от облачных сильно отличается — нужно, как минимум, иметь работающий компьютер с толстым диском.
У mail.ru был аттракцион щедрости — раздавали хранилище на 1 Тб. Работает, пользуюсь. Все нормально, кроме самого факта, что приходится пользоваться mail.ru. ;)
TeamMRG сделайте уже наконец API хоть какое-нибудь. Ну не хочу я держать тот же террабайт у себя! Богом бекапов прошу!!!
Где-то в комментах на хабре мелькало, что есть webdav (пока beta). Но по webdav.cloud.mail.ru/ — 403, в официальной помощи ничего об этом нет.
Вроде было первую неделю, потом отключили.
Хм, так видео-то официальные были, с тех самых вэбкамер.
Crashplan, Backblaze — если не жалко 5$ в месяц за безразмерное облако и автоматический бэкап.
UFO just landed and posted this here
Crashplan очень удивительная система. На каждый терабайт бэкапа (или сколько-то тысяч файлов) они хотят откусывать по гигабайту от памяти. Я сейчас веду с ними обширную переписку на тему «почему у вас все через ж… пу джаву, потому как мои 2 терабайта фоточек бэкапятся уже второй месяц со скоростью 300Kbps на линии в 44 MBps, отъедая при этом 4 гига из 8 доступных на машине. И техподдержка отвечает раз в сутки.
У меня на Crashplan чуть меньше терабайта сейчас заливается (перескочил с Backblaze, там тоже одна удивительная вещь произошла), пока 500 мегов памяти кушает, в принципе, не напрягает. Backblazе процессор точил ощутимо, напрягало сильнее.
Только что проверил — всего в архиве 1.7 TB, процесс Crashplan кушает в среднем 1.3 гигабайта памяти, процессор нагружен на 25%.

Кстати, а что с Backblaze не так? У них вроде клиент не на джаве — должно милосерднее выглядеть?
Backblaze, когда начинал ежедневный бэкап, кушал у меня под сотню на E8200. Возможно, тяжко ему индексировать было большое количество файлов. Из-за количества файлов он у меня и помер. В один прекрасный день сказал что файл bzfileids.dat too large и бэкапить он теперь отказывается. Гугление и переписка с поддержкой предложили одно и то же решение проблемы — удаление этого bzfileids.dat и полная перезаливка бэкапа. А раз все равно перезаливать, решил на Crashplan перескочить, мне он вкуснее давно уже казался. Ниже про этот bzfileids.dat

bzfileids.dat is a database of all the files on your computer. Normally that file is from 20 to 500 MB in size for normal backups, up to about 3-4 GB for extremely large backups.

Yours is currently reporting that it's 8 GB, which is why it errored and stopped, as it can not exceed 8 GB.

To resolve this, you can uninstall and reinstall Backblaze which will start a new backup and assign it a free 15 day trial to get started

Then you will need to transfer your paid license following these steps before the 15 day trial expires:
1. Visit secure.backblaze.com/user_signin.htm and sign in to your Backblaze account with your email address and password.
2. Click on the «Account» link in the upper left hand corner
3. Select your old backup from the list of computers.
4. Click the «Delete Computer» link next to it. This will delete the backed up data, and free up the paid license.
5. On the Overview page click the «Use License» button next to your new backup.
Восьми гигабайт хватит всем!
быстро ли у вас работает Backblaze в России?
Я несколько лет назад им пытался воспользоваться — к концу бесплатного месяца он еще не успел загрузить мои 250 Gb.
flickr терабайт предлагает. Только не скажу ничего про синхронизацию и прочее.
фликр (и любой другой фотохостинг) — средство хранения не сильно приватных фоток в готовом для просмотра виде. если вдруг захочется хранить равки, просто огромные тифы или псдшки — то приплыли, равно как и с приватностью.
Причина простая — ограниченный объем, у людей вполне может храниться по 100 гигов фоток с отпусков (никто их не сортирует, не жмет, не фильтрует по качеству… плюс видосы всякие там..). Облачные хранилища пока что на это не готовы за адекватные деньги.
Облака очень удобны для рабочих документов, написания диплома и т.п.
Людям не очень понятно, зачем платить облаку за место, если можно купить жесткий диск на шнурке… некоторые все же параноят слегка по поводу личных фотографий, а все паролить — потеря времени и удобства.
Поэтому должно быть удобно и понятно, чтобы не грузить человека лишним, но и должна быть возможность «открыть капот» и настроить алгоритм работы…
Облачные хранилища вполне себе готовы уже для всего. До недавнего понижения цен ситуация была такая: www.istudioweb.com/cloud-storage-comparison-2014-edition-2014-06-04/ — потом, вроде, Microsoft немного сбавил цену.

Жесткий диск на шнурке в ойфон не засунешь, а вот одной кнопкой настроить синхронизацию «все фоточге в дропбокс» — это уже элементарно.
Троян-шифровальщик без проблем накроет это хранилище. Как и внешний диск для бэкапа.
Dropbox вроде имеет-же возможность отката назад, нет?
UFO just landed and posted this here
Не все могут позволить себе хранить данные в облаке: конфиденциальность — не последнее дело.
UFO just landed and posted this here
1. Причем здесь фоточки? В посте речь о корпоративных данных же.
2. Да, можно перед отправкой шифровать данные. Но это время и ресурсы.
3. Опять же, не последнюю роль играет скорость доступа к этим самым облакам.

Учитывая п.п.2-3, многие просто предпочитают бэкапить локально, максимум — в другой датацентр.
UFO just landed and posted this here
Что на счет приложений типа CrashPlan или BackBlaze? Еще можно настроить AllWaySync — она бесплатная. Может по разным условиям синкать каталоги. Одному клиенту помогло уже пару раз после того как я настроил резервирование его флешки.
Я таким юзерам обычно ставлю бесплатный Cobian Backup 11 — при должных настройках достигается именно та схема работы, которую Вы описали.
Позволю себе указать на фактологическую неточность:
«Создать консистентную копию данных, например, СУБД Oracle или MS Exchange без остановки работы невозможно» — не знаю, как с Exchange, а Oracle умеет и любит делать консистентные копии данных без остановки, и никаких специальных агентов для этого не требуется. 100% виденных мной агентов систем резервного копирования просто интегрировались в штатный оракловый RMAN.
Exchange тоже умеет делать консистентную копию без остановки (с помощью технологии Shadow Copy)
Агент все же тоже нужен, он и делает Shadow Copy, а также подрезает transaction log, что критично для бесперебойной работы Exchange.
Я только ответил, что можно делать резервное копирование без остановки Exchange, но не говорил, что не нужен агент системы резервного копирования. В принципе, как решение для бедных (или знатных мазохистов), можно использовать встроенный в ОС Backup, но в этом случае возникает вопрос, откуда у организации взялись деньги на Exchange?
Все правильно, у Oracle начиная, если не ошибаюсь, с версии 8 существует специальный компонент Recovery Manager, он же RMAN. И он позволяет делать консистентный бэкап базы, не переводя ее в режим backup. Правда, она должна при этом работать в режиме archivelog. Однако, для софта резервного копирования агент все равно требуется, чтобы давать команды RMAN и направлять данные от RMAN channel, например, на определенный драйв библиотеки.
Oracle может делать online бакап еще с 7-й или даже 6-й версии, еще до RMAN, называется hot backup.
>Создать консистентную копию данных, например, СУБД Oracle [...] без остановки работы невозможно
А мужики-то не знают :)
Всегда возвращаю системник из сна через NumLock (виден отклик), ну или в крайнем случае стрелки.
Enter или пробел — ни в коем случае, мышь — нежелательно кликать куда попало.

Например вы запустили что-то долгое, важное и ушли, а там вывалился месаджбокс, спрашивающий Да/Нет.
Пробуждение пробелом закроет его и 1) вы не знаете что там было 2) делается не то что вам надо.
А зачем кликать мышью, достаточно ее повозить пару раз туда сюда, но намлок конечно лучше.
Многие дешевые беспроводные мыши сами не просыпаются от перемещения, только от кнопки.
В Windows хранители экрана не реагируют на Alt.
По 11 пункту, а разве Veeam не лучше работает с гипервизорами? Symantec конечно крут, но специализированное решение предствляется более надежным.
Veeam – достойный инструмент, и он развивался как продукт, заточенный под VMware. Поэтому если надо бэкапить только ферму VMware и вы настроены использовать Veeam, я вас только поддержу. Когда бэкапом надо покрыть много разных систем, среди которых есть и VMware, то плодить точечные решения под каждую задачу нерационально. Здесь больше подойдет Symantec.
Еще нужно иметь план восстановления из бекапа. А то бывает что все есть, а что с этим делать не понятно.
Всё написанное правильно, но это частные случаи.
Если хочется подойти к вопросу правильно, то начинать надо с написания Disaster Recovery Plan, составной частью которого является Backup Plan.

В частности, составляется перечень сервисов и матрица угроз. Один из возможных вариантов следующий:
1. Делается список: какие сервисы предоставляет IT.
2. Делается список: какое оборудование, какое ПО и какие данные необходимы для работы каждого сервиса.
3. Делается матрица: по горизонтали — зависимости из п.2, по вертикали — возможные угрозы. В пересечениях — принятые меры.

Например, сервер состоит (условно) из материнской платы, БП, жёстких дисков. От смерти БП мы защищаемся резервированием, от смерти материнки — дублирующим сервером, от смерти винта — рэйд-массивом.
А вот от другой угрозы — случайной или намеренной порчи данных человеком — рэйд нас не спасёт и тут нужны бэкапы.
А кроме бэкапов, есть ещё архивы (по сути, те же бэкапы, но предназначенные не для восстановления при сбоях, а в случае потребности бизнеса восстановить состояние за прошлый год, например).
Это всё описывается, документируется и только исходя из этого уже принимается решение — как бэкапить, чем бэкапить, на что бэкапить. Иначе есть шанс либо выкинуть деньги на ветер, либо в какой-то момент оказаться у разбитого корыта, когда бэкап на ленточке-то есть — а прочитать ленточку, например, нечем, потому что сдохла последняя голова в ленточной библиотеке.

Вообще это тема отдельного поста, да как бы и не одного.
UFO just landed and posted this here
1. Бэкап должен быть всегда
2. Бэкап должен быть автоматическим

ZFS automatic snapshots (TimeSlider)
Настраивается на уровне тома, любой интервал, есть предустановленные
frequent — раз в 15 минут
daily
weekly
monthly
yearly
Дальше божественная SMF управляет сервисом сама.
Массив можно собрать крайне недорогой и при этом он будет очень надёжным (надёжней RIAD'ов на тех же дисках) и быстрым (ZIL + L2ARC).
Что позволяет выполнять даже не до конца обдуманные действия экономя время на обдумывании.

3. Восстановление из бэкапа — это крайняя мера
Да нет, клонирование ZFS-снапшота — моментальное действие, восстановление в родной том — подольше, но тоже не сравнимо с лентами — быстро.
Снапшот невозможно повредить «восстановив не туда».

4. Бэкап нужно хранить отдельно от данных и минимум 2 недели
Храните пока место есть, сервис TimeSlider сам почистит самые старые бэкапы, когда места на диске станет критически мало.

5. Бэкап нужно регулярно проверять
Скрипт «zpool scrub» в crontab с запуском раз в неделю — за глаза.
Сильно надёжнее лент, сильно быстрее, спится легко.

6. Полезно дублировать бэкап на удаленную площадку
Плагины к сервису TimeSlider идут из коробки:
zfs-send
rsync
Выбирай любой в зависимости от целевой ОС.
Передача инкрементальных снапшотов по ssh-туннелю — из коробки.

7. Бэкап – это нагрузка на работающую систему
Забудьте про это при наличии ZFS — моментальный снапшот, более того — снапшоты, даже рекурсивные, атомарны!

8. Данные можно копировать по SAN, а не по LAN
Как уже говорилось — передаются только изменения, маршрут передачи и транспорт выбираешь сам.

9. Приложения можно бэкапить на ходу
Вот тут для ZFS надо городить свой велосипед, я толкового решения не знаю.

10. …и минимизировать нагрузку на основную систему
ZFS-снапшоты атомарны и моментальны, система «сидящая» на ZFS томе не заметит что её «снимают».

11. Виртуальные машины нужно стараться бэкапить средствами гипервизора
Та же проблема, что и в пункте 9.

12. Нужно избавляться от дублей
Для дедупликации ZFS нужно _очень_ много RAM. На Хабре была как-то статья с расчётами пользователя нексенты.
Если даже кажется, что RAM для таблиц дедупликации может не хватить — включать категорически нельзя.
Зато из коробки есть сжатие томов различными алгоритмами, LZ4 поддерживается.
а еще ZFS может:

13. Сожрать 48G оперативы из 64G total, и не отдавать обратно ядру никак кроме как ребутом

14. Невозбранно тупить на операциях с метаданными (удаление каталога с 10000 файлами, равномерно распределенными в 5 уровней вложенных подкаталогов)

(это я про zfsonlinux.org/)
Я в основном про солярку.
У меня проблемы с памятью были только при включении дедупликации.
14й так же не наблюдал, хотя и гоняю соляру (сначала опенсолярис, теперь индиану) как схд с 2010 года весьма плотно.
Zfsonlinux у меня только как удалённый бэкап сторадж.
Для тех, кто не хочет заморачиваться с LVM или не использует ZFS, есть прекрасная утилита Linux Hot Copy https://www.r1soft.com/free-tool-linux-hot-copy, которая делает атомарный снапшот файловой системы, аналог VSS (Volume Snapshot Service) под Windows.
Sign up to leave a comment.