Резервная копия: Резервное копирование данных на устройствах iPhone, iPad и iPod touch

Содержание

Резервная копия писем — Почта. Справка

Внимание. Доступно только с Яндекс 360 Премиум.

Хранить все удаленные письма
Создать резервную копию
Восстановить письма из копии
Удалить копию
Что будет, когда Премиум закончится?

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

С опцией Хранить удалённые письма вам в течение полугода будут доступны все письма, которые были удалены из ящика.

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

Чтобы восстановить такие письма:

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

Внимание. Если вы отключите эту опцию, все удаленные письма, которые не были сохранены в резервной копии, исчезнут безвозвратно.

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

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

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

Из резервной копии восстанавливаются те письма, которые были удалены из ящика с момента создания резервной копии.

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

Примечание. Восстановление писем происходит не быстро. Письма будут постепенно появляться в ящике.

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

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

9 способов ускорить резервное копирование / Хабр

Увы, резервное копирование не всегда происходит быстро. На скорость создания копии влияют десятки факторов, и из-за этого часто страдают бизнес-процессы, снижается производительность, а главное — данные остаются незащищенными. Сегодня я расскажу о том, как можно ускорить резервное копирование, устранив одно или несколько “узких мест” в архитектуре. Если вы задаетесь вопросом, оптимально ли настроено резервное копирование, вас не устраивает скорость создания резервных копий, либо данные вовсе не успевают перемещаться в заданные хранилища, то добро пожаловать под кат! Обсудим, что с этим можно сделать.

Привет, Хабр! Меня зовут Дмитрий Ермолаев, и я руковожу технической поддержкой в компании “Киберпротект”. И хотя в большей степени опыт нашей команды относится к продукту Кибер Бэкап, практически все советы можно применить и к другим системам резервного копирования, ведь фактически скоростному созданию аварийной копии мешают одни и те же факторы. Возможно, какие-то из пунктов покажутся вам очевидными — и это значит, что вы уже не новичок в работе с резервным копированием. Но сотни обращений в нашу техподдержку по этим вопросам подтверждают, что многие просто устанавливают систему “из коробки” и не в курсе, как именно улучшить процессы резервного копирования.

1. Бэкапить блоки, даже если нужны файлы

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

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

2. Использовать инкрементное резервное копирование

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

Тут, конечно, можно возразить, что инкрементный бэкап сложнее и отнимает ресурсы ЦП для создания образов и их последующего восстановления. Но, как показывает практика, уровень дополнительной нагрузки на процессор обычно не превышает 1%. Так что инкрементный бэкап стоит свеч в 90% случаев и позволяет ускорить РК. Например, в Кибер Бэкапе можно просто включить опцию “всегда инкрементное” для уже настроенных или новых планов резервного копирования. Эта схема раскрывает потенциал работы специального формата резервных копий “Киберпротекта” и в результате дает одновременно эффективную дедупликацию и сжатие, а также высокие скорости восстановления даже при длине цепочки 100+ точек. Как она работает я подробнее расскажу в отдельном посте.

3. Оптимизировать файловую систему

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

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

Кстати, если ваши резервные копии реально большие, а диск или том используется только для этой задачи, можно столкнуться с ограничением файловой системы на максимальное количество сегментов файла (~1,5 миллионов). Достаточно запустить параллельное резервное копирование 2-3 виртуальных машин с образами, скажем, по 500ГБ, и на томе NTFS с размером кластера 4 кб (по умолчанию) возникнут проблемы с дальнейшим расширением скопированных образов.

4. Использовать резервное копирование на уровне гипервизора

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

Решить эту проблему можно за счет интеграции СРК и гипервизора. В этом случае на виртуальных машинах не устанавливаются отдельные агенты, а СРК производит резервное копирование извне, используя свободные ресурсы кластера. В результате никакого снижения производительности не происходит. А учитывая, что все больше СРК поддерживают широкий спектр гипервизоров, подобный подход оправдывает себя полностью. Мы тоже работаем с разными гипервизорами — от VMware и oVirt до российских разработок, таких как ECP VeiL или РЭД Виртуализация. Кстати, работа по тестированию и устранению багов в таких связках была проведена нешуточная, и мои коллеги обязательно расскажут об этом в блоге в ближайшее время.

5. Развести процессы резервного копирования ВМ по времени

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

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

Может оказаться так, что нормальный такой двухпроцессорный сервер с 500 Гбайт ОЗУ не тянет сразу несколько процессов резервных копий…потому что они попадают на медленные накопители, которые не справляются с потоком операций ввода/вывода. В этом случае можно настроить план резервного копирования и развести операции по времени — и волки сыты, и апгрейдить сервер по конским ценам не нужно.

6. Минимизируйте нагрузку на сеть

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

Для того, чтобы нагрузка на сеть стала меньше, можно использовать сжатие и дедупликацию данных. Практически все современные СРК это поддерживают, но не все пользователи знают, что сетевая папка для успешной работы алгоритмов оптимизации должна соответствовать определенным требованиям. Например, в Кибер Бэкапе необходимо использовать сетевую папку с версией протокола SMB 2.1 (а лучше 3.1+), чтобы сжатие и дедупликация работали автоматом и на лету. Тогда неуникальные фрагменты информации не будут даже попадать на сетевой адаптер.

7. Или вообще не используйте сеть

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

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

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

Работает такая схема надежно. Мы неоднократно тестировали ее в разных средах виртуализации, в том числе c VMware. На сервере просто устанавливается ОС Windows и агент бэкапа WMware. После этого на него отправляются LUN, на которых находятся датасторы хостов ESXi.

Подключенные LUN не инициализируются в ОС и не используются на запись. Но в момент резервного копирования, после создания снимка виртуальной машины, агент обращается к презентованным ему дискам SAN, забирает из них данные дисков виртуальных машин и сохраняет резервную копию на свои локальные диски.

8. Выделить больше ресурсов для Virtual Appliance агентов для VMware.

Раз уж мы заговорили о виртуализации и VMware, нельзя не упомянуть такой простой метод ускорения, как увеличение производительности виртуальных устройств, который актуален также для oVirt, ECP Veil, Кибер Инфраструктуры и некоторых других. По умолчанию агенты для резервного копирования в экосистеме VMware создаются как двухъядерные виртуальные машины с 4 Гигабайтами оперативной памяти. И, что интересно, увеличение количества памяти до 8-10 ГБ ведет к серьезному росту производительности бэкапа. А если нагрузка сложная и данные требуют тщательной дедупликации и сжатия, можно также накинуть и количества ядер.

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

9. Отключить многотомные снимки VSS

Многотомные моментальные снимки VSS — полезная штука. Они позволяют синхронизировать данные между всеми томам на компьютере, создавая теневую копию. Такой подход активно используется для работы с тяжелыми и ответственными инфраструктурами, например часто применяется для СУБД Oracle. Но проблема в том, что синхронизация приводит к тому, что работа с дисками происходит одновременно, а не последовательно.

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

Заключение

Все разработчики (и мы в том числе) стремятся сделать резервное копирование простым коробочным продуктом. И это во многом получается. Например, сегодня можно просто взять и установить СРК не только на Windows или в экосистеме VMware, но и на операционные системы из реестра российского ПО или на отечественные системы виртуализации. И все будет работать без дополнительного обращения в техподдержку. Однако вопросы тонкой настройки остаются актуальными, и нередко одно из приведенных выше 9 правил позволяет ускорить резервное копирование.

Не буду спорить, эта задача вообще не всегда актуальна. Если объем защищаемых данных невелик, а ресурсов в системе достаточно, можно обойтись вообще без оптимизаций. Но если скорость стала снижаться, и это влияет на время создания копий (не удается перенести данные за нужный промежуток времени) или на работу пользователей (тормозят основные процессы), стоит попробовать и ускорить РК, какой бы системой вы ни пользовались.

О резервной копии — Руководство пользователя для VMware vSphere

В этой статье

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

Veeam Backup & Replication поддерживает резервное копирование для следующих типов резервных копий:

Резервные копии виртуальных машин VMware vSphere или VMware Cloud Director, созданные с помощью Veeam Backup & Replication
Резервные копии виртуальных машин Microsoft Hyper-V, созданные с помощью Veeam Backup & Репликация

Резервные копии виртуальных и физических машин, созданные с помощью Veeam Agent для Microsoft Windows, Veeam Agent для Linux, Veeam Agent для Mac, Veeam Agent для Oracle Solaris или Veeam Agent для IBM AIX

Резервные копии виртуальных машин Nutanix AHV, созданные с помощью Veeam Backup for Nutanix AHV
Резервные копии баз данных Oracle, SAP HANA и Microsoft SQL Server, созданные с помощью подключаемых модулей Veeam для корпоративных приложений
Резервные копии, хранящиеся в репозитории резервных копий HPE StoreOnce

Резервные копии файловых ресурсов, созданные с помощью Veeam Backup & Replication

Резервные копии инстансов Amazon EC2, созданные с помощью Veeam Backup для AWS
Резервные копии виртуальных машин Microsoft Azure, созданные с помощью Veeam Backup для Microsoft Azure
Резервные копии экземпляров ВМ, созданные с помощью Veeam Backup для Google Cloud

Резервные копии, созданные с помощью Veeam Backup для RHV
Резервные копии, экспортированные политиками K10

Важно

При копировании резервных копий, созданных с помощью Veeam Backup для AWS, Veeam Backup для Microsoft Azure или Veeam Backup для Google Cloud:

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

Когда начинается процесс резервного копирования, Veeam Backup & Replication обращается к файлам резервных копий в исходном репозитории резервных копий, извлекает блоки данных для конкретной машины из файла резервной копии, копирует их в целевой репозиторий резервных копий и компонует скопированные блоки. в файл резервной копии в целевом репозитории резервных копий. Процесс резервного копирования не затрагивает ресурсы виртуальной и физической инфраструктуры, не требует создания дополнительных снимков ВМ или снимков VSS и не создает нагрузки на машины, резервные копии которых копируются.

Резервное копирование — это управляемый заданием процесс. Для копирования резервных копий необходимо настроить задания резервного копирования. Задание резервного копирования определяет, когда, что, как и куда копировать. Дополнительные сведения о создании заданий резервного копирования см. в разделе Создание заданий резервного копирования для виртуальных машин и физических машин. Обратите внимание, что для копирования резервных копий файлового ресурса необходимо настроить задание резервного копирования файлового ресурса, а не задание резервного копирования. Дополнительные сведения см. в разделе Создание заданий резервного копирования файловых ресурсов.

См. также

Как работает резервное копирование
Создание задания резервного копирования для виртуальных машин и физических машин
Создание задания резервного копирования для репозитория HPE StoreOnce
Создание задания резервного копирования для баз данных Oracle и SAP HANA

Страница обновлена 08. 06.2023

Как работает резервная копия — Руководство пользователя для VMware vSphere

В этой статье

Veeam Backup & Replication выполняет резервное копирование следующим образом:

[Только для заданий резервного копирования ВМ] Veeam Backup & Replication подключается к серверам vCenter и хостам ESXi для сбора информации о ВМ, точки восстановления которых вы хотите скопировать.
Для процесса резервного копирования Veeam Backup & Replication запускает два Veeam Data Mover — исходный Veeam Data Mover и целевой Veeam Data Mover. Расположение Veeam Data Movers зависит от типа репозитория резервных копий и пути передачи данных. Дополнительные сведения см. в разделе Архитектура резервного копирования.
При первом запуске резервной копии всегда создается файл полной резервной копии.
Veeam Backup & Replication копирует блоки данных, необходимые для создания полной резервной копии машины на момент последнего состояния.

Veeam Backup & Replication может копировать блоки данных из одного или нескольких файлов резервных копий в цепочке резервных копий в исходном хранилище резервных копий.

Если цепочка резервных копий создается методом обратного инкрементного резервного копирования, Veeam Backup & Replication копирует блоки данных последней полной резервной копии.
Если цепочка резервных копий создается методом инкрементного резервного копирования с прямой или навсегда переадресацией, Veeam Backup & Replication копирует блоки данных из первой полной резервной копии и набора инкрементных резервных копий.

Чтобы минимизировать объем трафика, проходящего по сети, Veeam Backup & Replication использует ускоритель WAN, технологии сжатия данных и дедупликации.

Veeam Backup & Replication передает скопированные данные в целевой репозиторий резервных копий и записывает все скопированные блоки данных в файл полной резервной копии.

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

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

Чтобы сохранить желаемое количество точек восстановления, Veeam Backup & Replication использует политику хранения. Дополнительные сведения см. в разделе Политика краткосрочного хранения.

Если вы хотите хранить некоторые точки восстановления в течение более длительного времени (недели, месяцы или годы) и включить политику долгосрочного хранения (политику хранения GFS), Veeam Backup & Replication создает прямую цепочку инкрементного резервного копирования. Дополнительные сведения о политике хранения GFS см. в разделе Политика долгосрочного хранения (GFS).

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

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