 Восстановление файлов и папок из резервной копии позволяет вернуть скопированные ранее данные в исходное или новое место. Handy Backup позволяет автоматически восстановить файлы и другую информацию, а также выполнять восстановление данных вручную. Восстановление файлов программа выполняет с помощью специальной задачи восстановления, или же при запуске режима восстановления для задачи резервного копирования через контекстное меню. В последнем случае вам достаточно проделать следующие операции:
Восстановление данных с помощью специализированной задачиДля создания задачи автоматического восстановления (включая такие операции, как, например, восстановление файлов SQL для зеркалирования базы данных) воспользуйтесь, пожалуйста, следующей краткой инструкцией.
 Внимание! Будьте осторожнее с операцией автоматического возвращения данных на прежнее место по расписанию — это может привести к потере важных файлов и папок! Пользуйтесь функцией расписания только тогда, когда программа выполняет восстановление файлов в другое место! * Источники данных MS Exchange и Hyper-V на данный момент не поддерживают выбор места восстановления и позволяют только выполнять восстановление данных на их исходное место. Восстановление данных образа дискаЕсли вы создали образ диска в программе Handy Backup, вы можете восстановить его прямо из программы с помощью задачи восстановления – если только это не текущий системный диск. В этом случае, а также для восстановления образа диска на «голое железо», применяется специальная утилита Disaster Recovery.  Рекомендуемое решение для восстановление данных из резервной копии Версия 8.1.1 от 16 декабря 2019. 106 MB Скачайте и попробуйте Handy Backup для бэкапа и восстановления данных (фотографий, музыки, почты и др.) — первые 30 дней использования бесплатно! Восстановление необходимых файлов вручнуюМожет случиться так, что вы потеряли все данные в результате поломки компьютера. В этом случае вам поможет функция полного восстановления данных. Однако нередки случаи, когда вы просто случайно удалили какой-то важный файл. Тогда вы можете выбрать данный файл из резервной копии данных и восстановить его отдельно, без полного восстановления!   Восстановление системы Windows и LinuxЕсли же вам не повезло «по-крупному», и в результате поломки компьютера вы потеряли все данные на диске, в том числе и операционную систему, то не отчаивайтесь. Программа Handy Backup вернет все на свои места. Из резервной копии жесткого диска она восстановит не только данные пользователя, но и все настройки, драйвера и другие критические данные. Восстановление баз данныхС помощью Handy Backup вы легко восстановите базы 1С, MySQL, MS SQL, Oracle, Postgre SQL и другие ODBC-совместимые, а также данные приложений Lotus Notes и MS Exchange Server. При этом вы можете восстанавливать данные, как в исходную базу, так и в новую. Более того Handy Backup позволяет восстанавливать базы на удаленный компьютер.   Восстановление данных в новую директориюЕсли вы хотите восстановить данные в другую папку или на другой компьютер в локальной сети, вам нужно всего лишь указать при восстановлении новый путь. Handy Backup позволяет также восстанавливать данные, вручную перенесённые в новую директорию. Восстановление удалённых файлов по сетиДля сетевых хранилищ, таких, как облака, серверы FTP, NAS и общие папки пользователя, Handy Backup позволяет выполнить удалённое восстановление файлов по сети. Сетевые решения Handy Backup обеспечивают также централизованное восстановление локальных файлов.  Handy Backup – отличная программа для восстановления файлов и папок! Попробуйте прямо сейчас, Читайте также: |
BackUp. Автоматический бэкап. Восстановление и создание бэкапа из Панели Управления. Backup по требованию.
В разделе BackUp Вы можете произвести восстановление данных за доступную дату или же создать архив из текущих данных или данных из бэкапа.
Восстановление файлов
Для того чтобы восстановить файлы из бэкапа, необходимо открыть вкладку «Файловый архив» (открывается по умолчанию) и выбрать доступную для восстановления дату из выпадающего списка.
Далее выбрать папки и/или файлы и нажать на иконку восстановления 
.
Выбранные Вами данные будут перемещены на Ваш аккаунт, на все файлы выставятся права 700.
Время выполнения данной операции варьируется в зависимости от размера данных, по окончанию восстановления на административный email придет подтверждение.
При нажатии на нее выбранные Вами данные будут заархивированы и выложены в корне Вашего аккаунта. Время выполнения данной операции также варьируется в зависимости от размера данных, по окончанию архивации на административный email придет подтверждение.
Восстановление базы данных
Восстановление базы данных делается аналогично. Необходимо открыть вкладку «Базы данных«, выбрать нужную дату, далее выбрать базу данных и нажать на иконку восстановления или выкладывания архива резервной копии базы данных в корень аккаунта.
Архивирование текущих данных
Если вместо даты выбрать «Текущее состояние«, то рядом с файлами, папками или базой данных будет только одна иконка
История заданий
На вкладке «История заданий» Вы можете отследить процесс выполнения восстановления из резервных копий.
Backup по требованию
С помощью данной функции Вы можете создать резервную копию всего Вашего аккаунта (файлы и БД). Данная копия хранится без ограничения по времени и одна копия всегда бесплатно.
Для того чтобы создать копию, достаточно написать для неё любой комментарий, например, «Перед обновлением движка на всех сайтах», после чего нажать на кнопку «Создать вечный backup
Время создания копии зависит от общего размера и количества файлов и баз данных. После создания первой копии каждая дополнительная будет стоить 2 рубля в сутки.
Возможности восстановления физических машин из бэкапов с помощью Veeam Endpoint Backup FREE / Veeam Software corporate blog / Habr
«Уж сколько раз твердили миру», что резервное копирование как самоцель не имеет практического смысла – а имеет оно таковой, конечно же, если из резервной копии возможно быстро, корректно и легко восстановиться. Поэтому темой моего сегодняшнего поста, в продолжение предыдущего, станет восстановление физической машины из резервной копии, созданной с помощью Veeam Endpoint Backup FREE.Как вы, наверное, уже предположили, опции восстановления тесно связаны с настройками резервного копирования: само собой разумеется, восстановить машину целиком не получится, если были забэкаплены, скажем, только пользовательские папки.
Рассмотрим же эти опции более подробно, для чего добро пожаловать под кат.
Эту возможность можно использовать вне зависимости от того, какой режим бэкапа был применен. Отрадно, что ради восстановления пары-тройки файлов вам не придется поднимать из бэкапа машину целиком. (Что-то это мне напоминает… как, думаю, и всем пользователям Veeam Backup & Replication, котрым с его помощью доводилось восстанавливать отдельно взятые файлы.)
Итак, как можно запустить восстановление файлов:
- Идём в меню Start, выбираем Veeam > Tools > File Level Restore и запускаем его.
- В системном трее находим иконку нашего приложения, кликаем по ней правой кнопкой и выбираем команду Restore – Individual files.
Оба этих способа перекинут нас на шаг мастера, посвященный выбору точки восстановления.
Примечание: При необходимости можно перейти на предыдущий шаг Backup Location
Можно пойти иным путем: открыть панель управления Veeam Endpoint Backup Control Panel и выбрать нужный бэкап на диаграмме, где все они представлены графически в виде прямоугольников. Изучив информацию о выбранном бэкапе и убедившись, что это именно с него мы хотим восстанавливаться, нажмём на кнопку Restore files.
Что произойдет потом?
После того, как вы нажали Restore files (или прошли по шагам мастера и нажали Open), файл резервной копии будет смонтирован на файловую систему вашей в данный момент работающей машины, в папку C:\VeeamFLR, и вы сможете просмотреть содержимое бэкапа с помощью браузера Veeam Backup Browser (или браузера Windows).
Браузер Veeam Backup Browser поддерживает следующие опции при восстановлении:
- Overwrite — файл будет восстановлен в исходное местоположение; если таковой файл там уже имеется, он будет перезаписан файлом из бэкапа.
- Keep — файл будет восстановлен в исходное местоположение с префиксом Restored –, имеющийся в исходном месте файл не будет перезаписан.
- Copy To — файл можно скопировать в другое местоположение, дополнительно можно указать, нужно ли сохранить при этом настройки прав (галка Preserve permissions and ownership).
Полезно: Можно выбрать для восстановления сразу несколько файлов\папок, нажав CTRL+SHIFT.
Сразу обращаю ваше внимание на то, что такое восстановление будет возможно только если при бэкапе вы выбрали опцию Entire PC (бэкап всей машины) или Volume Level Backup (бэкап тома).
Очевидно, что результатом восстановления будет весь том.
Для запуска процесса есть аналогичные способы: выбрать Veeam > Volume Restore в меню Start, либо кликнуть правой кнопкой по иконке в трее и выбрать команду
Аналогично файлу, том можно восстановить в исходное либо в новое местоположение. В первом случае исходный том будет перезаписан. Во втором случае можно разместить том либо на свободном месте диска, либо на месте уже имеющихся томов, заместив их (т.е. данные будут перезаписаны взятыми из бэкапа).
Обращаю ваше вниманин на ряд ограничений для восстановления тома, которые будут иметь место при восстановлении без использования Veeam Recovery Media:
- Системный том нельзя восстановить в исходное местоположение.
- Нельзя восстановить том на другой, содержащий файл подкачки.
- Нельзя восстановить том на другой, содержащий файл резервной копии, из которой происходит восстановление.
Указанные ограничения можно обойти, использовав восстановление с ранее созданного загрузочного носителя Veeam Recovery Media (о котором было рассказано здесь) и запустив мастер восстановления «на голое железо» Veeam Bare Metal Recovery для восстановления тома (подробнее об этом чуть позже). Шаги мастера достаточно просты; в зависимости от местонахождения бэкапа вы выбираете удаленную СХД или сервер Veeam Backup & Replication и получаете возможность маппирования диска туда. Выбираете тома, которые хотите восстановить — по умолчанию, они будут восстановлены в исходное местоположение (чтобы задать другое, кликните на Customize disk mapping, затем укажите, куда должны быть восстановлены тома).
Важно! Если вы указываете местоположение вручную, будьте внимательны, чтобы не стереть имеющиеся тома. (Собственно, данные затираются непосредственно во время восстановления, так что если вы передумаете насчет маппирования на этом этапе, то достаточно нажать Cancel или закрыть окно мастера, чтобы невзначай ничего не произошло.)
Для ручного маппинга диска есть следующие опции:
- Apply Backup Layout — разметить как в бэкапе; диск будет размечен так же, как был на момент создания бэкапа.
- Apply Disk Layout — разметить как диск; будут использованы текущие настройки разметки другого диска (который вы укажете).
- Erase — стереть; текущие настройки разметки диска будут удалены.
Далее можно переходить к восстановлению.
Как было сказано выше, с помощью ранее созданного загрузочного носителя вы можете обойти некоторые ограничения при восстановлении тома. Но, разумеется, его предназначение не только в этом, а в том, чтобы обеспечить восстановление вашей машины из хранящейся на нем резервной копии.
Напомню, что для создания такого носителя используется специально предназначенный мастер Create Recovery Media. В зависимости от того, какой тип носителя вы выберете, вам может понадобиться поменять приоритет загрузки ОС, указав в соответствующих настройках BIOS, что загрузку следует выполнять с данного носителя. Если все сделано правильно, то после перезагрузки машины (до запуска ОС) вам будет предложено нажать любую клавишу для загрузки с Veeam Recovery Media.
Теперь посмотрим, какие опции предлагает нам Veeam Endpoint Recovery в появившемся окне.
Инструментарий
Начнем в обратном порядке, то бишь с опции Tools – а вдруг все-таки можно починиться, не прибегая к радикальному методу «Восстановление на голое железо»?
Вот что у нас тут есть:
- Command Prompt — ну, это и так понятно.
- Reset Password — полезная вещь, позволяет вместо забытого пароля локального админа установить пустой. Если админская учетка была деактивирована, ничего страшного – утилитка может ее включить обратно, чтобы дать вам возможность залогиниться. Само собой, пароль надо будет поменять, а после того, как вы проделаете необходимые манипуляции, вернуть учетку в прежний вид (то есть деактивировать ее).
Важно! - Load driver — для доступа к сетевой СХД или выделенной СХД, хранящей резервные копии, нужен соответствующий драйвер для ОС — ровно то же требуется и для работы с Recovery Media. Если при создании носителя была выбрана опция Include hardware drivers from this computer, то драйверы будут загружены автоматически. Также можно использовать данную утилиту для загрузки дополнительных драйверов в случае необходимости.
- Memory diagnostics (утилита Microsoft) — проверка памяти вашей машины и диагностика потенциальных проблем. Подробнее см. http://technet.microsoft.com/en-us/magazine/2008.09.utilityspotlight.aspx
- Startup repair (утилита Microsoft) — может помочь с починкой неполадок при старте Microsoft Windows (например, отсутствующие или поврежденные системные файлы или загрузочный сектор). Подробнее см. http://windows.microsoft.com/en-us/windows7/products/features/startup-repair
- Export Logs — экспорт журналов работы приложения на внешнюю СХД; очень рекомендуется иметь файлы журналов на случай обращения в службу техподдержки Veeam.
Среда восстановления Windows
Данная среда является частью установочного пакета Windows. Если у вас имеется системный имидж Microsoft, то его можно использовать для восстановления, воспользовавшись Veeam Recovery Media для его запуска. (А можно запустить и обычным образом; подробнее см. windows.microsoft.com/en-us/windows/restore-computer-from-system-image-backup#1TC=windows-7 )
Восстановление «на голое железо»
После запуска с нашего носителя нажимаем на значок Bare Metal Recovery и проходим по шагам мастера:
Вернемся немножко назад (к моменту создания резервной копии) и поговорим и о том, что собой представляют бэкап по требованию и бэкап по расписанию, а также выясним, кто такой отдельно стоящий полный бэкап (standalone full backup).
Бэкап по расписанию
Выполняется автоматически согласно расписанию задания резервного копирования, чьи настройки вы указываете в мастере Сonfigure backup wizard: они могут включать в себя расписание периодического запуска и\или триггеры старта.
При первом проходе задания будет создан полный бэкап, а при последующих – инкременты; созданные точки восстановления будут храниться и удаляться в соответствии с заданным сроком хранения.
Создание резервных копий будет функционировать до тех пор, пока будет в рабочем состоянии выбранное место их хранения. Что касается повторных запусков (в случае возможной ошибки при выполнении задания), то логика такова: после любого сбоя задание будет пытаться повторно стартвать каждые 10 минут на протяжении ближайших 23 часов, после чего прекратит это делать, выдав сообщение об ошибке.
В хранилище резервных копий будут находиться вот такие файлы:
- .VBM – файл метаданных, который хранит всю информацию о цепочке бэкапов
- .VBK – файл полной резервной копии
- .VIB – файл инкремента
Бэкап по требованию
Бэкап по требованию удобен, например, когда вам нужно установить новый софт или проапгрейдить систему. Запускается он из интерфейса Veeam Endpoint Backup нажатием кнопки Backup Now.
В результате в цепочке резервных копий создается новый инкрементальный бэкап (исключение – первый запуск, когда создается полный бэкап как начало цепочки).
Заметим, что, в отличие от бэкапа по расписанию, такой бэкап не будет рестартовать в случае ошибки.
Отдельный полный бэкап
Создает полную резервную копию, но она не будет частью цепочки и, соответственно, не подпадет под политику хранения.
Чтобы запустить создание такого бэкапа, нужно кликнуть правой кнопкой мыши по иконке в трее и выбрать команду Backup > Standalone full backup. Такой процесс тоже не будет рестартовать в случае ошибки. После завершения файл резервной копии сохраняется туда же, куда и цепочка, но в отдельную подпапку. В ней вы найдете файлы .VBM и .VBK — при необходимости из них можно будет восстановиться (не забудьте перенести и эту папку с отдельным бэкапом, если будете перекладывать папки с резервными копиями).
А теперь посмотрим, что нам дает интеграция Veeam Endpoint Backup FREE с Veeam Backup & Replication в плане дополнительных возможностей восстановления.
Восстановление файлов
Из консоли Veeam Backup & Replication очень удобно восстанавливать файлы и папки из нашего бэкапа, задействуя механизм FLR (file-level restore, то есть восстановление на уровне файлов), подробно описанный в документации. Есть только одно ограничение — нельзя восстанавливать в исходное местоположение, но можно использовать команду Copy To в Backup Browser и скопировать нужные файлы в новое место.
Восстановление объектов приложений с помощью Veeam Explorers
Если вы бэкапите сервер Active Directory, SharePoint, Exchange или SQL с помощью Veeam Endpoint Backup FREE, то из такого бэкапа можно восстанавливать объекты соответствующего приложения: просто запустите восстановление на уровне файлов из консоли Veeam Backup & Replication, а затем из браузера Backup Browser – соответствующий инструмент Veeam Explorer.
Подробнее о том, как это делается, можно узнать, например, здесь.
Экспорт дисков
Любой диск из бэкапа, созданного Veeam Endpoint Backup, можно экспортировать в файл VMDK, VHD или VHDX с помощью консоли Veeam Backup & Replication, выбрав в меню Home команду Restore > Endpoint > Export disk contents as virtual disks.
Следует понимать, что это не будет восстановлением P2V, так что при попытке загрузиться с такого диска в виртуальной среде возможны ошибки из-за наличия физических драйверов. Однако есть и более практичные сценарии – например, аттач диска к ВМ. Но и здесь нужно помнить о нескольких моментах:
- Диск VMDK можно восстановить на СХД (datastore) в «тонком» формате (thin provisioned), тогда как восстановление на сервер сохранит диск в виде «толстого» (thick provisioned).
- Диски VHD/VHDX всегда восстанавливаются как динамические.
Напоминаю, что недавно вышла версия 1.1 решения Veeam Endpoint Backup FREE, которая поддерживает Windows 10. Решение доступно по ссылке http://www.veeam.com/ru/endpoint-backup-free-download.html.
Описание продукта можно найти на страничке http://www.veeam.com/ru/endpoint-backup-free.html.
Статья на Хабре с обзором решения Veeam Endpoint Backup FREE: http://habrahabr.ru/company/veeam/blog/255729/
Статья на Хабре о резервном копировании физических машин с помощью Veeam Endpoint Backup FREE: http://habrahabr.ru/company/veeam/blog/261481/
Бэкап Linux и восстановление его на другом железе / Habr
Я работаю в организации с маленьким штатом, деятельность тесно связана с IT и у нас возникают задачи по системному администрированию. Мне это интересно и частенько я беру на себя решение некоторых.На прошлой неделе мы настраивали FreePBX под debian 7.8, нанимали фрилансера. В процессе настройки оказалось, что сервер (да, я так называю обычный PC) не хочет грузится с HDD при подключенных USB 3G модемах, которые мы используем для звонков на мобильные, колупание BIOSа не помогло. Непорядок. Решил, что нужно перенести его на другую железяку. Так появилось сразу две связанные задачи:
- сделать бэкап сервера;
- восстановить бэкап на другом железе.
Гугление не дало внятных ответов, как это сделать, пришлось собирать информацию кусками и пробовать. Всякие acronis’ы отбросил сразу, ибо не интересно.
Опыт общения с linux-системами у меня небольшой: настройка VPN сервера на open-vpn, ftp-сервера и еще пара мелочей. Сам себя я характеризую как человека умеющего читать маны и править конфиги 🙂
Ниже я описываю свой частный случай и почему я поступил именно так. Надеюсь, новичкам будет полезно, а бородатые админы улыбнутся вспомнив молодость.
Начинаем копать теорию:
По созданию бэкапов уйма статей, я для себя отметил два способа: tar — упаковывает и сжимает все файлы, при этом не сохраняется MBR, мой бэкап будет весить около 1.5 Gb; dd — делает полную копию раздела, включая MBR и всю область, где нет файлов, архив будет равен размеру раздела, в моем случае ~490 Gb.
Второй способ требует наличия внешнего жесткого диска объемом не меньше раздела, который архивируем. Да и что с ним потом делать, непонятно, хранить на полочке? Остановился на tar, чуть сложнее в реализации, нужно будет создать MBR, но время создания/восстановления архива существенно меньше, хранить бэкап проще, полтора гига можно закинуть в облако и скачать, когда будет нужно. Записывать его можно на ту же live-флэшку, с которой буду грузиться.
Итак, план действия:
- создание бэкапа;
- форматирование, разметка диска, создание файловой системы;
- восстановление бэкапа;
- создание MBR;
- тестирование и устранение неполадок.
1. Создание бэкапа
Грузимся с live-флэшки, у меня это debian-live-7.8.0-amd64-standard.
Переключаемся на root:
sudo su
Монтируем раздел, который будем архивировать, у меня это sda1, чтобы случайно не наломать дров, монтируем только для чтения. Посмотреть все свои разделы можно при помощи команд ls /dev | grep sd или df -l
mount -o ro /dev/sda1 /mnt
Наша флэшка уже примонтирована, но в режиме только чтения, нужно перемонтировать для чтения-записи, чтобы писать туда бэкап.
mount -o remount,rw /dev/sdb1 /lib/live/mount/medium
Все готово для создания архива
tar -cvzpf /lib/live/mount/medium/backupYYYYMMDD.tgz --exclude=/mnt/var/spool/asterisk/monitor --exclude=/mnt/var/spool/asterisk/backup /mnt/
Здесь у нас параметры: c — создать архив, v — выводить информацию о процессе, z — использовать сжатие gzip, p — сохраняем данные о владельцах и правах доступа, f — пишем архив в файл, путь к файлу, —exclude — исключаем из архива каталог (я исключил каталоги с записями разговоров и каталог с бэкапами FreePBX), /mnt/ — каталог, который архивируем.
Ждем… у меня вся подготовка и создание архива заняли 10 минут. Будь флэшка быстрее, уложился бы в 7-8 минут.
Отмонтируем диск:
umount /mnt
… и перезагружаемся.
reboot
Складываем архив в надежное место за пределами офиса.
Восстановление бэкапа на другом железе
2. Размечаем диск, создаем файловую систему
Грузимся с live-флэшки, у меня все та же debian-live-7.8.0.
Переключаемся на root:
sudo su
Размечаем диск. Мне понравилась утилита с псевдографическим интерфейсом cfdisk. Там все просто и понятно.
cfdisk
Удаляем все имеющиеся разделы. Я создал два новых раздела, один на 490 Gb под / (sda1) и 10 Gb под swap (sda2) в конце диска, т.к. он практически не будет задействован. Проверим типы разделов. Который под систему должен иметь тип 83 Linux, второй — 82 Linux swap / Solaris. Помечаем системный раздел загрузочным (bootable), сохраняем изменения и выходим.
Cоздаем файловую систему на первом разделе.
mkfs.ext4 /dev/sda1
3. Распаковываем архив.
Монтируем отформатированный раздел
mount /dev/sda1 /mnt
Распаковываем архив прямо с флэшки
tar --same-owner -xvpf /lib/live/mount/medium/backupYYYYMMDD.tgz -C /mnt/
Параметр —same-owner — сохраняет владельцев у распаковываемых файлов, x — извлекаем из архива, v — выводить информацию о процессе, p — сохраняем права доступа, f — указываем файл, который распаковываем, C — распаковываем в категорию.
4. Создаем MBR на новом диске.
Чтобы корректно создать загрузочную запись, монтируем рабочие каталоги к нашему будущему root-каталогу, у меня это /mnt. Каталоги /dev и /proc сейчас используются live-системой, используем параметр bind, чтобы они были доступны сразу в двух местах:
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
Переключаемся на новую систему используя chroot:
chroot /mnt
Делаем swap-раздел для новой системы:
mkswap /dev/sda2
Подключаем его же:
swapon /dev/sda2
Чтобы grub работал, нужно указать ему правильные UUID разделов в fstab, сейчас там прописаны разделы предыдущей системы:
nano /etc/fstab
Открываем второй терминал (Alt+F2) под root:
sudo su
Вызываем:
blkid
И видим текущие UUID разделов.
Вручную переписываем их в fstab переключаясь между Alt+F1 и Alt+F2. Да, муторно, но попытки копировать занимали у меня больше времени, чем переписывание. Сохраняем fstab.
Устанавливаем grub2. У меня один физический диск, поэтому ставим его на sda:
grub-install /dev/sda
На чистый диск должно встать без ошибок. Обновляем информацию из fstab:
update-grub
Возвращаемся в Live-систему:
exit
Размонтируем все каталоги:
umount /mnt/dev
umount /mnt/proc
umount /mnt
Если вылазят процессы, которые используют эти каталоги, убиваем их используя fuser.
Все, поехали. Грузимся с жесткого диска:
reboot
Здесь статья должна была закончиться, но у меня возникли проблемы с подключением к интернету. Сервер видит сеть, видит компьютеры в ней, но в интернет не ходит… а это как бы важно для телефонии.
5. Тестирование и устранение неполадок.
ifconfig -a
Показывет интерфейсы eth2 и lo, гугление сказало, что gateway можно прописать только подключению eth0, остальные рассчитаны только на работу внутри сети.
Похоже, отсутствие eth0 вызвано способом переноса системы. Находим файл, который отвечает за нумерацию интерфейсов, смотрим туда:
nano /etc/udev/rules.d/70-persistent-net.rules
Действительно, там два активных интерфейса, определенных MAC’ами. Комментируем первый, второму прописываем eth0.
Перезапуск /etс/init.d/networking не помог, поэтому перезагружаемся:
reboot
Подключаем донглы, проверяем, все работает.
Спасибо за внимание.
Резервное копирование и восстановление информационной базы 1С
Редактор статьи:Юрий Сухарев
Консультант 1С Получить консультациюАктуальность статьи проверена:
Содержание статьи
Традиционно, пользователи 1С делятся на две категории: тех, кто делает резервные копии*, и тех, кто начнет их делать. Чтобы не учиться на собственных ошибках, давайте начнем делать резервное копирование прямо сейчас.
*Если вы уже делаете резервные копии, эта статья все равно окажется вам полезной, поскольку многое из того, что можно найти и прочитать на тему резервного копирования в Интернете, ошибочно и весьма опасно для сохранности ваших данных. Если вы ИТ-специалист — переходите к чтению раздела «Резервное копирование информационной базы 1С средствами SQL».
Стоит ли вообще тратить на это время?
Разве в наше время информационная база 1С может как-то сломаться? Ломается все: чайники и самолеты, ножка от табуретки и электронный микроскоп. Трудно сломать только что-то очень простое, например, чугунный шар. Но информационная база 1С – сложный объект и функционирует в сложной технологической среде. Рано или поздно что-то произойдет, сначала совсем незначительное, а далее «открутившийся винтик» вызовет каскадную реакцию отказов ПО и оборудования, которая в итоге закончится крупными неприятностями и потерей информационной базы.
Файловый вариант информационной базы
Начнем с самого простого примера. В небольшой организации работает конфигурация 1С с файловой информационной базой, которую обслуживает приходящий системный администратор, который вероятно все настроил. Но! Отсутствие сообщений «Не настроено резервное копирование» вовсе не означает, что теперь оно настроено. Это может означать также, что данное сообщение просто не показывается. Поэтому, взяв на себя ответственность за надежность и сохранность результатов своего труда, для начала убедимся, что информационная база именно файловая. Как это сделать – наглядно показано на иллюстрации ниже. Если вместо File= написано Srv=, это SQL-база и для настройки резервного копирования обратитесь к вашему администратору баз данных. Если база файловая, можно воспользоваться ручным или автоматическим копированием.
Ручной способ – создайте резервную копию, как показано на иллюстрации. Перед выгрузкой все пользователи должны завершить работу с информационной базой. Выгрузка создает один файл резервной копии с расширением DT, в котором будет почти все (об этом – далее), что есть в данный момент в информационной базе, и не будет того, что введется после. Дайте осмысленное имя файлу (например, «Резервная копия Управления торговлей на 2017-10-31») и выберите для его сохранения специальную папку (например, папка «Резервные копии» в папке «Мои документы»). Используя этот файл, вы можете впоследствии восстановить информационную базу до состояния, которое предшествовало выгрузке. Для восстановления надо использовать операцию «Загрузить информационную базу».
Автоматический способ. Расположение ссылки «настройка резервного копирования» может отличаться в разных конфигурациях и редакциях 1С.
Типичная настройка резервного копирования показана на иллюстрации. Такая настройка предполагает, что пользователь с правами администратора оставляет открытой программу в конце рабочего дня (иначе резервное копирование не выполнится), а все остальные пользователи программу закрывают. Альтернативный вариант – выполнять резервное копирование при завершении работы (будет запрошено подтверждение необходимости резервного копирования).
При наступлении времени резервного копирования в первом случае или при завершении работы последнего пользователя с административными правами во втором, системой будет установлена блокировка информационной базы с завершением работы всех пользователей. Это сложный процесс, который может не сработать, что повлечет ошибку резервного копирования (на иллюстрации ниже). Об этом вы можете прочитать специальную статью на нашем сайте.
Поэтому ограничиться единовременной настройкой автоматического резервного копирования не получится, за созданием резервных копий все равно придется регулярно следить.
А сейчас некоторые вопросы, которые не рассмотрены в популярных статьях на тему резервного копирования.
- Все ли попадет в резервную копию?
Нет. Вы можете потерять или испортить историю работы (кто и когда входил и выходил ли из программы), историю изменений объектов (кто и когда менял данные). Эта информация хранится вне информационной базы, ее хранение и правильное восстановление требует специальных действий. Вы можете потерять или испортить прикрепленные к объектам 1С-файлы (сканы документов, фотографии и т.д.). В зависимости от настроек эти данные могут храниться внутри или вне информационной базы, в последнем случае их сохранение и правильное восстановление также требует специальных действий. В резервной копии также не сохранятся настройки управляемых форм, сделанные пользователями.
- Можно ли делать резервную копию в процессе работы?
Стандартный механизм сначала пытается завершить работу пользователей. Однако это не всегда удается, поэтому операция резервного копирования может быть выполнена и при работающих пользователях. В этом случае предполагается, что эти пользователи не производят модификацию данных. Но если это не так, гарантия корректности резервной копии отсутствует. То есть ответ на этот вопрос – нет, нельзя.
- Как часто надо делать резервные копии?
Зависит от интенсивности ввода данных и критичности их потери. Для небольшого предприятия с одним-двумя пользователями 1С рекомендуем делать это минимум ежедневно. При 20 пользователях рекомендуем создавать одну ночную резервную копию и несколько резервных копий в ходе рабочего дня. Как вы помните, это повлечет временный технологический перерыв в работе пользователей.
- У нас были случаи потери данных, и мы бы хотели перейти на SQL-вариант информационной базы, но это очень дорого…
Возможно, вам подойдет бесплатный вариант MS SQL. Обратитесь к нам за консультацией.
SQL-вариант информационной базы
Данная часть статьи будет интересна специалистам и тем, кто еще только собирается им стать.
Сразу уточним, что избежать задачи резервного копирования нельзя. Ни репликация, ни абсолютно надежная аппаратура не защитит от случайного или злонамеренного повреждения данных на уровне приложения (ошибочное закрытие месяца, неверная работа плохо отлаженной обработки массового изменения данных и т.п.). Данные в этом случае надежно хранятся, но они неверны, а резервные копии отсутствуют, поэтому откат назад невозможен. На практике приходится восстанавливать информационную базу 1С из-за повреждения данных гораздо чаще, чем можно себе представить.
С точки зрения пользователя, живущего в понятийном пространстве файловых баз, у нас есть точки восстановления в виде бэкапов информационной базы, разделенные по времени частотой резервного копирования: если мы делаем копии раз в сутки, то в случае восстановления потеряем изменения, сделанные в базе максимум за сутки или меньше. Но в среде SQL server и способ хранения/изменения данных, и технологии резервного копирования предусматривают «бесконечное» количество точек, сливающихся в одну непрерывную прямую восстановления. Это означает возможность отката на точку, непосредственно предшествующую моменту сбоя или при необходимости на любой момент времени назад. На языке пользователя, это равнозначно созданию резервных копий раз в секунду и менее того.
Дело в том, что резервное копирование в среде SQL – это не последовательность нажатий кнопок, а комплекс регулярных мероприятий над сложно устроенными объектами. И этот комплекс создается в весьма сложной среде.
Чтобы понять «как все работает», мы еще раз обозначим цель наших действий – полное резервирование данных вплоть до секунды, предшествующей сбою (или моменту внесения нежелательных изменений) и возможность отката назад на произвольный момент времени с точностью до секунды.
Неужели так важно восстановление данных с точностью до секунды?
Это важно для фронт-офисных систем или в случае, когда предприятие достигает определенного масштаба. Поясним это утверждение, задав несколько наводящих вопросов. Легко ли организовать повторный ввод данных в филиальной сети, разбросанной по 10 регионам с разными часовыми поясами и имеющей несколько тысяч сотрудников? Как проконтролировать его правильность? Допустим, можно взять накладную и повторно ввести с нее данные. А как выполнить повторный ввод данных, которые поступали в систему при взаимодействии с аппаратурой (фискальные регистраторы, банковские терминалы) или со сторонними информационными системами (онлайн-кредит, процессинг скидочных карт единой партнерской сети), при участии большого количества людей (системы учета рабочего времени по отпечатку пальца)? Где взять источник информации для повторного ввода, если нет никаких документов, а все действия фиксируются безбумажным способом (учет питания в корпоративной столовой по карте сотрудника)?
Как получить копию базы со всеми данными, которые находились в системе «за секунду до взрыва»
Журнал транзакций (Transaction log, TLog)
Необходимо записывать в журнале все действия, которые мы собираемся произвести с базой данных, плюс их точное время (до микросекунд), и только затем выполнять их. Имея такой журнал (хранящийся на очень надежном и быстром носителе, обязательно отдельно от самой базы), мы могли бы повторить все операции с момента начала существования базы данных до произвольного момента восстановления с точностью до микросекунды. Но у ведения журнала транзакций есть два недостатка: через некоторое время с ростом базы TLog будет занимать очень много места (т.к. он непрерывно растет), а восстановление от «нулевого» момента времени будет выполняться очень долго.
Резервные копии журнала транзакций (Transaction log backup, TLog backup)
Образно выражаясь, мы будем регулярно забирать из журнала все листы и относить их в соседнюю комнату (назовем изъятые листы TLog backup), а в сам журнал класть пачку новых чистых листов, чтобы было, куда записывать новые действия с базой. Технически это выполняется так: снимается копия с файла TLog и записывается на архивный диск, после чего все записи в TLog «стираются» (помечаются как свободные, размер файла журнала не меняется), на «стертом» месте пишется информация о новых транзакциях. Очень важно понимать – каждая вырванная пачка листов, хоть и называется в устоявшейся терминологии Transaction Log backup, является единственным носителем информации о действиях с базой за этот период, а в самом журнале этой информации теперь нет. Поэтому потеря даже одного «вырванного листа» пока абсолютно недопустима, а термин TLog backup коварно маскирует сущность и назначение данной информации. Запомните – это не бэкап! Мы разбили журнал на множество файлов и информация в каждом из них нигде не продублирована. Но термин Transaction Log Backup общепринят, поэтому и дальше мы будем использовать именно его.
Теперь TLog бесконечно не растет, но возникает регламентная задача – резервное копирование TLog по расписанию.
Полные резервные копии базы данных (Full database backup, Full backup)
Если периодически делать копии всей базы данных, то для восстановления можно будет взять наиболее подходящую по времени копию и повторить не все операции с нулевого момента времени, а только операции с момента создания этой копии до момента восстановления (как говорят, «взять Full backup и накатить на него TLog»). Это значительно сокращает время восстановления, особенно если база существует уже лет 5. Помимо этого, теперь у нас появилась возможность удалять старые Full backup и TLog backup. На самом деле, откат назад с точностью до секунды зачастую может быть необходим только на коротком временном периоде (например, два месяца назад от текущего момента для расследования каких-то инцидентов или для восстановления базы за секунду до трагического внесения нежелательных изменений). В течение этого периода мы и будем хранить непрерывную цепочку TLog backup. За пределами этого периода можно хранить лишь точки восстановления в виде Full backup (и то не все, а например, только точки на первые числа месяца). TLog backup за пределами периода можно теперь удалять вообще (очевидно, что их выборочное удаление и выборочное хранение за пределами периода совершенно бессмысленно из-за нарушения непрерывности цепочки TLog). Так или иначе, возникает регламентная задача интеллектуального удаления.
Здесь возникает следующая проблема. Представим базу данных с большим количеством пользователей и высокой интенсивностью изменений. Условно – 33% времени тратится на запись и 67% на чтение, простоев нет. Когда мы будем восстанавливать базу, мы можем писать почти 100% времени, т.е. в три раза быстрее. Значит, мы можем три часа работы с базой восстановить по журналу за час. И этот час – максимальное время простоя на восстановление, на которое согласен бизнес. Допустим, Full backup делается раз в сутки. Если сбой произошел через 21 час от этого момента – нам придется потратить на восстановление по журналу 7 часов, что уже абсолютно неприемлемо. Значит, Full backup надо делать 1 раз в 3 часа? Увы, не всегда это возможно: базы бывают настолько большими (сотни гигабайт и даже терабайты), что за такое время Full backup создать просто невозможно. К тому же частое создание Full backup в рабочее время дает дополнительную нагрузку и замедляет работу пользователей, да и хранить такое количество данных весьма накладно. Но в принципе достаточно и того, что отсутствие возможности создать Full backup за приемлемое время полностью ставит крест на нашей технологии резервного копирования.
Разностные резервные копии (Differential backup, Diff backup)
Мы можем придумать специальную структуру хранения данных с непрерывно возрастающей нумерацией транзакций и другими хитростями, позволяющими легко понять разницу между двумя состояниями базы данных (от сих и до сих – уже было, все что далее – уже новое). Это позволит в резервной копии базы данных сохранить не все данные, а лишь отличия текущего Full backup от предыдущего Full backup. Процедура получения очередной полной копии будет простая: надо взять Full backup и накатить на него Diff backup. Вместо сохранения одного терабайта данных в Full backup мы сохранили в Diff backup всего десяток мегабайт и получили возможность делать это довольно часто – например, раз в полчаса. Но надо следить, чтобы была в наличии полная резервная копия, иначе разностная бесполезна.
В этом месте очень удачно можно сравнить дифференциальный бэкап и бэкап журнала транзакций, закрепив полученную информацию. Если не делать полную копию – размер дифференциальных бэкапов будет монотонно увеличиваться, т.к. будет накапливаться все больше и больше отличий от полной копии – и так до создания очередного полного бэкапа. Размеры очередных бэкапов журнала транзакций не будут иметь такой тенденции, их размер определяется количеством произведенных действий с базой за период. Обычно их размер колеблется вокруг некоего среднего значения, но в отдельные периоды (при выполнении операций массового изменения данных, при всплеске активности пользователей и т.д.) может очень сильно отличаться от среднего.
На иллюстрации ниже с некоторой долей условности изображена наша система резервного копирования. Первый ряд объектов отображает состояние базы данных, в которую периодически добавляются записи. Второй отображает одну полную резервную копию и три разностных. Третий ряд отображает содержимое резервных копий журнала транзакций. Каждый элемент пронумерован. Давайте установим несколько зависимостей между элементами.
- 5+7=3. Это означает, что имея Full backup 5 и Diff backup 7 можно восстановить базу в состояние 3. При этом отсутствие 6 никак не повлияет на возможность восстановления.
- 5+10+11=3. Того же результата (восстановить в состояние 3) можно достичь, если к Full backup 5 применить все изменения, зафиксированные в TLogBackup 10 и 11. Так придется делать, если у нас отсутствуют 6 и 7 из-за того, что расписанием было предусмотрено только создание 5 и 8 (или если 6 и 7 повреждены). Но если 7 есть, то способ 5+7 гораздо быстрее способа 5+10+11.
- Если отсутствует только 7, то базу в состояние 3 можно восстановить способом 5+6+11.
- Если расписание таково, что 11 не создавалось, содержимое 12 будет следующим: «Добавлены: Топорков, Уфимцев, Яшин».
- Журнал транзакций, на первый взгляд, на картинке не представлен, но как вы помните, TLog backup – это никакой не бэкап, а журнал транзакций за определенный период. Обратите внимание, что появление новых фамилий в журнале предшествует их появлению в базе данных.
- Если не создавать резервные копии журналов транзакций, содержимое TLog в момент 12 будет следующим: «Добавлены:», а далее список фамилий 4 (т.е. зафиксированы все действия). Если резервные копии созданы, как на картинке, то содержимое журнала транзакций в момент 4, как и в момент 8, будет следующим: «Никаких действий пока не производилось».
Резервное копирование заключительного фрагмента журнала транзакций
Если речь не идет о системах высокой доступности, то в случае сбоя нужна еще одна уже не регламентная, а ручная операция – создание самого последнего TLog backup. Если это невозможно, т.е. журнал поврежден вместе с базой или вместе с сервером – восстановление возможно только до момента последнего TLog backup, а не на последнюю секунду. Т.е. поставленная изначально цель не будет достигнута.
Из этого следует, что ключевым элементом всей системы резервного копирования является журнал транзакций. Он должен располагаться на отдельном носителе (не совпадающем с носителем для самой базы данных) с очень высокой надежностью, высокой скоростью доступа и высокой доступностью, но ни в коем случае не в разных папках одного логического диска, равно как и на разных логических дисках одного физического носителя. Кроме того, желательно, чтобы даже при падении сервера SQL, журнал оставался бы доступным или хотя бы мог оказаться доступным за минимальное время (методы достижения отказоустойчивости мы не рассматриваем, они составляют тему отдельной статьи внушительного объема).
Именно такая сложная система обеспечит нам достижение поставленных в начале целей и будет свободна от обнаруженных в ходе ее разработки проблем.
Full recovery model (работает только с регламентными заданиями и под контролем администраторов)
Мы описали полную модель восстановления базы данных – Full recovery model. Для особых случаев в MS SQL Server существует простая модель восстановления (Simple recovery model) и модель с неполным протоколированием (Bulk-logged). Full recovery model предусматривает регулярное выполнение задач обслуживания базы данных, а также контроль регулярности и результатов выполнения заданий со стороны администратора. Это предполагает существование сложного инструментария проектирования плана обслуживания (Maintenance Plan), который необходимо изучить.
Перейдем к практике
Возможно, первая трудность, с которой придется столкнуться – невозможно создать новый план обслуживания.
Надо разрешить этот функционал выполнением SQL-скрипта (New Query на панели инструментов, набрать скрипт, Execute на панели инструментов). При успешном выполнении скрипта вы увидите соответствующие сообщения в нижней части окна со скриптом.
Текст этого скрипта для копирования/вставки:
sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO
sp_configure 'Agent XPs', 1;
GO
RECONFIGURE
GO
Реальный план обслуживания
Покажем для начала реальный план обслуживания, обслуживающий непродуктивные базы данных в контуре разработки, а далее рассмотрим отдельные фрагменты плана, необходимые для его чтения и понимания. Четыре иллюстрации ниже показывают план обслуживания «Основной план», состоящий из четырех подпланов, работающих по своему расписанию.
1. Подплан «Ежедневный полный бэкап»
2. Подплан «Еженедельное обслуживание»
3. Подплан «Дифференциальный бэкап»
4. Подплан «Бэкап ЖТ»
В обозревателе объектов мы видим, что на SQL сервере настроено два плана обслуживания (Основной план, Тестовый план). Основной план состоит из четырех подпланов с разным расписанием (Shedule):
Ежедневный полный бэкап- Еженедельное обслуживание
- Дифференциальный бэкап
- Бэкап ЖТ
В области дизайна задач мы видим задачи. Процесс конструирования плана заключается в перетаскивании задач с палитры Toolbox, установки параметров задач и рисовании стрелок между задачами. Задачи могут иметь произвольное описание в области дизайна, соответствие между задачей на плане и задачей на палитре можно установить по иконкам. Например, задача «Ошибка целостности» – это задача «Notify operator task» на палитре (иконка «человек»).
Это блок-схема?
Первое, что можно подумать, глядя на сценарий выполнения задач плана обслуживания – что это блок-схема, стрелочки обозначают переходы от одной задачи к другой, и по ним можно пройтись указательным пальцем, проследив весь сценарий от начала и до конца. Однако это не так. Бывает, с первого взгляда даже сложно определить, с чего все начинается и какова последовательность выполнения задач. Сценарий в общем случае может начинаться в нескольких местах и заканчиваться также в нескольких местах, потому что SQL сервер стремится запустить абсолютно все задачи одновременно.
Параллелизм и ограничения
Единственное, что его останавливает – наличие ограничений. Задача не может быть запущена, пока не «сбылись» входящие в нее стрелки (ограничения, restrictions). Цвет стрелки обозначает тип завершения влияющей задачи. Входящая зеленая стрелка обозначает для зависимой задачи ограничение «запустить только в случае успешного выполнения влияющей задачи», черная – «запустить только после завершения влияющей задачи (Completion)», красная – «запустить только в случае ошибки во влияющей задаче (Failure)».
Тип линии (сплошная или пунктир) обозначает логический оператор AND или OR для вычисления итогового ограничения от нескольких входящих стрелок. Этот оператор меняется в диалоге Precedence Constraint Editor (двойной клик по любой из стрелок). Сплошные стрелки должны сбыться все, из пунктирных должна сбыться хотя бы одна – тогда зависимая задача сразу будет запущена. Цвет каждой входящей стрелки можно менять независимо (правый клик, Success/Failure/Completion). Тип линии можно изменить только для всех входящих стрелок сразу (двойной клик, диалог Precedence Constraint Editor). Сначала начинают одновременно выполняться все задачи, не имеющие ограничений. Как только завершается очередная задача, проверяются все зависимые от нее задачи и одновременно запускаются на выполнение те, у которых итоговое значение ограничений стало достаточным для принятия решения о запуске.
Информации в предыдущем абзаце достаточно для понимания общего механизма выполнения сервером SQL задач плана обслуживания. Теперь рассмотрим вопросы, имеющие прикладное значение.
Странное расписание
Странное время выполнения задач объясняется разницей 4 часа между часовым поясом серверов и часовым поясом разработчиков. Диапазон возможного времени работы разработчиков с 9:00 до 21:00, поэтому подплан «Бэкап ЖТ» выполняется каждый час с 10:00 до 21:00, фиксируя изменения каждый час (в 9:00 этих изменений еще нет). В переводе на часовой пояс серверов это с 14:00 дня до 01:00 часа ночи, что и указано в расписании.
Переход через полночь
При указании времени можно перескакивать через полночь, это корректно работает. Выглядит немного непривычно. Другие планировщики во избежание трудностей с пониманием времени окончания в следующих сутках запрашивают длительность выполнения задачи – «в течение Х часов».
Зачем создавать в одно и то же время полный бэкап и бэкап ЖТ
Если за полным бэкапом немедленно следует бэкап ЖТ – можно быть на 100% уверенным в том, что план создан мастером планов обслуживания (никогда не используйте его, он не создает ничего, кроме мусора) или администратором низкой квалификации, считающим пару Full backup + TLog backup, сделанную в одно время, неким обязательным комплектом для восстановления. А ведь это – независимые задачи, выполняющиеся по разным расписаниям.
Но наш план является исключением, поскольку наша цель – в одном подплане собрать информацию об успешности выполнения ключевых задач (целостность, полный бэкап, бэкап ЖТ), и только в случае их успешного выполнения отдать команду на удаление старых бэкапов.
Если удаление старых бэкапов выполняется безусловно, может оказаться, что новые бэкапы не создаются, а старые окажутся удалены полностью. Если удаление старых бэкапов раскидывается в зависимости от типа бэкапа по разным подпланам – получается почти то же самое. Допустим, перестал срабатывать полный бэкап. При этом перестало выполняться удаление старых полных копий. Но подплан Бэкап ЖТ ничего об этом не знает и продолжает удалять устаревшие бэкапы ЖТ. Через некоторое время у нас не будет не только непрерывной прямой восстановления, но и даже точек восстановления в актуальном окне: последний сделанный полный бэкап сделан слишком давно, а хранящиеся бэкапы ЖТ за последнее время абсолютно бесполезны, т.к. нет ни одного полного бэкапа внутри их непрерывной цепочки.
Задача дифференциального бэкапа ключевой для восстановления не является и в подплане не фигурирует. Но в этот подплан все-таки можно было бы добавить и ее, расположив сразу после полного бэкапа.
Вычисляемые параметры
*
*Заметьте на задаче значок fx
У каждой задачи есть свойства, часть из которых можно увидеть в диалоге настройки задачи (двойной клик), а полный список – в диалоге свойств (правый клик, Properties). Также в задачах есть свойство Expressions, которое позволяет сформировать таблицу свойств и соответствующих им выражений SQL, для вычисления значений свойств «на лету». Практическая польза от этой возможности следующая. Наверняка вам приходилось видеть т.н. «батники» для того, чтобы удалить все, кроме бэкапов на первые числа, или наоборот, чтобы перед удалением бэкапов скопировать бэкапы на эти числа в какое-то другое место.
Подобные задачи не требуют внешних инструментов и решаются штатными средствами MS SQL. Расширение файла полной резервной копии по первым числам можно сделать MNT, а по остальным дням – BAK. А значит, задача очистки может удалять BAK старше 1 месяца, а MNT хранить более длительное время, удаляя их, например, через 1 год.
При открытии диалога настройки задачи «Полный бэкап БД» вы увидите расширение файла BAK или MNT в зависимости от сегодняшней даты.
Почему две задачи серые?
Согласно рекомендациям 1С, обновление статистики должно производиться ежедневно, а очистка процедурного кэша – с частотой обновления статистики. Данные задачи являются достаточно ресурсоемкими с одной стороны, а с другой – не являются принципиальными для информационных баз команды разработки. Ведь такие базы не содержат много данных, и вопросы производительности остро не стоят. Поэтому данные задачи выполняются в еженедельном подплане, а в ежедневном они запрещены (правый клик по задаче, Disable). Не просто отсутствуют, а именно созданы и запрещены.
Рассмотрим закономерный вопрос: а все ли корректно будет работать в запрещенной задаче? Как на такой запрет отреагируют красные, черные и зеленые стрелки?
Запрет задач и моделирование результата
При написании сложных планов обслуживания возникает задача отладки и вытекающие из нее практические потребности:
- Не выполнять долгую задачу фактически, но считать ее условно выполненной, сохранив ее влияние в виде стрелок на остальные задачи;
- Моделирование ошибочного выполнения задачи.
Для первого в MS SQL есть механизм запрета фактического выполнения задачи: правый клик по задаче, Disable. При этом задача станет серой, фактически выполняться не будет, но будет считаться как завершенной, так и выполненной (будут работать черные и зеленые стрелки). Если мы хотим смоделировать ошибочное выполнение, то в окне свойств задачи надо установить свойство задачи ForceExecutionResult в значение Failure. Не перепутайте это свойство со свойством ForcedExecutionValue в другом разделе.
Реализация условия ((A or B) and C) для ограничений задачи или фиктивные задачи, которые совсем не фиктивные
Ограничения могут быть объединены или оператором AND, или оператором OR. Это значит, что на иллюстрации ниже пунктирные стрелки Completion нельзя провести непосредственно к задаче «Оповестить о завершении с ошибками». Решение состоит в создании промежуточной задачи «Были ошибки», аккумулирующей результат пунктирных черных стрелок. Задача является SQL-скриптом из одной единственной инструкции go, то есть, казалось бы, ничего полезного не делает.
Но на самом деле она собирает входящие ограничения и служит источником ограничений для других задач, являясь, таким образом, важной точкой управления, через которую проходит выполнение сценария. Данный прием с фиктивной задачей можно использовать и в других ситуациях. Например, в вашем сценарии нет нужды переводить базы в состояние оффлайн и затем возвращать состояние обратно. Но просто так задачу «Онлайн небэкапируемых баз» из подплана не удалить, она является важной точкой выполнения, собирая входящие ограничения и служа источником исходящих. В таком случае, надо заменить эту задачу фиктивным сценарием.
Асинхронность выполнения
В конструкции на иллюстрации выше может возникнуть «квантовый парадокс», когда следствие опережает причину. В самом деле, если одна из влияющих задач, например, «Ошибка целостности» дала сигнал к запуску зависимой задачи, ждать результата от остальных влияющих задач уже не имеет смысла, это все равно не повлияет на то, что зависимую задачу «Были ошибки» надо запускать. Поэтому она сразу же выполнится. Еще через некоторое время может случиться так, что сработает и завершится задача «Ошибка бэкапа ЖТ». Она могла бы служить причиной запуска «Были ошибки», но это событие уже произошло ранее. В нашем подплане так и задумано, но такого рода асинхронные эффекты следует иметь в виду, чтобы не получить неожиданные результаты. Например, при замере общего времени выполнения подплана обслуживания с помощью задачи «оповещение оператора» в начале и в конце.
Что это такое?
Это первая и одна из последних выполняемых задач, являющихся скриптами SQL. Дело в том, что в контуре разработки часто присутствуют копии исторических систем весьма большого объема. Они предназначены для ознакомления с ведением исторического учета, служат источником данных в операциях миграции. Данные в них практически не меняются. Оригиналы баз находятся в текущем продуктивном контуре заказчика, копии этих систем всегда могут быть получены по запросу. Бэкапить этот гигантский объем информации – впустую расходовать ресурсы. В параметрах задач, создающих бэкапы, хорошей практикой является указание в задачах бэкапа параметра «All» вместо перечисления конкретных баз данных (это позволяет избежать типичной ошибки «базу создали, а в список бэкапа включить забыли»). А раз так, необходим механизм какого-то исключения некоторых особых баз из множества All. Именно это и делает первый скрип – переводит такие базы в состояние OFFLINE. Второй скрипт выполняет обратную операцию. При этом в параметрах задач бэкапа или реиндексирования ставится параметр «Игнорировать базы в состоянии OFFLINE», иначе возникнет ошибка задания.
Параллельно или последовательно
В подплане «Ежедневный полный бэкап» самой первой выполняется задача «Оффлайн небэкапируемых баз», т.к. это единственная задача, не имеющая ограничений. Ниже нее мы видим выстроенную последовательность выполнения задач, являющихся основным стержнем подплана «Ежедневный полный бэкап».
В качестве причин последовательного выполнения назовем, допустим, желание не превысить нагрузку сервера SQL во время обслуживания и наглядность восприятия плана. Обычно, за счет большого ночного окна с перерывом в работе пользователей последовательное выполнение не становится проблемой. Но могут быть ситуации, когда с базой работают много пользователей из разных часовы&
Резервное копирование и восстановление данных
Резервное копирование и восстановление данных
Дорогие друзья, сегодня мы с вами рассмотрим очень важную тему: резервное копирование и восстановление данных. Почему эти два понятия идут вместе и никак не раздельно? В чём их особенности, для чего они нужны? На все эти вопросы мы ответим сейчас, а потом перейдём непосредственно к активным действиям.
Восстановление данных
Итак, начнём с резервного копирования: оно позволяет нам сохранить все файлы, документы и другую информацию с устройства или программы на внешний носитель информации. Обратите внимание, что в качестве последнего может выступать облачное хранилище в интернете. Но далеко не все данные можно хранить таким образом. Об этом мы поговорим чуть-чуть позже.
Восстановление данных же даёт возможность вернуть всё то, что мы сохранили ранее, с последующей эксплуатацией файлов. Например, если вы сохранили фотографии с вашего летнего отпуска в облачном хранилище, то вы сможете их потом не только посмотреть, но и загрузить обратно на любое поддерживающее устройство. Теперь, когда вы немного пополнили свой багаж двумя этими понятиями, мы можем перейти к активному обсуждению: как сделать резервное копирование данных, какие существуют для этого программы, на каких устройствах это можно делать и так далее. Как видите, наша небольшая дискуссия потихоньку становится обширнее. Чтобы вам было легче работать, то сразу покажем вам блоки, которые будут освещены. Можете сразу выбрать нужный вам и приступать к работе:
- Информация с компьютера
- Информация с планшетов и смартфонов
- Облачное хранилище
- Рекомендации пользователю
Облачное хранилище
Стоит отметить, что для создания копии файлов или системы вам потребуется внешний носитель информации, на котором будут храниться ваши данные. Вставьте его в USB-вход на вашем компьютере или ноутбуке. Позаботьтесь о том, чтобы объём доступного пространства на диске или флешке был больше, чем занимают ваши файлы. Также проследите за тем, что во время записи не произошёл какой-нибудь сбой: если кто-то случайно заденет кабель и он отсоединится, то вы можете потерять данные.
Если вы хотите создать копию со смартфона или планшета, то желательно использовать оригинальный кабель для подключения к ПК. Для пользователей облачного хранилища рекомендуется наличие быстрого безлимитного интернет-соединения. Например, если у вас будет ограниченный трафик, а вы его превысите, то вам придётся выложить некоторую сумму, чтобы покрыть образовавшийся долг.
Информация с компьютера
Так как компьютерные данные занимают первую строчку в рейтинге важности среди остальных устройств, с них мы и начнём нашу работу. Прежде всего стоит отметить, что здесь тоже есть небольшое деление резервной копии по типу сохраняемой информации: это может быть полная копия операционной системы, копия вместе с файлами или отдельное хранение файлов. Для удобства рассмотрим пример для Windows 7, 8.1 и 10.
Windows 7
- Переходим в панель управления компьютера с помощью кнопки Пуск или любых других средств навигации.
- Нажимаем на меню «Система и безопасность».
- Далее, перед вами откроется окно с вкладками, где нужно будет нажать на «Резервное копирование и восстановление данных».
- Итак, в новом окне вы увидите меню с настройками архивации. Нажмите на пункт «Архивация и восстановление».
- Далее, нам понадобится настроить резервное копирование с помощью одноимённой синей кнопки.
Нажимаем на «Настроить резервное копирование»
- Затем перед вами появится диалоговое окно с настройками архивации. Выберите свой жёсткий диск и жмите на кнопку «Далее».
Выбираем расположение архива
- В следующем окне система попросит вас уточнить, что именно следует архивировать. Рекомендуется использовать первый вариант («Предоставить выбор Windows»), так как он сохраняет всё и регулярно обновляет данные. Обратите внимание, что здесь второй вариант даёт пользователю самому выбрать, что именно нужно сохранить. То есть, вы можете поставить свои папки или отдельные директории, если полная резервная копия вместе с файлами операционной системы вам не нужна.
Выбор объектов для архивации самостоятельно
- Далее, мы проверяем установленные параметры. Здесь вы можете установить расписание для автоматического создания копии с помощью кнопки «Изменить расписание».
Расписание
- Когда всё будет установлено и проверено, нажмите «Сохранить параметры и запустить архивацию».
Процесс выполняется
- Дождитесь окончания процесса, затем проверьте ваш внешний жёсткий диск: записались ли на него ваши данные.
Windows 8.1
- Запустите панель инструментов в правой части экрана. Для этого отведите мышь в правый верхний угол затем нажмите на «Поиск».
- Наберите с клавиатуры словосочетание «История файлов» без кавычек и нажмите Enter. В полученных результатах нажмите на одноимённую папку.
- Вы попадёте в окно, где нужно будет нажать на ссылку «Резервная копия образа системы», которая расположена в левом нижнем углу окна.
«Резервная копия образа системы»
- Выбираем место хранения архива (как мы договорились выше, это должен быть внешний жёсткий диск). Жмите «Далее».
- Следующее окно покажет вам объём памяти, который потребуется. Проверьте все данные и нажмите кнопку «Архивировать».
- Подождите, пока система создаст резервную копию Windows на внешнем носителе информации. Этот процесс может занять некоторое время, поэтому не спешите паниковать.
Windows 10
- Запустите «Параметры» с помощью кнопки Пуск на панели задач.
- Теперь откройте вкладку «Обновление и безопасность».
- В левом столбике с параметрами нажмите на пункт «Служба архивации».
- С помощью одноимённой кнопки настройте систему автоматического резервного копирования.
- Обратите внимание, что вы там же без проблем можете легко регулировать папки, копии которых будут создаваться. Это намного облегчит вашу работу.
- Если же вы хотите создать полную резервную копию вместе с операционной системой, а не отдельные библиотеки и директории, то воспользуйтесь инструкцией для Windows.
Для восстановления данных повторите пункты до нахождения настроек архивации. НО теперь просто выберите вкладку или пункт «Восстановление» и просто следуйте инструкциям в диалоговом окне на экране вашего монитора. Ничего сложного в этом нет. Естественно, мы с вами рассмотрели штатные средства ОС Windows от Майкрософта. Существуют и специальные программы для проведения аналогичных операций. Они могут быть удобнее, но в плане безопасности и надёжности могут уступать этим. Поэтому рекомендуется всё же пользоваться стандартными утилитами ОС.
Информация с планшетов и смартфонов
Здесь всё несколько проще, так как тоже используются стандартные программы (например, для iPhone и iPad мы будем работать с iTunes). Для всех гаджетов любой операционной системы процедура выполнения резервной копии будет одна и та же:
- Подключите своё устройство к компьютеру или ноутбуку. Дождитесь установки соответствующих драйверов.
- Запустите программу, которая предназначена для синхронизации с вашим девайсом. То есть, если у вас Айфон, то откройте приложение iTunes на своём ПК.
- Найдите вкладку или пункт «Синхронизация», или «Резервное копирование». Кликните по ней и, следуя подсказкам на экране, создайте копию.
Резервное копирование с iPad на компьютер
- Для восстановления данных в этом же окне найдите одноимённую кнопку и нажмите на неё.
- Во время выполнения компьютером этих действий ни в коем случае не отсоединяйте устройство от USB. Это может кончиться программной поломкой девайса.
- Обратите внимание, что вы можете просто перенести некоторые файлы со смартфона или планшета на ПК. Особенно это актуально для владельцев гаджетов под управлением операционной системы Android: здесь имеется полный доступ ко всем файлам и папкам.
- Владельцы iOS-девайсов могут хранить только фотографии и видео аналогичным образом: зайдите в «Компьютер» и кликните правой кнопкой мыши по вашему устройству. Нажмите на «Импорт фотографий и видео». Следуя подсказкам на экране, вы можете не только сделать импорт, но и настроить его.
Облачные хранилища
Сегодня этот типа хранения данных достаточно популярен на рынке: не нужны никакие флешки, кабели и другие средства периферии. Нужно лишь активное скоростное подключение к интернету, и все ваши файлы у вас в руках. Их настройку рассматривать мы не будем (для этого есть отдельная тема), а просто скажем о каждом хранилище для определённой ОС:
- OneDrive для Windows
- iCloud и iCloud Drive для iOS и MacOS
- Google диск для Android
Стоит отметить, что есть ещё универсальные, которые ставятся на любое устройство, вне зависимости от установленной ОС:
- Облако Mail
- OneDrive
- Google диск
Как вы заметили, из всех хранилищ, только компания Apple сделала свой продукт доступным лишь для своей системы. Плохо это или хорошо — решать вам.
Рекомендации пользователю
- При использовании внешнего жёсткого диска или флешки, позаботьтесь о том, чтобы она обладала достаточным объёмом свободного пространства.
- Обратите внимание, что большинство облачных хранилищ имеют ограниченную память для бесплатного доступа. Например, в iCloud Drive вам доступно будет пять гигабайт. Чтобы расширить её вам нужно будет покупать подписку. Если у вас не так много файлов, то покупать ничего не нужно. Можете также пользоваться несколькими облачными хранилищами.
- Проверяйте создание копий: если память на диске или в облаке закончилась, то копия не создастся. Вы рискуете потерять некоторые данные, что будет очень печальным последствием.
- Если вы просто копируете некоторые файлы, то желательно удалить их с копируемого девайса для освобождения памяти на нём.
- Если вы хотите сохранить очень важные документы, то лучше сделать две копии. Например, можете одну сделать на внешнем жёстком диске, а другую с помощью программы облачного хранилища.
Подведём итоги
Дорогие друзья, сегодня мы с вами обсудили очень обширную и важную тему: резервное копирование и восстановление данных. Особый акцент был сделан на компьютерной информации, затем мы рассмотрели общий принцип создания копии смартфонов и планшетов, а также познакомились с облачными хранилищами. В конце мы дали несколько рекомендаций, чтобы ваша работа была максимально продуктивной. Запомните: вовремя сохранённые данные являются залогом сохранения ваших нервов. Если вы потеряете файлы своей дипломной работы, которую вы делали несколько недель или месяцев, то будет не очень весело, не так ли? Расскажите в комментариях, какими службами архивации вы больше всего предпочитаете пользоваться и почему.
Программа Exiland Backup или надежное резервное копирование файлов как для домашних пользователей, так и для организаций. Восстановление файлов из резервной копии. Синхронизация как вид резервного копирования
Здравствуйте, уважаемые читатели сайта www.remontcompa.ru! Меня зовут Роман Нахват и сегодня мы с вами продолжим работу с программой резервного копирования файлов Exiland Backup. В статье «Программа Exiland Backup или надежное резервное копирование файлов как для домашних пользователей, так и для организаций» мы создали три задания резервного копирования с именами Backup Task 01, Backup Test 02, Backup Task 03 и выполнили резервное копирование файлов, сохранив резервные копии как на локальных носителях, так и на ftp и ssh серверах. Рассмотрим обратный процесс, а именно восстановление файлов из созданной резервной копии (например в случае случайного удаления файлов).Программа Exiland Backup или надежное резервное копирование файлов как для домашних пользователей, так и для организаций. Восстановление файлов из резервной копии. Синхронизация как вид резервного копирования
В главном окне программы Exiland Backup видим созданные и выполненные задания резервного копирования Backup Task 01, Backup Test 02 и Backup Task 03.
Перед тем, как приступить к восстановлению файлов из созданных резервных копий, необходимо удостовериться в их доступности для нужного задания резервного копирования. Выполним проверку доступности резервных копий для заданий Backup Task 01, Backup Test 02, Backup Task 03. Для этого первым выделяем задание Backup Task 01, переходим на вкладку Созданные резервные копии. Как видим, в задании резервного копирования Backup Task 01 резервную копию мы сохраняли на ftp сервере с ip адресом 192.168.100.21, и в папке My foto на разделе F жесткого диска.
Жмём Проверить.
Выделим задание резервного копирования Backup Task 03 и перейдём на вкладку Созданные резервные копии. При создании задания Backup Task 03 в качестве исходной папки выступала папка Documents на разделе E, которая содержала в себе файлы Doc-01.doc, Doc-02.doc, Doc-03.doc, Doc-04.doc и Doc-05.doc. Резервную копию папки Documents мы сохраняли на ssh сервере с ip адресом 192.168.100.6, а также в сетевой папке Backup documents.
Восстановим содержимое папки Documents из резервной копии, сохранённой на ssh сервере.
Выделяем резервную копию и жмём Просмотр.
Мы можем восстановить файлы из резервной копии как в исходное расположение (то есть в папку Documents на разделе E), или в любую другую папку. Для начала выполним восстановление файлов в исходное расположение, т.е в папку Documents.
Синхронизация как тип резервного копирования файлов
Синхронизация представляет собой такой тип резервного копирования, который позволяет иметь 2 идентичные по составу папки, при этом при добавлении или изменении файлов в одной папке все изменения будут отражаться в другой. В нашем случае в качестве исходной папки будет выступать сетевая папка My music на удаленной машине D-01. Данные этой сетевой папки мы будем синхронизировать в конечную папку Music на разделе E: жёсткого диска.
