12 заповедей про бэкап, за которые я чуть не заплатил пальцем



    В прошлый раз я рассказал вам, не побоюсь этого слова, кровавую историю, как мы срочно спасали сначала инсталляцию, а потом уже и данные. И такие истории лишний раз дают понять важность наличия бэкапа и правильность его настройки. Сегодня я хочу суммировать свои мысли, накопленные за последние 10 лет опыта работы в системном интеграторе.

    1. Бэкап должен быть всегда.
    Как бы не развивались технологии, старая добрая резервная копия никогда не потеряет своей ценности, в трудную минуту сохраняя нам нервы, работу, премию, а также успокоительные средства. Она, в случае чего, позволяет нам не паниковать, действовать взвешено, допуская разумный риск.
    Даже если в вашем сервере все компоненты дублированы, а данные лежат на дорогом массиве с избыточностью, отгоните от себя ложное чувство безопасности. Никто не застрахован от логических ошибок и человеческого фактора.

    Пример из жизни. Недолгое время у одного из наших заказчиков работал некий товарищ, который, хоть был еще не стар, вел себя как Леонид Ильич в рассвете паралитических недугов. Он ходил вразвалку, неторопливо и с наслаждением разговаривал, то и дело причмокивая. Любая деталь подолгу занимала его внимание. Однажды он набирал в юниксовой консоли команду rm -rf, и перед тем, как его отвлекли разговором, он успел еще добавить слэш, после чего переключился на собеседника. Когда разговор закончился, товарищ обернулся к монитору, нахмурился, силясь вспомнить, чем до этого занимался, и решительно прогнал проклятый скринсейвер, нажав на Enter. Надо ли говорить, что в этот момент информация, весело шурша винчестерами, удалялась со всех копий RAID и даже с удаленных реплик массива. Кстати, после этого случая я всегда возвращаю компьютер из режима сна клавишей Alt — так безопаснее.


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

    3. Восстановление из бэкапа — это крайняя мера.
    Прибегать к восстановлению надо тогда, когда других шансов уже нет. Потому что это всегда медленно и это всегда спешка и стресс. Были в нашей практике случаи, когда админы у заказчиков накатывали не тот бэкап не на ту систему, только усугубляя ситуацию.
    Поэтому восстанавливаться лучше не на исходное место на диске, чтобы не перезаписывать оригинальные данные, а куда-нибудь по соседству, чтобы была возможность проверить, что вы в итоге восстановили.

    4. Бэкап нужно хранить отдельно от данных и минимум 2 недели.
    Это рекомендуемый срок, чтобы даже нерасторопный бухгалтер успел опомниться, что у него что-то пропало или испортилось. Но можно хранить и дольше, если позволяет место.

    Традиционно для хранения бэкапов используется магнитная лента благодаря ее дешевизне.
    А еще ею удобно украшать к Новому Году серверную, особенно хорошо смотрятся композиции с оранжевой оптикой.

    Для работы с лентой предназначены стримеры и ленточные библиотеки. В стример кассеты загружает человек, а в ленточной библиотеке – робот. Поэтому библиотека предпочтительнее, т.к. позволяет автоматизировать бэкап полностью.

    Еще более предпочтительными являются дисковые хранилища, по мере удешевления производства это перестало быть роскошью. СХД отличаются скоростью работы и надежностью, конечно, при условии, что используется RAID. Есть так называемые виртуальные библиотеки – VTL – которые умеют прикидываться ленточной библиотекой, но данные записывают на диски.


    5. Бэкап нужно регулярно проверять.
    Главные недостатки ленты — последовательный доступ к информации и относительно низкая надежность хранения. Нет способа узнать, восстановится ли бэкап с ленты без ошибок, пока это не проверишь на практике. Дисковые хранилища, в отличие от ленты, защищены от размагничивания и, вообще, более предсказуемы. Тем не менее, регулярная проверка любого бэкапа позволяет спокойнее спать.

    6. Полезно дублировать бэкап на удаленную площадку.
    Техногенные катастрофы, отключения электричества в целом городе, нашествие зомби и прочие беды подстерегают бизнес на каждом углу. Особенно малоизученными остаются зомби. Поэтому хорошей практикой является наличие удаленной площадки, куда, так или иначе, попадают резервные копии.

    Как это можно организовать? В простом случае кассеты извлекаются из библиотеки, и их отвозит куда-нибудь в Химки водитель дядя Вася. Понятно, что при восстановлении также участвует дядя Вася, поэтому он во всей цепочке является самой медленной стадией. Ну а для тех, кто сумел построить или использует на аутсорсинге полноценный резервный ЦОД с хорошим каналом, резервные копии можно автоматически дублировать при помощи современных средств резервного копирования. Например, имея на каждой площадке по АПК Symantec NetBackup Appliance, можно получить полноценный DR-сайт, куда резервные копии с основной площадки попадают при помощи технологии Automatic Image Replication (AIR).

    7. Бэкап – это нагрузка на работающую систему.
    Во время копирования возможно сильное проседание по производительности основной системы. Поэтому создание резервных копий всегда планируют на период минимальной активности. Однако растет число систем, которые обслуживают запросы круглосуточно. Поэтому для минимизации нагрузки появились продвинутые техники, о которых речь дальше.

    В давние времена ночью все пользователи спали, и окно резервного копирования могло длиться, например, с 11 вечера до 7 утра. За это время все данные успевали скопироваться. Когда стало расти число систем, которые обслуживают запросы клиентов и ночью, скорость создания резервных копий стала иметь большее значение. Теперь нужно уложиться в пару-тройку часов, а для систем, работающих 24х7, в минуты. Именно поэтому рынок систем резервного копирования продолжает активно развиваться, изобретая все новые подходы.

    8. Данные можно копировать по SAN, а не по LAN.
    Большой поток копируемых данных нагружает сеть. Существует техника, которая называется LAN-free backup. Если СХД с данными и библиотеки подключены в SAN (сеть хранения данных), то вполне разумно передавать данные между СХД и библиотекой напрямую по SAN, при этом исключив загрузку локальной сети. Это часто бывает и быстрее, потому что далеко не везде локальная сеть построена на 10G, а обычный 1GB ethernet сильно уступает по пропускной способности даже не самой современной SAN.

    9. Приложения можно бэкапить на ходу…
    Создать консистентную копию данных, например, СУБД Oracle или MS Exchange без остановки работы невозможно: информация непрерывно меняется, часть ее находится в буферах, в оперативной памяти. У серьезных продуктов промышленного класса, таких как Symantec NetBackup, EMC Networker, CommVault Simpana и др., есть широкий спектр агентов для работы с различными бизнес-приложениями. Эти агенты умеет перевести приложение в режим, когда буфер сбрасывается на диск, а файлы с данными на время перестают меняться.

    10. …и минимизировать нагрузку на основную систему.
    Чтобы не держать приложение долго в таком режиме работы, эту технику можно скомбинировать с созданием снапшотов — мгновенных снимков данных. Снапшот создается быстро, после чего приложение можно «отпустить», а копировать консистентные данные уже со снапшота. Для создания снапшотов применяются в свою очередь свои агенты, которые также могут входить в состав программного обеспечения для резервного копирования.

    Если создать не просто снапшот данных, а клон, то его можно отсоединить от исходного диска с данными и передать через SAN на другой хост. И уже на другом хосте программа резервного копирования увидит эти данные и будет передавать их на резервное хранилище. Это техника называется Offhost backup.

    11. Виртуальные машины нужно стараться бэкапить средствами гипервизора.
    Современные гипервизоры, такие как VMware ESXi, предоставляют инструменты по созданию образов виртуальных машин на лету, без остановки их работы. По сути — те же снапшоты. Такой образ виртуалки бэкапится как файл, а вот топовым функционалом средств резервного копирования является возможность восстанавливать из этого образа гранулярно любой объект, например, единичное письмо электронной почты, если внутри виртуалки работал почтовый сервер. Самыми продвинутыми возможностями тут, по моему мнению, обладают продукты от Symantec.

    12. Нужно избавляться от дублей.
    Например, каждая виртуалка имеет компоненты операционной системы, которые одинаковы для всех виртуальных машин, на файловых помойках хранится множество копий одного и того же, почтовые рассылки могут дублировать в разных почтовых ящиках одинаковые письма и вложения. Дедупликация позволяет бэкапить только уникальные фрагменты данных и, причем, однократно. Степень дедупликации оказывается часто весьма впечатляющей, цифры достигают 90-98%. Об этом стоит задуматься.

    Дедупликация на клиенте. Если поначалу дедупликация выполнялась только на уровне сервера или хранилища (например, DataDomain является аппаратным решением по дедупликации), то сейчас некоторые производители реализовали дедупликацию уже на уровне клиента резервного копирования. Это позволяет не только уменьшить объем хранимой информации, но и объем информации, передаваемой от клиента. В этом случае объем между клиентом и сервером состоит преимущественно из потока контрольных сумм.

    Есть много других нюансов, все невозможно покрыть одной статьей. Главная заповедь – уделите бэкапу достаточно внимания, не откладывая на потом. И постарайтесь не доводить до того, чтобы он когда-то понадобился. И еще берегите пальцы )



    Вот такую руку мне выдали по страховке взамен порезанной. Пальцы толстоваты, но в целом нормально. Они держат чистящую кассету для ленточной библиотеки.
    КРОК 503,82
    №1 по ИТ-услугам в России
    Поделиться публикацией
    Комментарии 80
    • +62
      Насчет пальца я уже успел подумал, что будет история в духе «Вы работали на якудзу, случайно потеряли данные командой rm -rf /, оябун^1 потребовал от вас сделать юбитсуме^2, однако вовремя сделанные бекапы спасли ситуацию, все счастливы и довольны, Happy end»
      ===========
      1 — Кланом якудза руководит Оябун или Кумичё (組長, глава семьи), который отдаёт приказы подчинённым.
      2 — Юбитсуме (отрезание пальца) — это способ расплатиться за свою ошибку. За первый проступок провинившийся якудза должен отрезать конец левого мизинца и принести обрезок своему боссу.
      • +31
        Образцово показательный комментарий.
        • +1
          Я вот тут подумал, на сколько бы увеличилось качество кода если бы за ошибки делалось юбитсуме.
          Опыт работы бы сразу был бы виден, безо всяких там сиви, гитхабов и прочей мишуры. Наверное выпускались бы и клавиатуры для матерых программистов, с подушечками специальными.
          • +5
            К сожалению программисты вымирали бы слишком быстро ;(
            • +2
              Нету пальцев — ничем не рискуешь. Уже б давно был нейроинтерфейс или хотя б нормальный голосовой ввод.
            • +1
              И насколько бы уменьшилось его количество, а также количество программистов в целом :)
              • +7
                Я вот тут подумал, на сколько бы увеличилось качество кода если бы за ошибки делалось юбитсуме.
                Навеяло — «я знаю циркулярку как свои 7 пальцев!»©
                • +1
                  Точнее, «технику безопасности при работе с циркуляркой / токарным станком я знаю как свои 3 пальца».
              • +3
                Юбитсуме
                В русский язык этот термин был заимствован в форме «юбицумэ», извлекающей пользу от наличия буквы «ц» в кириллице (в отличие от латиницы), а также от различия букв «э» и «е».

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

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

                                                      Кстати, а что с Backblaze не так? У них вроде клиент не на джаве — должно милосерднее выглядеть?
                                                      • 0
                                                        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.
                                                        • +1
                                                          Восьми гигабайт хватит всем!
                                                  • 0
                                                    быстро ли у вас работает Backblaze в России?
                                                    Я несколько лет назад им пытался воспользоваться — к концу бесплатного месяца он еще не успел загрузить мои 250 Gb.
                                                  • 0
                                                    flickr терабайт предлагает. Только не скажу ничего про синхронизацию и прочее.
                                                    • +1
                                                      фликр (и любой другой фотохостинг) — средство хранения не сильно приватных фоток в готовом для просмотра виде. если вдруг захочется хранить равки, просто огромные тифы или псдшки — то приплыли, равно как и с приватностью.
                                                  • 0
                                                    Причина простая — ограниченный объем, у людей вполне может храниться по 100 гигов фоток с отпусков (никто их не сортирует, не жмет, не фильтрует по качеству… плюс видосы всякие там..). Облачные хранилища пока что на это не готовы за адекватные деньги.
                                                    Облака очень удобны для рабочих документов, написания диплома и т.п.
                                                    Людям не очень понятно, зачем платить облаку за место, если можно купить жесткий диск на шнурке… некоторые все же параноят слегка по поводу личных фотографий, а все паролить — потеря времени и удобства.
                                                    Поэтому должно быть удобно и понятно, чтобы не грузить человека лишним, но и должна быть возможность «открыть капот» и настроить алгоритм работы…
                                                    • +1
                                                      Google Drive: 100GB — 2USD/месяц. support.google.com/drive/answer/2375123?hl=en Дешево и доступно. Мне хватает. Хотя у меня папка с фоточками не особо большая, гигов 20 всего.
                                                      • 0
                                                        Облачные хранилища вполне себе готовы уже для всего. До недавнего понижения цен ситуация была такая: www.istudioweb.com/cloud-storage-comparison-2014-edition-2014-06-04/ — потом, вроде, Microsoft немного сбавил цену.

                                                        Жесткий диск на шнурке в ойфон не засунешь, а вот одной кнопкой настроить синхронизацию «все фоточге в дропбокс» — это уже элементарно.
                                                      • +1
                                                        Троян-шифровальщик без проблем накроет это хранилище. Как и внешний диск для бэкапа.
                                                        • 0
                                                          Dropbox вроде имеет-же возможность отката назад, нет?
                                                          • 0
                                                            Выше рекомендованные backblaze и crashplan имеют версионность, причём один из них хранит все изменения за 30 дней, а другой вообще неограниченно.
                                                          • 0
                                                            Не все могут позволить себе хранить данные в облаке: конфиденциальность — не последнее дело.
                                                            • 0
                                                              Да, особенно это касается фоточек с пыльного винчестера обычных пользователей. Ну, а для параноиков есть шифрование на клиенте, причём если нет доверия встроенному (в упомянутых выше бэкапных облаках есть опция шифровать своим ключом дополнительно, кроме обычного ssl при передаче), можно бэкапить зашифрованные контейнеры или типа того. И вообще обычно про конфиденциальность говорят те же люди, которые это всё сами выкладывают во все соцсети и пользуются паролями 12345 и qwerty
                                                              • 0
                                                                1. Причем здесь фоточки? В посте речь о корпоративных данных же.
                                                                2. Да, можно перед отправкой шифровать данные. Но это время и ресурсы.
                                                                3. Опять же, не последнюю роль играет скорость доступа к этим самым облакам.

                                                                Учитывая п.п.2-3, многие просто предпочитают бэкапить локально, максимум — в другой датацентр.
                                                                • 0
                                                                  1. В посте о корпоративных, а в треде — о частных.
                                                                  2. Копроративные данные в любом случае шифруются — хоть в облако, хоть на ленту.

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

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

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

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

                                                                              Вообще это тема отдельного поста, да как бы и не одного.
                                                                              • 0
                                                                                И даже целой книги может оказаться мало, но начинать с чего-то нужно:)
                                                                              • +2
                                                                                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 поддерживается.
                                                                                • 0
                                                                                  а еще ZFS может:

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

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

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

                                                                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                  Самое читаемое