Рубрика «veeam backup» - 2

Новые возможности Veeam Backup & Replication 8.0: усовершенствованная репликация
Как можно догадаться из названия продукта, столпами реализуемой в Veeam Backup & Replication стратегии защиты данных являются «2-в-1»: резервное копирование и репликация, реализованные в рамках одного продукта.

Достоинством механизма резервных копий является возможность отката на различные точки восстановления в прошлом, механизм же репликации позволяет получить минимальный показатель времени восстановления системы после сбоя — этим она особенно ценна для современных ЦОД. Сегодня я расскажу о новых возможностях репликации, которые увидят свет с выходом (уже в ноябре!) новой версии Veeam Backup & Replication 8.0.
Читать полностью »

Как стало известно из KB (2090639) в гипервизорах VMware ESXi версий начиная с 4.х и до актуальной при обращении командой QueryChangedDiskAreas для запроса информации о занятых дисковых секторах виртуальных дисков возвращаемое значение может быть неправильным или отсутствовать вовсе. Под риском находятся все ВМ размер vmdk диска которых превышает 128 GB. Чем это чревато — все утилиты бэкапа которые используют этот механизм (к примеру Veeam) могут создать невалидные резервные копии. Временное решение — полное отключение механизма CBT для всех виртуальных машин. Однако это увеличит продолжительность резервного копирования.
Для получения актуальной информации по теме подпишитесь на KB указанный в начале.

P.S в новостной рассылке Veeam есть ссылка на скрипт PowerShell для отключения СBT на всех виртуальных машинах.Читать полностью »

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

И, так как “плясать начинают от печки”, мы рассмотрим ситуацию с самого начала — с принципов, лежащих в основе виртуальных бекапов, немного копнем внутрь и раскроем одну очевидную проблему, которую не учитывает около 90% администраторов виртуальных сред. Также отмечу, что для упрощения повествования описания всех функций будут даваться на основе функционала гипервизора от VMware, как наиболее прозрачного и документированного.
Читать полностью »

1998 год, Студия Pixar. Полным ходом идет создание «Истории игрушек 2». В процессе участвует более 150 человек. Размер исходных материалов анимации составляет 10 ГБ (по тем временам это очень много). Каждый день строится полный бэкап на ленту. Кассета имеет размер… 4ГБ (данные при записи на ленту сжимаются, но, конечно, не до такой степени). Каждый раз выдается ошибка, но этого никто не замечает, потому что лог-файл располагается на этой же кассете и пишется в самом конце бэкап-задания, а, поскольку места на кассете уже нет, он имеет размер 0 байт. Каждую неделю проводится тестовое восстановление данных, в ходе которого проверяются первые 2000 кадров анимации. И, конечно, каждый раз тест проходит успешно.

… А потом вдруг наступил день, когда кто-то из сотрудников (ошибочно или намеренно) запустил на сервере команду "/bin/rm -r -f *" (или аналогичную), которая удалила 90% из 100,000 файлов исходников анимации. Один из сотрудников компании, Ларри Катлер, как раз просматривал файлы папки с исходниками анимации, собираясь откорректировать что-то в модели шляпы персонажа Вуди, как вдруг он заметил, что файлов в папке осталось всего 40… потом 4… а еще через секунду их там не осталось вовсе. Ларри позвонил в ИТ службу и сообщил, что "произошла масштабная потеря данных", и что "восстановление потребует полную резервную копию..." Которой, как выяснилось чуть позже, у них не было, несмотря на ежедневный бэкап.

Читать полностью »

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

Правило резервного копирования «3 2 1». Часть 1

Итак, правило «3-2-1» гласит, что для обеспечения надежного хранения данных, необходимо иметь как минимум:

  1. ТРИ резервные копии,
  2. которые должны быть сохранены в ДВУХ различных физических форматах хранения,
  3. причем ОДНА из копий, должна быть передана на внеофисное хранение

Все три составляющих правила базируются на принципе обеспечения отказоустойчивости через избыточность хранения данных.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js