Восстановление данных *

За время работы администратором баз данных я выработал для себя одно правило, которого придерживаются многие DBA. Это «золотое» правило всех администраторов баз данных – не делай ничего серьезного с базой данных, если у тебя нет бэкапа. Если ты собрался серьезно изменить параметры базы данных, провести операции по техническому обслуживанию базы данных и т.п. – то всегда перед этим надо выполнить операцию резервного копирования. Этот принцип достаточно долго работал и оправдывал себя, и даже в нескольких случаях помогал восстановить базу данных на определенный момент времени.

Страшнейший враг CD/DVD-дисков — это царапины. Из-за одной маленькой царапинки можно потерять бэкап или важный файл, записанный 10 лет назад. Но если диск перестал читаться — есть довольно высокий шанс его спасти с помощью полировки рабочей поверхности. См. инструкцию по сборке самодельной полировочной машинки.

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

В этой статье я собираюсь обсудить доступность данных, сохраненных в облаках. Вторым (и наиболее интересным) пунктом программы выступает приватность и защищенность этих данных.

Всё началось с простой задачи: скачать по 100-мегабитной сети большой объём данных с помощью rsync. Возник вопрос, можно ли ускорить этот процесс. Утилита top показала, что на сервере-источнике шифрование занимает не более 10 процентов процессора, поэтому было решено что можно попробовать сжатие данных. Тогда мне было неясно, будет ли хватать производительности процессора для упаковки данных с необходимой скоростью, поэтому была выставлена самая маленькая степень сжатия, а именно использовался флаг --compress-level=1 для rsync. Оказалось, что загрузка процессора не превысила 65%, то есть производительности процессора хватило, при этом скорость скачивания данных несколько повысилась.

После этого возник вопрос о анализе применимости распространённых программ сжатия
для передачи данных по сети.

В ответ на топик «В комнате с белым потолком».

Введение

В топике было предложено эффективное решение для устранения некоторых проблем эникеем. Дополним и означим их списком:

• Последствия работы вирусов, а, иногда, и последствия борьбы с вирусами приводят к состоянию системы, в котором она «недолечена» или «недочищена»;
• Слабое железо или жадность не позволяет использовать серьезные антивирусные пакеты;
• Ошибки пользователей или специализированных программ приводят к неменьшему ущербу, чем вредоносные программы (случай, когда у программы сложно забрать рута, а работает она не очень оптимально);
• Система подвержена естественному (для нее) «замусориванию» со временем;
• Ошибки администратора системы может приводить к серьезным последствиям (напр., неудачная попытка обновиться);
• Отсутствие автоматизированной системы для резервного копирования (напр., есть Acronis, но не сетевой);
• и прочие ...

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

IT-специалистам несложно настроить резервное копирование дома, например, с помощью rsync, созданием rar-архивов планировщиком задач, инкрементальным копированием в интернет (не говоря уже о настройке tar+cron или bacula на работе). Однако неспециалисты (для дома) будут использовать программы резервного копирования, которые много проще. Рассмотрим программу, скрывающей за привычной простотой для домашнего пользователя, гибкий и хорошо продуманный инструмент резервного копирования.

В этой статье речь пойдет о бесплатной версии Genie Timeline — Free (Noncommercial), с незначительными ограничениями и отличиями от платных версий (например, нет бэкапа с телефонов Blackberry). Стоит упомянуть, что Pro-версии используют такие компании, как NASA, Siemens, NEC, ZyXEL и Philips.

Думаю никому из присутствующих не нужно объяснять важность резервного копирования.
Проблема в том, что из десятков готовых решений ни одно толком не удовлетворяет моим требованиям standalone *NIX-сервера на колокейшене.
Чего же хотелось от резервного копирования?
1) ежедневного полного бакапа всех данных. Никаких incremental-бакапов.
2) максимально быстрого восстановления отдельно взятого файла. Архиваторы (tar/gzip/bzip2/rar) отпадают
3) быстрого мониторинга «кто именно залил вчера на сервер 156Гб?!!!»
4) резервные копии хочется хранить максимально долго, насколько хватает свободного места на дисках.
5) хочется не заботиться об ручном удалении старых копий если место на диске всё-таки уже кончилось
Если в двух словах — то мне захотелось реализовать функционал MAC OS TimeMachine на Linux-сервере.
И я начал писать скрипт.

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

В качестве примера я буду использовать openSUSE 11.4 в текстовом (минимальном) режиме на ядре 2.6.37. (можно так же его обновить до 3.1.1 несколькими командами, которые будут доступны ниже)

1. Конечно необходимо сначала установить чистую оперцаионную систему и настроить RAID. В нашем случае будет использоваться простое зеркалирование, то есть RAID 1. Это можно настроить в процессе установки операционной системы или собрать по её установке, если вы

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

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

Задача

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

Дано

• VPS на базе Centos 5 x86_64.
• Панель управления ISP Manager. Стандартные средства ISP Manager не устраивают.
• Свободного места на сервере очень мало.

Цель

Получить архивы файлов и БД на сервере в определенной папке. Архивы должны быть доступны по http-протоколу.

Если у вас возникло желание поддерживать рабочие станиции в максимально «защищённом» состоянии, а так же насколько возможно «автоматизировать» этот процесс, то этот пост для вас.

Будет использоваться:

Немного batch файла
Немного Linux сервера
Немного Windows Server 2008 R2 и Групповых политик

Идея в следующем — незаметно от самого юзера, чтобы не нарушать его работу, делать еженедельное копирование его профиля, дабы исключить потерю данных, и сохранять его на сервере в максимально защищённом виде.

Для этого начнём с клиентской части.

Добрый день, друзья. В этой статье я хотел бы рассказать, о чем стоит задуматься, прежде чем настраивать систему резервного копирования баз данных. Несмотря на то, что в первую очередь рассматривается использование данного подхода с MS SQL Server, принципы, изложенные здесь, легко проецируются на любую другую технологию. Ну что ж, поехали.

Столько всего хочется хранить на жестком диске: фильмы, музыку, программы, документы… Но, к сожалению, винчестер – не резиновый. Заставить данные потесниться смогут программы-архиваторы. Сейчас довольно сильно распространены 7Zip и WinRAR, но в данный момент по эффективности все же лидирует FreeArc. По результатам одного из самых авторитетных тестов FreeArc занял три первых места, причём c большим отрывом от соперников:

Если вы не знакомы с проблемой, когда из-за неверного обновления Ubuntu или от шалостей очередного вируса в Windows, систему нужно поднимать с колен, то дальше будет скучно.

Бэкап — это страховка системного администратора. Обычно бэкапируют данные, которые можно безвозвратно потерять — базы 1С, файлы и папки, БД Oracle, конфиги DHCP и т.д. Что же происходит с ПК, на котором трудиться обычный клерк, если неожиданно помирает HDD? Начинается круговерть — ставим ОС, накатываем ПО, учетки, принтеры и т.д.
А как же топ-директора, главный бухгалтер и другие важные личности, которым во-первых нужно так, как было, а во-вторых рабочий и настроенный компьютер уже через 30-60 минут?

Использовать Clonezilla Server (CE)!

Написано на реальных событиях.

Любое повторение действий и необдуманные решения могут привести к полной утрате данных. Не для HowTo-шников, данный материал лишь для воссоздания картины о представлении данных на дисковых носителях.

Итак, приступим. Вводные данные:

• 7 дисков, 2 primary-раздела на каждом;
• 1й раздел 7и кратное зеркалирование (RAID1);
• 2й раздел RAID5, под которым крутится LVM.

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

Здравствуйте, хабраузеры!

Хочу поделиться с вами опытом организации резервного копирования стандартными средствами FreeNas.

Для начала хотелось бы вас ввести в курс дела, чтобы читателю было легче ориентироваться в обстоятельствах моего дела, итак.

Мы имеем у нас в сети AD, со всему сопутствующими службами, много пользователей и файл-сервер, работающий на FreeNas (aka freeBSD), который дружит с доменом.

У самого FreeNas есть вариант перемещения удаленных файлов в скрытую папку .recycle Там лежат удаленные файлы, которые группируются по папкам, где название папки- %USERNAME% удалившего. Этого решения хватает, но что делать если пользователь не удаляет информацию, а изменяет?
В этом случае необходим откат самого файла, что наш файл-сервер в стандартных функциях делать не умеет.

Поэтому пишем скрипты, которые запускаем через cron.

Disclaimer: за давностью лет точную модель серверов и контроллеров установить не удалось, поэтому в тексте при упоминании модели будут оговорки и, конечно же, возможны ошибки в деталях. Сути это не меняет — ниже описана процедура преодоления отсутствия драйвера нового контроллера без Recovery Console и «глубоких» знаний Windows 2003. Вероятно, возможны более оптимальные пути решения такой проблемы, чем использование виртуальной машины.

Проблема: Сломался контроллер, выпали два SCSI диска, а потом и умер и весь сервер. Это был HP Proliant, предположительно Proliant DL380 G3 с контроллером Smartarray 6i. К утру нужно заставить работать Exchange и несколько доменов, которые крутились на сервере.

Современный мир постепенно переходит на хранение всей известной ему информации с бумажного вида на цифровой, соответственно появляется главный вопрос, вопрос защиты этой информации.




Весь мир — хранилище данных
Фото из фотобанка Лори.

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