что такое инкрементный бэкап
Инкрементальный бэкап (incremental backup) файлов ПК, флешки или сайта
Что такое инкрементальный бэкап?
Этот тип бекапа отлично подойдет для резервного копирования больших объемов исходных данных, 50 гигабайт и более. Скорость создания backup’ов будет довольно высокой, а размер каждой добавочной копии может быть всего 100-200 мегабайт.
Как сделать инкрементный бэкап с помощью Exiland Backup
Эта универсальная программа хорошо подойдет для резервного копирования файловой 1С, сайтов на WordPress и других CMS, копируя файлы сайта с FTP-сервера на локальный ПК.
После запуска, в главном окне программы, сверху на панели нажмите кнопку создания нового задания, укажите название задания, например, «Мои документы» и нажмите «Далее». Теперь как показано на скриншоте ниже, выберите тип копирования «Добавочный (Incremental)».
Скриншот программы. Выбор типа копирования.
Ниже есть возможность ограничить количество полных копий, чтобы самые старые резервные копии автоматически удалялись перед созданием новой копии. Эта настройка экономит место на диске. Также, вы можете ограничить количество инкрементальных копий между полными. При достижении этого ограничения будет создана очередная полная копия.
При выборе шаблона наименования резервных копий, вы можете добавить строку, например, » (incremental)», для инкрементных копий, чтобы визуально их легко отличать от полных.
Что такое инкрементный бэкап
Acronis Backup & Recovery 10 предоставляет возможность использования популярных схем резервного копирования, таких как «дед-отец-сын» и «Ханойская башня», а также создания собственных схем резервного копирования. Все схемы резервного копирования строятся на основе методов полного, инкрементного и дифференциального резервного копирования. Термин «схема» в действительности обозначает алгоритм применения этих методов в сочетании с алгоритмом очистки архива.
Сравнение методов резервного копирования между собой не имеет смысла, поскольку в схеме они работают в совокупности. Каждый метод должен выполнять собственную роль в соответствии со своими преимуществами. Грамотная схема резервного копирования позволяет использовать преимущества всех методов, уменьшая влияние их недостатков. Например, еженедельное создание дифференциальных резервных копий облегчает очистку архива, поскольку их легко удалять вместе с набором зависящих от них ежедневных инкрементных резервных копий, сохраняемых в течение недели.
Резервное копирование с помощью методов полного, инкрементного или дифференциального резервного копирования создает резервную копию соответствующего типа.
В полной резервной копии хранятся все данные, выбранные для резервного копирования. Полная резервная копия лежит в основе любого архива и формирует базу для инкрементных и дифференциальных резервных копий. Архив может содержать несколько полных резервных копий или состоять только из них. Полная резервная копия является самодостаточной: чтобы восстановить из нее данные, доступ к любой другой резервной копии не требуется.
Широко известно, что полная резервная копия — самая медленная для создания и самая быстрая для восстановления. С помощью технологий Acronis восстановление из инкрементной резервной копии может выполняться так же быстро, как из полной.
Полное резервное копирование наиболее полезно в следующем случае:
Примеры: интернет-кафе, школа или университетская лаборатория, в которых администратор часто отменяет изменения, сделанные студентами или гостями, но базовую резервную копию обновляет редко (только после установки обновлений программного обеспечения). Время создания резервной копии в этом случае не является решающим, а время восстановления будет минимальным, если восстанавливать систему из полной резервной копии. Для обеспечения дополнительной надежности администратор может иметь несколько полных резервных копий.
Инкрементное резервное копирование наиболее полезно в следующем случае:
Широко известно, что инкрементные резервные копии менее надежны, чем полные, так как, если повреждена одна копия в «цепочке», следующие копии уже нельзя использовать. Тем не менее хранение нескольких полных резервных копий не является оптимальным вариантом, если требуется иметь несколько предыдущих версий данных, потому что надежность слишком большого архива еще более сомнительна.
Пример: резервное копирование журнала транзакций базы данных.
Обычно считается, что «дифференциальные резервные копии дольше создаются и быстрее восстанавливаются, а инкрементные быстрее создаются и медленнее восстанавливаются». В действительности не существует физической разницы между инкрементной резервной копией, прилагаемой к полной, и дифференциальной копией, прилагаемой к той же полной резервной копии, на один и тот же момент времени. Упомянутая выше разница подразумевает, что дифференциальная резервная копия создана после (или вместо) создания нескольких инкрементных копий.
Инкрементная или дифференциальная резервная копия, созданная после дефрагментации диска, может иметь значительно больший объем, чем обычно, потому что в процессе дефрагментации изменяется местоположение файлов на диске и резервная копия отражает эти изменения. После дефрагментации диска рекомендуется заново создавать полную резервную копию.
В следующей таблице указаны общепризнанные преимущества и недостатки каждого типа резервного копирования. В действительности эти параметры зависят от множества факторов, таких как объем, скорость и характер изменения данных, их природа, физические характеристики устройств, установленные параметры резервного копирования и восстановления. Лучшим учителем в выборе оптимальной схемы резервного копирования является опыт.
Инкрементальные бэкапы postgresql с pgbackrest — курс молодого бойца от разработчика
Я — разработчик. Я пишу код, с базой данных взаимодействую лишь как пользователь. Я ни в коем случае не претендую на должность системного администратора и, тем более, dba. Но…
Так вышло, что мне нужно было организовать резервное копирование postgresql базы данных. Никаких облаков — держи SSH и сделай, чтобы все работало и не просило денег. Что мы делаем в таких случаях? Правильно, пихаем pgdump в cron, каждый день бэкапим все в архив и если совсем разошлись — отправляем этот архив куда-нибудь подальше.
В этот раз сложность состояла в том, что по планам база должна была расти примерно на +- 100 МБ в день. Разумеется, уже через пару недель желание бэкапить все pgdump’ом отпадет. Тут на помощь приходят инкрементальные бэкапы.
Интересно? Добро пожаловать под кат.
Инкрементальный бэкап — разновидность резервной копии, когда копируются не все файлы источника, а только новые и измененные с момента создания предыдущей копии.
Как и любой разработчик, СОВЕРШЕННО не желающий (на тот момент) разбираться в тонкостях postgres я хотел найти зеленую кнопку. Ну, знаете, как в AWS, DigitalOcean: нажал одну кнопку — получил репликацию, нажал вторую — настроил бэкапы, третью — все откатил на пару часов назад. Кнопки и красивого GUIшного инструмента я не нашел. Если вы знаете такой (бесплатный или дешевый) — напишите об этом в комментариях.
Погуглив я нашел два инструмента pgbarman и pgbackrest. С первым у меня просто не задалось (очень скудная документация, пытался все поднять по старинным мануалам), а вот у второго документация оказалась на уровне, но и не без изъяна. Чтобы упростить работу тем, кто столкнется с подобной задачей и была написана данная статья.
Дочитав данную статью вы научитесь делать инкрементальные бекапы, сохранять их на удаленный сервер (репозиторий с бэкапами) и восстанавливать их в случае утери данных или иных проблем на основном сервере.
Подготовка
Для воспроизведения мануала вам понадобятся два VPS. Первый будет хранилищем (репозиторием, на котором будут лежат бэкапы), а второй, собственно, сам сервер с postgres (в моем случае 11 версия postgres).
Подразумевается, что на сервере с postgres у вас есть root, sudo пользователь, пользователь postgres и сам postgres установлен (пользователь postgres создается автоматически при установке postgresql), а на сервере-репозитории есть root и sudo пользователь (в мануале будет использоваться имя пользователя pgbackrest).
Чтобы у вас было меньше проблем при воспроизведении инструкции — курсивом я прописываю где, каким пользователем и с какими правами я исполнял команду во время написания и проверки статьи.
Установка pgbackrest
Репозиторий (пользователь pgbackrest):
1. Скачиваем архив с pgbackrest и переносим его содержимое в папку /build:
2. Устанавливаем необходимые для сборки зависимости:
3. Собираем pgbackrest:
4. Копируем исполняемый файл в директорию /usr/bin:
5. Pgbackrest требует наличие perl. Устанавливаем:
6. Создаем директории для логов, даем им определенные права:
Postgres сервер (sudo пользователь или root):
Процесс установки pgbackrest на сервере с postgres аналогичен процессу установки на репозитории (да, pgbackrest должен стоять на обоих серверах), но в 6-ом пункте вторую и последнюю команды:
Настройка взаимодействия между серверами через passwordless SSH
Для того, чтобы pgbackrest корректно работал, необходимо настроить взаимодействие между postgres сервером и репозиторием по файлу-ключу.
Репозиторий (пользователь pgbackrest):
Создаем пару ключей:
Внимание! Указанные выше команды выполняем без sudo.
Postgres сервер (sudo пользователь или root):
Создаем пару ключей:
Репозиторий (sudo пользователь):
Копируем публичный ключ postgres сервера на сервер-репозиторий:
На данном шаге попросит пароль от root пользователя. Вводить нужно именно пароль root пользователя postgres сервера!
Postgres сервер (sudo пользователь):
Копируем публичный ключ репозитория на сервер с postgres:
На данном шаге попросит пароль от root пользователя. Вводить нужно именно пароль root пользователя репозитория!
Репозиторий (root пользователь, для чистоты эксперимента):
Postgres сервер (root пользователь, для чистоты эксперимента):
Убеждаемся, что без проблем получаем доступ.
Настройка postgres сервера
Postgres сервер (sudo пользователь или root):
1. Разрешим «стучаться» на postgres сервер с внешних ip. Для этого отредактируем файл postgresql.conf (находится в папке /etc/postgresql/11/main), добавив в него строчку:
Если такая строка уже есть — либо раскомментируйте ее, либо установите значение параметра как ‘*’.
В файле pg_hba.conf (так же находится в папке /etc/postgresql/11/main) добавляем следующие строчки:
2. Внесем необходимые настройки в postgresql.conf (он находится в папке /etc/postgresql/11/main) для работы pgbackrest:
3. Внесем необходимые настройки в файл конфигурации pgbackrest (/etc/pgbackrest/pgbackrest.conf):
4. Перезагрузим postgresql:
Настройка сервера-репозитория
Репозиторий (pgbackrest пользователь):
Внесем необходимые настройки в файл конфигурации pgbackrest
(/etc/pgbackrest/pgbackrest.conf):
Создание хранилища
Репозиторий (pgbackrest пользователь):
Создаем новое хранилище для кластера main:
Проверка
Postgres сервер (sudo пользователь или root):
Проверяем на postgres сервере:
Репозиторий (pgbackrest пользователь):
Проверяем на сервере-репозитории:
Убеждаемся, что в выводе видим строку «check command end: completed successfully».
Устали? Переходим к самому интересному.
Делаем бэкап
Репозиторий (pgbackrest пользователь):
1. Выполняем резервное копирование:
2. Убеждаемся, что бэкап был создан:
Pgbackrest создаст первый полный бэкап. При желании вы можете запустить команду бэкапа повторно и убедиться, что система создаст инкрементальный бэкап.
Если вы хотите повторно сделать полный бэкап, то укажите дополнительный флаг:
Если вы хотите подробный вывод в консоль, то также укажите:
Восстанавливаем бэкап
Postgres сервер (sudo пользователь или root):
1. Останавливаем работающий кластер:
2. Восстанавливаемся из бэкапа:
Чтобы восстановить базу в состояние последнего ПОЛНОГО бэкапа используйте команду без указания recovery_target:
Важно! После восстановления может оказаться так, что база зависнет в режиме восстановления (будут ошибки в духе ERROR: cannot execute DROP DATABASE in a read-only transaction). Честно говоря, я еще не понял, с чем это связано. Решается следующим образом (нужно будет малость подождать после исполнения команды):
На самом деле, есть возможность восстановить конкретный бэкап по его имени. Здесь я лишь укажу ссылку на описание данной фичи в документации. Разработчики советуют использовать данный параметр с осторожностью и объясняют почему. От себя могу добавить, что я его использовал. Если очень нужно — убедитесь, что после восстановления база вышла из recovery mode (select pg_is_in_recovery() должен показать «f») и на всякий случай сделайте полный бэкап после восстановления.
3. Запускаем кластер:
После восстановления бэкапа нам необходимо выполнить повторный бэкап:
Репозиторий (pgbackrest пользователь):
На этом все. В заключение хочу напомнить, что я ни в коем случае не пытаюсь строить из себя senior dba и при малейшей возможности буду использовать облака. В настоящее время сам начинаю изучать различные темы вроде резервного копирования, репликаций, мониторинга и т.п. и о результатах пишу небольшие отчеты, дабы сделать небольшой вклад в сообщество и оставить для себя небольшие шпаргалки.
В следующих статьях постараюсь рассказать о дополнительных фичах — восстановление данных на чистый кластер, шифрование бэкапов и публикацию на S3, бэкапы через rsync.
Виды резервного копирования: полный, инкрементальный и дифференциальный бэкап
ЗАЧЕМ НУЖНО РЕЗЕРВНОЕ КОПИРОВАНИЕ
О резервном копировании в последнее время много говорят и пишут. И мы, SIM-Networks, в том числе. 🙂
Модная тема неизбежно мифологизируется. Нам свойственно заполнять пробелы в своих познаниях выдуманными фактами и субъективными оценками. Так происходит, в частности, в том, что касается услуги резервного копирования и вопроса ее организации провайдерами хостинга. Должен ли хостер предоставлять своим клиентам резервное копирование автоматически, по умолчанию? Ответ на этот вопрос можно найти в нашем материале “5 мифов о бэкапе и хостинг-провайдерах”
Повышенный интерес к теме бэкапов неудивителен: учитывая активное развитие зловредов, опережающее развитие антивирусов, наиболее рационально строить ИТ-безопасность вокруг системы резервного сохранения информации – вместо того, чтобы тратить ресурсы на предотвращение атак и борьбу с вирусами, гораздо проще, дешевле и легче поднять систему и сохраненные данные из актуальных резервных копий.
Кроме того, актуальный бэкап поможет нивелировать последствия вмешательства форс-мажорных обстоятельств или человеческого фактора, а также сбоя оборудования вследствие разных причин. Не зря ведь одна из заповедей сисадмина гласит: готовя новый сервер к работе, вначале настрой резервное копирование!
КАК НАСТРОИТЬ БЭКАП
Бэкап можно делать самостоятельно – инструментов на сегодняшний день хватает, Google с удовольствием подскажет. Но если вы не являетесь крутым профи в области системного администрирования, лучше довериться тем, кто компетентен и способен настроить резервное копирование, полностью отвечая за результат.
Очень важно обратить внимание на два момента: копии критичной для вас информации должны делаться регулярно, а сохраняться – в удаленном месте, как можно дальше от оригиналов.
Первый момент важен потому, что информация на момент восстановления должна быть максимально актуальной для вас. Например, если ваша система поражена вирусом и единственный путь вернуть ценные данные – это восстановить их из бэкапа, то, согласитесь, будет очень обидно, если самая свежая копия вашей бухгалтерской отчетности датирована прошлым месяцем.
Важность второго момента можно проиллюстрировать так: если ваше резервное хранилище для бэкап-копий размещается на том же сервере, где и основная система, то в случае, если сервер сгорит – сгорит действительно всё. Окончательно и бесповоротно.
Поэтому заботимся о правильном расписании бэкапов и обеспечиваем удаленность хранилища для копий.
ОСНОВНЫЕ КРИТЕРИИ ВЫБОРА ПРОГРАММЫ ДЛЯ БЭКАПОВ
В том случае, если вы все-таки хотите рискнуть и самостоятельно заняться организацией резервного копирования ваших данных, в поиске программы для бэкапов эксперты рекомендуют руководствоваться четырьмя универсальными критериями:
Современное ПО, используемое профессиональными админами, всегда соответствует этим критериям. Кроме того, люди, специально обученные и имеющие за плечами богатый и разнообразный опыт настройки резервного копирования, могут подобрать наиболее оптимальный вариант бэкапа для каждого конкретного случая. Поэтому все-таки настоятельно рекомендуем обращаться за помощью к специалистам, чтобы не было потом мучительно больно от затертых правильных копий, поверх которых записывается ошибочная информация. Понятно, что восстановление таких версий резервных копий не принесет вам желаемого результата, ведь исходные корректные данные утрачены. Так бывает, если выбран неподходящий метод копирования и слишком мал объем резервной СХД.
Поговорим теперь о видах бэкапа – полном, инкрементальном и дифференциальном. Они различаются способом копирования и сжатия информации.
ПОЛНЫЙ БЭКАП (FULL BACKUP)
Тут все понятно из названия: каждый раз, согласно заданию на бэкап, создается полная копия всей системы, точнее, всех тех данных, которые вы определили для резервного копирования при постановке задачи. Для уменьшения итогового объема резервной копии все данные сжимаются в архив. Таким образом, в вашем хранилище при полном резервном копировании с заданной периодичностью появляются архивы, где данные в основной своей массе дублируются (поскольку на протяжении долгого времени не изменяются). Это серьезный недостаток, ведь расходуется огромный объем ресурсов (см.п.1 в списке критериев бэкапа): место в хранилище, время создания и процессорное время, вычислительные мощности, наконец, ресурсы трафика при транспортировке архивов в удаленную СХД. И хотя метод полного копирования ранее был очень распространенным из-за высокой надежности, в чистом виде на сегодняшний день он признан малоэффективным. Например, для резервного копирования невысокой глубиной (менее двух недель) или с высокой частотой (раз в сутки, раз в несколько часов) полный бэкап чрезмерно расходует ресурсы.
Немного спасет ситуацию механизм дедупликации – выявление и удаление дублирующихся данных в полных копиях. Он также задается специальными программными средствами как на уровне СХД или сервера, так и на клиенте непосредственно. Статистика в некоторых источниках приводит впечатляющие результаты степени дедупликации – от 90% до 98%.
Преимуществом полного бэкапа можно назвать разве что скорость восстановления: когда данные поднимаются из одного архива, это происходит быстрее, чем при инкрементальном или дифференцированном бэкапе.
На сегодняшний день метод полного резервного копирования, как правило, используется исключительно как базовый в сочетании с другими методами, менее ресурсоемкими. Иногда такой подход называют еще смешанным или синтетическим бэкапом.
ИНКРЕМЕНТАЛЬНЫЙ, ИЛИ ИНКРЕМЕНТНЫЙ, БЭКАП (INCREMENTAL BACKUP)
По сравнению с full backup гораздо экономичнее и быстрее, поскольку в этом процессе копируются только те файлы, которые изменились со времени предыдущего резервного копирования. Исходные данные, записанные изначально, не перезаписываются. Механизм инкрементального копирования прост: в качестве начальной точки бэкапа Х0 выбирается время (например, полночь с воскресенья на понедельник), в которое делается полный бэкап; в точке Х1 (полночь с понедельника на вторник) делается копирование файлов, измененных и/или появившихся с момента Х0; в точке Х2 (полночь со вторника на среду) копируются файлы, измененные/появившиеся с момента выполнения Х1; … в точке Хn происходит завершение цикла и делается следующий полный бэкап.
Этот метод гораздо более экономично расходует ресурсы и места в хранилище, и времени, и трафика передачи данных, по сравнению с другими. Однако при восстановлении данных в случае необходимости из резервной копии происходит поэтапное восстановление из точек Хn-1…Х2, Х1, Х0 – до последнего полного бэкапа включительно, и этот процесс может занять много времени.
ДИФФЕРЕНЦИАЛЬНЫЙ БЭКАП (DIFFERENTIAL BACKUP)
Выигрывает перед инкрементальным в случае восстановления данных – время на эту операцию у него меньше, поскольку сравниваются полные копии Х0 и Хn и не требуется поэтапного восстановления. Однако в части объема пространства для размещения в СХД дифференциальное резервное копирование сопоставимо с полным, поэтому экономии места в хранилище и трафика практически не достигается.
При дифференциальном бэкапе происходит копирование «нарастающим итогом»: каждый измененный файл в каждой последующей точке бэкапа копируется заново. То есть выглядит это как: Х0, Х1, Х1+Х2, Х1+Х2+Х3, … +Хn, Х0+Х(1+…n)
Словом, очень громоздко и сложно при расчете места в СХД.
Понять разницу между инкрементальным и дифференциальным бэкапом достаточно просто. Фактически – она в одном слове. Просто сравните:
ДРУГИЕ ВИДЫ РЕЗЕРВНОГО КОПИРОВАНИЯ
Разновидностью дифференциального бэкапа считается дельта-копирование (дельта-блочное или дельта-стилевое резервное копирование). При таком методе в копию записываются только изменения, происходящие в файлах, а не переписываются полностью изменяемые данные. То есть копируется частичка, а не весь файл. Правда, дельта-блочный метод можно применить именно на изменяемые, а не на создаваемые файлы – поэтому новые файлы копируются целиком.
Его отличает высокая скорость создания, крайняя экономия места и значительно меньшее (в сравнении с инкрементальным и дифференциальным бэкапами) количество избыточных данных. Казалось бы, применять дельту должны все, но этого не происходит, поскольку создание бэкапов таким способом и восстановление информации происходит средствами специального ПО. Кроме того, восстановление из дельта-бэкапа происходит очень долго: данные приходится собирать из мозаики измененных кусочков. Тем не менее, этим методом удобно пользоваться для обеспечения непрерывной защиты данных (когда бэкап файла делается непосредственно после его создания или внесения в него изменений – механизм, который отдаленно напоминает автосохранение в файлах Word’а))) или в случаях пониженной пропускной способности при сохранении резервных копий в удаленном СХД.
Аналогично дельта-блочному бэкапу действует разработанный программистами метод бинарных патчей, при котором копируются частички измененных файлов, но применяется другая база сравнения (в дельте – блоки, в этом методе – биты информации).
Однако необходимо иметь в виду, что оба упомянутых метода применяются в связке с дифференциальным или инкрементальным резервным копированием, но не сами по себе.
Иногда резервным копированием называют технологию зеркалирования, используемую, к примеру, на аппаратном уровне в RAID1 или при создании сайтов-зеркал. По сути же это – простое копирование исходных и измененных файлов, без архивирования и систематизации накопления изменяемых файлов в заданном периоде.
За последние 12-15 лет в технологиях резервного копирования произошло много критических изменений, заставивших пересмотреть эффективность подходов и открыть новые способы. Например, внедрение технологии снэпшотов (snapshots) – моментальных «снимков» файловой системы, из которых можно «склеить» резервную копию, – позволяют в облачных системах делать резервное копирование быстро и безболезненно, не останавливая виртуальной машины. Кроме того, применяясь в облаке, снэпшоты позволяют серьезно экономить ресурс СХД, поскольку на диске клиента они места не занимают.
КЛИЕНТЫ SIM-NETWORKS ВЫБИРАЮТ БЭКАП!
Конечно, если вы любите все делать самостоятельно, для вас не составит проблемы настроить резервное копирование вручную – на своем домашнем компьютере. Правда, даже в этом случае есть частичный риск, ведь что-то может пойти не так, и ценные фотографии, книги, видеозаписи или расчеты ракетной ступени случайно могут не сохраниться или сохраниться с дефектом, который сделает невозможным их восстановление из резервной копии. А если речь идет об офисных машинах? Как быть, если необходимо обеспечить бэкап данных, которые хранит корпоративная инфраструктура? Мы рекомендуем все-таки полагаться не на собственные силы, а на профессионализм хостинг-провайдера. Заказать настройку резервного копирования и пространство для удаленного хранения резервных копий в Германии – это очень просто.
Если вы арендуете мощности в нашей облачной инфраструктуре SIM-Cloud, заказать услугу резервного копирования SIM-Cloud BaaS Backup-as-a-Service, проще простого, в пару кликов. Всё уже настроено и будет подключено автоматически, как только вы дадите команду. Кстати, когда наши инженеры разрабатывали SIM-Cloud BaaS, они проанализировали эффективность разных типов бэкапа и остановили свой выбор на методе инкрементального копирования. Наше резервное копирование в облаке оптимизировано таким образом, что показатель RTO (время восстановления данных из копии) составляет в среднем от 15 до 30 минут в зависимости от объема данных. Облачный BaaS от SIM-Networks соответствует всем заявленным выше критериям высококачественного резервного копирования.
Резервное копирование критически важных для бизнеса данных в наши дни стало насущной необходимостью. А еще – частью комплексных мер по обеспечению информационной безопасности компании, о которых мы писали в материале Кибербезопасность организации: защищаем информационный периметр
Создайте собственный выделенный сервер
Вы можете самостоятельно выбрать, в каком дата-центре организовать хранилище для бэкапов. Первый вариант – локальное хранение: ваши резервные копии хранятся в том же ДЦ, где развернута ваша основная инфраструктура. Это дает возможность ускорить RTO и RPO. Второй вариант – бэкапы отправляются на хранение в дата-центр, удаленный от того, в котором развернута основная инфраструктура. Восстановление данных в этом случае будет происходить немного медленнее, но фактор безопасности выше. Если вы сомневаетесь, какой вариант выбрать, обратитесь в нашу службу Customer Care – вам помогут подобрать оптимальное решение.
А приверженцам классического «железа» мы предлагаем аренду удаленного хранилища для резервных копий: надежного, безопасного, высокотехнологичного. И, разумеется, наши высококвалифицированные эксперты поддержки помогут вам настроить необходимую периодичность, глубину и другие параметры резервного копирования вашей системы.