`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Что для вас является метрикой простоя серверной инфраструктуры?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Ирина Рундель

11 типичных ошибок облачного бэкапа

+33
голоса

Сколько бы не писали статей о бэкапе, их никогда не хватит, чтобы предотвратить все возможные промахи пользователей. Однако есть и хорошая новость — при выполнении резервного копирования, как правило, совершаются одни и те же ошибки. Это дает возможность их обозначить, проанализировать и систематизировать, и в будущем защитить себя от неприятностей. В новой статье мы собрали самые распространенные ошибки и заблуждения, связанные с бэкапом данных (в том числе облачным). Читайте и учитесь на чужих, чтобы не допускать свои:)

1. Вы храните все резервные копии на одной площадке

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

2. Вы не проверяете бэкапы на целостность и актуальность

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

3. Вы предоставляете серверам доступ к системе резервного копирования

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

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

4. Вы путаете термины «синхронизация» и «бэкап»

Некоторые пользователи считают, что резервную копию делать не нужно, так как файлы синхронизируются. Напомним, что «синхронизировать» означает сохранить и согласовать файлы между определенным количеством устройств. Если вы внесете изменение в содержимое файла, оно также отобразится в соответствующих файлах на других синхронизированных устройствах. Это касается и нечаянного удаления файлов. Возможно, решения для синхронизации хороши для личного пользования, но когда речь идет о данных компании, потери могут привести к масштабным последствиям. Синхронизацию можно использовать для удобства работы сотрудников, но резервное копирование она не заменит.

5. Ваши резервные копии ни о чем вас не предупреждают

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

6. Вы предполагаете, что удаленные файлы хранятся всегда

Публичные облачные провайдеры на какое-то время сохраняют удаленные файлы, но в большинстве случаев этот срок не превышает 30 дней. Как только вы удалили файл, он перемещается в очередь для полного удаления. Dropbox хранит удаленные файлы в течение 30 дней, а для тарифных планов Professional и Business — 120 дней. OneDrive сохраняет файлы 30 дней. Помните, что после полного удаления данные теряются безвозвратно.

7. Вы бездумно открываете доступ к данным сторонним приложениям

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

8. Вы не закрываете приложения и запускаете бэкап

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

9. Вы не структурируете файлы и папки

Конечно, хаос в документах никак не повлияет на сам факт резервного копирования. Но когда приходит время disaster recovery, опрометчивость решения не структурировать данные выливается в массу потерянного времени. Как правило, полное восстановление информации — довольно редкое явление. В основном требуется «возвращать» лишь несколько ключевых файлов, причем делать это нужно как можно быстрее. Рекомендуем хорошо отсортировать информацию в несколько легкоуправляемых кластеров. И чем проще будет эта структура, тем лучше. Можно также установить соответствующие права доступа для определенных категорий папок, чтобы предотвратить утечки.

10. Вы считаете, что сможете избежать ошибок

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

11. Вы не учитываете конкретные потребности своей компании

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

Заключение

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

11 типичных ошибок облачного бэкапа


Вы можете подписаться на наш Telegram-канал для получения наиболее интересной информации

+33
голоса

Напечатать Отправить другу

Читайте также

Ирина, а кому адресованы ваши статьи, на этом сайте? Например,эта - про бэкапы. Я не иронизирую, я вполне искренне интересуюсь Вашими мотивами. Ведь, если сюда заглядывают CIO или IT директоры, то -
они ведь уже в курсе профильных вопросов. Спасибо.

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

Поддержу. Помимо образовательных материалов всегда нужны Уставные: 10 заповедей христианина, 7 смертных грехов, 5 пороков команды, 3 орешка для Золушки итд

Это Золотой фонд.

Дякую. Згода, нагадувати про прописні і розумні істини - завжди не зайве. Років 15-ть тому, я втратив все своє цифрове майно, разом з одним згорілим HDD. Відновити, зрізних джерел, вдалося заледве 10-15 відсотків. З того часу я маю, щонайменьше, - три копії надважливих бекапів: зашиіфроване на "хмарі", на зовнішньому диску, що підключається лише для оновлення бекапів і на домашньому NAS. А, от з робочими потужньостями - все не так просто: користуватися "хмарами" - забороняє внутрішній протокол безпеки, а об'єми даних, особливо відео і зображень, пов'заних з авторським правом - величезні. Використовуємо три окремих, розташованих в різних країнах сервери від https://en.wikipedia.org/wiki/Quantel#Quantel-designed_technologies. Дані зберігаються зашифрованими і "перемеленими" і "вивантажуються" на конкретний запит, конкретного авторизованого користувача. А бекапа, як такого, - немає. Просто чітко категоризуються дані і у різних категорій - різний термін зберігання. Сервери, між собою,-"страхуються", звісна річь.

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT