@dyukarev92
сисадмин

Стоит ли делать резервное копирование в облако?

Коллеги всех приветствую!
Хотелось бы узнать Ваше обоснованное мнение.
Руководство предлагает делать резервное копирование в облако, для того что бы не покупать сервак для бэкапов. Пока суть не в деньгах, хочу сначала понять есть ли смысл, и кто сталкивался какое ваше мнение?
Копироваться будут документы, чертежи и базы sql. Копирование ВМ в облако пока не рассматриваю.
Почитав интернаты, интересные сервисы предлагает акронис. Что думаете?
  • Вопрос задан
  • 374 просмотра
Пригласить эксперта
Ответы на вопрос 7
Jump
@Jump Куратор тега Резервное копирование
Системный администратор со стажем.
Стоит ли делать резервное копирование в облако?
Да, это хорошее дополнение к локальному хранилищу бэкапов.

Руководство предлагает делать резервное копирование в облако, для того что бы не покупать сервак для бэкапов.
Сначала покупают сервак для бэкапов, настраивают резервное копирование, после чего дублируют в облако при желании.

Почитав интернаты, интересные сервисы предлагает акронис. Что думаете?
Дорого, и доверия особого не вызывает. Amazon S3 Glacier явно получше будет.

P.S.
По моему мнению Glacier идеальное хранилище для бэкапов - достаточно надежно, и самые низкие цены на хранение. Он несколько сложноват в освоении, и цена получения данных оттуда достаточно высока - но так это холодные данные, которые в идеале и не должны оттуда вытаскиваться. Только в крайнем случае. А локальный бэкап это обязательно - особенно если у вас приличные объемы данных. Вы просто оцените ширину своих каналов, и скорость отдачи от облака и подумайте сколько времени вы будете вытаскивать данные в случае нештатной ситуации, когда нужно как можно быстрее возобновить работу критичных для организации сервисов.
Ответ написан
Комментировать
@rPman
Онлайн, помимо удобства и высоких цен дает еще один момент - низкая скорость восстановления после сбоя. Если у вас терабайты данных, вы можете столкнуться с проблемой единомоментной выгрузкой всех данных обратно, когда это станет необходимо. Поймите, это и так будет момент стресса для компании, где лишние сутки другие могут стоить столько денег, что кажущиеся затраты на локальный сервер покажутся копейками.

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

p.s. СВОЙ локальный сервер для хранения бакапов будет по определению дешевле, удобнее,.. и размещать его можно в соседнем датацентре а не у себя в подсобке.
Кстати, в 90% случаев, для мелких организаций бакапом может являться просто последовательная запись дисков, подключаемых по usb

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

Формат, в зависимости от того, что у вас за данные, может быть от простого архива 7zip (изменения файлов могут быть оценены по дате или файловому атрибуту - архивирован) до красивого архиватора на базе rsync, теневых копий и символических ссылок (одно время пользовался простейшим bat файлом, который создавал в целевом каталоге, с датой архивации, полную копию моих файловых разделов, где для не изменившихся файлов использовалась символическая ссылка на предыдущую копию, дико удобно, старую реплику можно было удалить просто удалив каталог, а восстановление - обычное копирование, плюс можно по каталогам пройтись и взять любой файл не только последней версии но и по дате архивации).
Ответ написан
Комментировать
@nrgian
В 2 разных облака. Для надежности.
Смотря что за данные, может оказаться и не удобнее, чем на свой сервер. Или удобнее. (имею ввиду: скорость, цена)
Ответ написан
inoise
@inoise
Solution Architect, AWS Certified, Serverless
Интересные варианты предлагают AWS и Azure. Остальное от лукавого)

И да, стоит делать в облако дампы, но не только по тому чтобы не покупать сервак
Ответ написан
Комментировать
CityCat4
@CityCat4
//COPY01 EXEC PGM=IEBGENER
Если с шифрованием, которое делаете сами - ну, тут нужно только учесть что недавно подписали закон о безопасности от Рунета :) Может так случиться, что трах, бах - и нет у вас бэкапов :)
Если без шифрования или же "шифрование от провайдера" - ну, тоже можно. Хостеру и всем заинтересованным ваши документы и чертежи возможно покажутся интересными... ":)
Ответ написан
Moskus
@Moskus
Не забудьте рассмотреть вариант аренды не-облачного сервера. Облако - не единственная возможность "не покупать сервер" (если речь о локальном сервере). Именно облако хорошо, по большому счету, только возможностью платить только за то, что вы реально используете.
Ответ написан
Комментировать
@mezhuev
Системный администратор
Руководство предлагает делать резервное копирование в облако, для того что бы не покупать сервак для бэкапов.

Первое не исключает второго. Есть золотое правило резервного копирования «3-2-1»:
  1. Три физически разделённые резервные копии. Разные папки на одном сетевом хранилище считаются одним местом.
  2. В двух различных форматах хранения. Например, простая копия через rsync и в специализированном формате выбранного средства резервного копирования.
  3. Одна из копий должна быть вне офиса. Облако подходит, но так же это может быть сервер в другом филиале.

Можно упростить данное правило до «2+1», то есть две копии локально и одна удалённо.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы