Rusguard ошибка авторизации карты

Видеоинструкции

Установка ПО RusGuard Soft | Как установить СКУД РусГард

Как настроить RusGuard Soft? | Инструкция по настройке СКУД РусГард

Как настроить учет рабочего времени в СКУД

Как создать и настроить карту Mifare в СКУД RusGuard

Эмиссия карт Mifare Classic, Mifare ID и Mifare Plus в RusGuard Reader Config

Обзор функционала и настройка мобильного приложения RusGuard Mobile

Как сделать правильное фото для терминала распознавания лиц

Настройка автономного контроллера и считывателя от RusGuard и его возможности

Как настроить считыватель пластиковых карт? RusGuard Reader Config

Пропуск в телефоне | Использование NFC в смартфоне для контроля доступа

Настройка алкотестеров Динго и Алкорамки в СКУД RusGuard

Как настроить терминал распознавания лиц R20 Face от RusGuard

Интеграция 1С и СКУД RusGuard | Подключаем считыватель бесконтактных карт к 1С

Как узнать IP адрес контроллера RusGuard? | Настройка СКУД Русгард

Источник

Работа считывателей карт за рамками СКУД

Считыватели RFID-карт могут использоваться не только в составе СКУД. Благодаря бесконтактной идентификации можно решить множество задач: от выдачи обедов в столовой до запуска производственных станков.

Считыватели в СКУД

Задача считывателей в СКУД всем понятна. Если это настенный считыватель (например, R15-Multi), то он считывает данные RFID-карты, которые передаются в контроллер СКУД, где и принимается решение о доступе пользователя на охраняемую территорию.

Если речь идет о настольном считывателе, то как правило он необходим для передачи данных карты в программное обеспечение СКУД. Это намного быстрее, чем переписывать данные карты вручную для каждого сотрудника.

И настенные, и настольные считыватели RusGuard могут использоваться не только в составе СКУД RusGuard, но и с любыми другими системами контроля доступа.

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

Как можно использовать настольный считыватель

К настольным считывателям относятся R5-USB и R5-USB (Prof). Оба считывателя мультиформатные, то есть поддерживают работу с картами 125 KHz (Em-Marine, HID Prox II) и 13.56 MHz (Mifare). Версия Prof также умеет работать с картами Indala и Cotag, а также со смартфонами и другими умными устройствами по протоколу NFC.

1. Эмуляция клавиатуры.

Настольные считыватели RusGuard могут работать в качестве эмулятора клавиатуры. Это самый простой способ получения данных из карты для использования их в сторонних приложениях: открываем любую программу, активируем поле для ввода символов, подносим карту к считывателю – и туда автоматически прописываются данные с карты. Такой программой может быть 1С, другой специализированный софт и даже обычная таблица Excel.

Этот функционал работает как в операционной системе Windows, так и в Linux. Более того, можно подключить настольный считыватель и к устройству на базе Android через OTG-переходник. И в этом случае он будет передавать в приложение данные с карты.

Как настроить?
Необходимо скачать утилиту RusGuard Reader Config. В списке виртуальных интерфейсов выбираем пункт «Эмуляция клавиатуры». Далее выбираем, в какой кодировке считыватель будет передавать данные. Для решения базовых задач достаточно предоставления кода в десятичном формате (Dec) или в шестнадцатеричном (Hex). После настройки не забываем нажать кнопку «Записать конфиг».

2. Эмуляция COM-порта

По функционалу этот способ очень похож на эмуляцию клавиатуры. Дело в том, что некоторые приложения работают только с устройствами, подключенными через COM-порт. Например, та же 1C попросту не будет знать о том, что к компьютеру через USB подключен настольный считыватель. Но это можно исправить. У считывателя есть возможность эмулировать COM-порт. В этом режиме он определяется как устройство, подключенное к COM-порту. Дальше остается указать в приложении, с каким COM-портом ему нужно работать, и можно получать данные с устройства.

Как настроить?
Скачиваем утилиту RusGuard Reader Config. В списке виртуальных интерфейсов выбираем пункт «Эмуляция COM-порта». Далее необходимо установить формат кода. Вы можете выбрать любую из трех кодировок (Dec, Hex или ASCII) – все зависит от желаемого результата . После настройки не забываем нажать кнопку «Записать конфиг». Операционная система (Windows или Linux) обнаружит новый COM-порт. Его и нужно указать в вашем приложении.

3. Работа через API.

Это способ наиболее сложный, однако, он предполагает наиболее широкие возможности при использовании наших настольных считывателей. У нас есть готовый кроссплатформенный API, который можно использовать в любых приложениях для Windows или Linux. API позволяет гибко настраивать считыватель (например, можно ограничить форматы карт, с которыми работает считыватель, изменить тип световой индикации, указать, какую именно информацию будет передавать считыватель). Само собой, для этого вам потребуется разработчик, который сможет внедрить API RusGuard в вашей системе.

Для удобства использования API уже имеет набор готовых примеров, которые можно внедрять в ваше решение.

Просто скачайте API RusGuard и передайте его вашему разработчику вместе с пожеланиями по работе считывателей.

4. Native API для 1C

Для решений на базе 1C у нас также есть внешняя компонента, написанная по технологии Native API. Она позволяет встроить считыватели R5-USB в экосистему 1С и тонко настроить их работу. В состав API также входят готовые примеры реализации – вам останется лишь вставить этот код в свое решение на базе 1С.

Необходимо скачать внешнюю компоненту Native API и передать ее вашему разработчику 1С, который решит поставленную задачу.

Как можно использовать настенный считыватель

К настенным считывателям относятся R10-EHT, R10-MF, R10-MF (QR), R15-Multi, а также устройства линейки RDR-204. Разные модели устройств работают с идентификаторами разных форматов (или RFID-карты с частотой 125 KHz, или карты 13,56 MHZ). Мультиформатный считыватель R15-Multi может работать одновременно со всеми типами карт, в том числе со смартфонами.

Настенный считыватель можно использовать для решения совершенно разных задач. Например, на одном из промышленных предприятий реализована следующая схема работы.

На производстве работает несколько десятков станков и других агрегатов. Есть некоторые ограничения на их использование: только определенные сотрудники и в определенное время имеют право их включать и работать на них. На каждый агрегат устанавливается считыватель RusGuard с внешним карманом для фиксации карты. Сотрудник опускает персональную карту-пропуск в карман считывателя, после этого считыватель замыкает внутреннее реле – тем самым дается разрешение на включение станка штатными средствами. Без идентификации сотрудника запуск агрегата невозможен.

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

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

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

Настенные считыватели используют другой тип соединения – RS-485. Такой интерфейс позволяет передавать данные без потерь на расстояние до одного километра. При этом сигнал может быть конвертирован соответствующими переходниками в USB или LAN-интерфейс для удобства приема.

Также надо отметить, что принимающим устройством не обязательно должен быть классический «большой» компьютер под управлением Windows или Linux. Таким устройством может быть:

• мини-компьютер (Raspberry или подобный);
• контроллер на базе Linux;
• смартфоны или планшеты на базе Android.

Главные требования к таким устройствам – наличие интерфейсов USB или LAN на борту, а также способность принимать и должным образом интерпретировать входящие данные от считывателей.

Рассмотрим два основных способа реализации такого решения.

1. Простая передача кода из считывателя

Считыватели RusGuard можно последовательно подключить в линию к шине RS-485. Количество устройств на одной линии может достигать 32 штук (но можно подключить и всего один считыватель). Далее на линию устанавливается конвертер для интерфейса RS-485: он будет преобразовывать сигнал либо для интерфейса USB, либо для интерфейса LAN – все зависит от типа принимающего устройства. При прикладывании карты считыватель будет передавать на принимающее устройство пакет с данными, куда входит адрес считывателя и UID карты. Таким образом, принимающее устройство будет понимать, к какому считывателю какая карта была приложена.

Скачиваем утилиту RusGuard Reader Config. Устанавливаем формат кода «Код в пакете AddrCod». Для каждого считывателя устанавливаем уникальный адрес. После настройки не забываем нажать кнопку «Записать конфиг».

2. Передача кода посредством API

Более сложный, но и более функциональный вариант. Он позволяет не только получать коды бесконтактных карт, но и гибко настраивать работу считывателей. Можно определять, какие форматы карт будет читать устройство, можно управлять световой индикацией, а также состоянием встроенного реле в считывателе. Главное преимущество такого решения – управлять работой считывателей можно из внешнего приложения. Фактически можно организовать мини-СКУД с базовым набором возможностей.

Принцип построения такого решения во многом схож с предыдущим. Подключаем считыватели в линию к шине RS-485. Однако стоит помнить: в этом случае количество считывателей на одной линии не должно превышать 4 штук. Далее к линии подключаем конвертер RS-485/USB или RS-485/LAN. Кабель от конвертера подключаем к принимающему устройству.

Скачиваем утилиту RusGuard Reader Config. Устанавливаем для каждого считывателя уникальный адрес от 0 до 3. Далее вся настройка происходит через API.

Источник

Так сложилось исторически, что мы стали дилером компании RusGuard чуть ли не сразу после её образования. Причиной тому было то, что компания была основана бывшими сотрудниками другой компании – Legos, с которой мы довольно плотно работали. Дилерами стали, но сотрудничество как-то не задалось – инсталляций не было, только продавали оборудование несколько раз. Позже решил посерьёзнее познакомиться с тем, что же у ребят получилось. Первый критерий оценки очень простой – беспроблемная установка софта. Скачал дистрибутив, попробовал поставить – не вышло. Отложил до лучших времён.

Справедливости ради скажу, что та же история произошла и с CARDDEX – попробовал, словил кучу проблем, отложил. Логика такая – разобраться можно со всем, но зачем лишние проблемы на объекте, если есть гораздо более стабильные решения.

Первое знакомство

Недавно обратился клиент с просьбой установить ему СКУД со считывателями, работающими по технологии BLE и NFC. И сам же клиент нашёл такой считыватель R15-Multi у RusGuard, поскольку первоначально предложенный мной считыватель SIGUR MR1 BLE был заметно дороже. К тому же софт у SIGUR стоит денег, а у RusGuard предоставляется бесплатно.

Решено – RusGuard-у на объекте быть! Будет интересно поразбираться с новым оборудованием. Связался с поставщиком, обсудили возникшие вопросы об автономной и сетевой работе, сформировали комплект оборудования и сделали заказ.

Установка

Сроки поджимали, поэтому пощупать оборудование в офисе не удалось – сразу приступили к монтажу. Решил потренироваться в установке на своём ноутбуке. Недавно менял диск и ставил заново ОС, поэтому компьютер, практически, девственно чист. Не ожидая подвоха скачал дистрибутив (3,7 Гб вместе с SQL Server) и запустил установку. При запуске было сказано, что .NET Framework 4.6 в системе присутствует, а IIS отсутствует, поэтому будет установлен автоматически. Далее выбрал вариант с установкой SQL ServerExpress 2014, задал имена и пароли, какие попросили, но чуда не случилось – установка завершилась с ошибкой. Попробовал ещё раз – то же самое.

Когда ничего не получается, самое время читать инструкцию или смотреть видеоролик, поэтому полез смотреть ролик про установку. Первое требование – компьютер должен быть “чистым”. Почти так и есть. Следующая возможная проблема – имя компьютера. Почему-то дефолтные виндовые имена – это не есть “хорошо”. Имя действительно было дефолтное – поменял, не помогло. Включил вручную ISS, хотя об этом в ролике и не было, и повторил попытку – не помогло. Посмотрел ролик дальше и увидел там, что необходимо установить ещё и .NET Framework 3.5, а иначе SQL Server не установится. Установил фреймворк, запустил снова инсталлятор и SQL Server таки встал! Но рано радовался, т.к. установка опять завершилась с ошибкой – что-то там с правами. Запустил инсталлятор снова и выбрал вариант с уже установленным SQL Server. На следующем шаге инсталлятор выдал ошибку авторизации и предложил ввести правильный пароль пользователя sa. Ввёл. Инсталлятор его принял и на следующем шаге попросил ввести пароль пользователя user для сервера отчётов. Не понял, что за пользователь такой, но нашёл в документации, что на сервер отчётов вход производится под пользователем ОС и ввёл свои логин и пароль. Инсталлятор ещё пошуршал и, о чудо – установка завершилась успешно!

Что хочется сказать? Не надо так! Почему установка происходит с такими сложностями? Почему нельзя всё автоматизировать? Чем плохи дефолтные виндовые имена? Почему наличие в системе .NET Framework 4.6 проверяется, а .NET Framework 3.5 нет, хотя он необходим?

Взять те же SIGUR или PERCo – в них установка происходит на порядок проще. Ну и фраза “ПО может не установиться”, часто звучащая в ролике, несколько настораживает. Сделайте так, чтобы устанавливалось! Хороший и правильный дистрибутив должен содержать в себе все необходимые компоненты, проверять соблюдение всех требований и не допускать возникновения ошибок в процессе установки.

На объекте пришлось устанавливать на Windows Server 2019. В принципе всё прошло гладко, кроме того, что сначала пытался запускать инсталлятор из папки с Рабочего стола, но из-за длинных путей SQL Server устанавливаться не хотел. Опять же, без объяснения причин. По совету тех.поддержки попробовал установить его отдельно и только тогда увидел причину ошибки установки.

Проблемы с NFC и BLE

Проблемы эти проявились в процессе настройки, но чтобы не отвлекаться от темы настройки в следующей части, расскажу про них сразу. Так вот, оказалось, что несмотря на информацию в описании считывателя R15-Multi, приложения под iOS нет в принципе. Оно, как-бы в разработке, но сроки выхода неизвестны. Из этого следует то, что технология BLE для iPhone пока недоступна. Использовать можно только NFC, но, поскольку прямой доступ к чипу NFC в iOS закрыт, то приходится делать это через ApplePay, используя в качестве идентификатора ID какой-нибудь банковской карты. Это несколько смущает пользователей. т.к. при поднесении смартфона к считывателю они видят тот же интерфейс, что и при оплате через терминал на кассе. Многие опасаются, а не снимут ли у них со счёта деньги.

На смартфонах с Android тоже можно пользоваться Google Pay, но есть и приложение, называется RusGuard Key. В нём настраивается тип идентификатора (3 варианта) и каким образом должна происходить идентификация – через NFC или BLE или и так и так и если через BLE, то автоматически или вручную. Автоматический режим работы BLE подразумевает разблокировку двери сразу, как только смартфон попадает в зону действия считывателя. И вот это второй EPIC FAIL – в отличие, например, от считывателя SIGUR MR1 BLE, дальность действия считывателя R15-Multi не настраивается! То есть дверь открывается с расстояния 5-6 метров. А может и больше – это уже зависит от модуля Bluetooth смартфона. Ручной режим подразумевает отправку идентификатора не постоянно, а только после сработки акселерометра, то есть смартфон надо потрясти или покрутить. Это уже лучше, но всё равно не очень хорошо, потому что эти настройки делаются в приложении на смартфоне пользователя, а такие вещи лучше делать на стороне сервера.

Ну и финальный аккорд – не на всех Android-смартфонах приложение работает корректно. Это понятно – производителей таких смартфонов много, версий систем в них установленных, учитывая кастомные прошивки, ещё больше, ну и различные настройки безопасности и энергосбережения тоже вносят свой вклад. Винить разработчиков RusGuard тут не стоит – об этом честно упомянуто в описании продукта.

Настройка

Честно говоря, сначала софт не порадовал. Хотя и у аналогичных продуктов конкурентов интерфейс, прямо скажем, оригинальный. Так что придираться не буду. Хорошо то, что не глючит. Настроек много – чувствуется, что система масштабная и гибкая. После нескольких часов работы и к интерфейсу привыкаешь.

Автопоиском нашёл контроллер, добавил в систему, выбрал нужный тип точки доступа – Две двери и поменял схему индикации. Что SIGUR, что RusGuard используют по умолчанию каки-то странные настройки, а нужно то самое простое – чтобы в закрытом состоянии на считывателе горел красный индикатор, а при отпирании замка – зелёный. В SIGUR-е с индикацией всё сложно. Здесь же – из выпадающего списка значений параметра Схема индикации выбираем пункт Дежурный красный и всё работает, как надо.

На вкладке Дверь 1 и Дверь 2 нужно поменять протокол считывателя на RBus, чтобы настраивать его параметры из ПО.

Нужно было настроить систему на работу с NFC и BLE и c брелками форматов Mifare и EM-Marine, благо считыватель R15-Multi всеформатный. Для настройки нужно зайти в раздел Конфигурация системы, найти в дереве пункт Настройки Mifare и добавить профили для идентификаторов Mifare, приложения RusGuard Key и Apple/Google Pay. Профили для приложения и платёжных систем не настраиваются, а профиль для идентификаторов нужно чуть подправить. Усиленная защита не требуется, к тому же настольного считывателя нет, поэтому эмиссию идентификаторов Mifare производить не нужно, да и не получится. В параметре Режим аутентификации нужно выбрать вариант Защищённые данные или UID.

Теперь нужно в настройках контроллера добавить эти профили в список, причём в правильной последовательности: идентификатор, приложение, платёжная система. В нашем случае: Key, App, Pay. Далее, на вкладке RBus нужно сменить режим аутентификации на вариант Настройки профиля и там же ниже выбрать Разрешённые типы карт.

Настройка RusGuard

Следующий этап – импорт сотрудников из предоставленного XLS-файла. В основном ПО такой функции нет, но есть специальная утилита UniversalImport. Файл был специальным образом подготовлен – каждое поле в отдельном столбце и успешно импортирован в БД. После импорта сотрудников нужно было дать им право доступа. Это делается либо персонально, либо наследуется из настроек отдела. Хотел завести один родительский отдел и перенести все остальные в него, чтобы сделать назначение прав доступа парой кликов, но не вышло – в ПО нельзя редактировать структуру компании. Отделы можно только удалять и добавлять. Пришлось задавать права доступа для каждого отдела.

Опытная эксплуатация

Через пару дней после запуска в работу один из считывателей странным образом заглючил – перестал читать Mifare и NFC c BLE. С EM-Marine проблем не было. Нормальная работа восстановилась после перезапуска контроллера и считывателей путём сброса питания. Тех.поддержка посоветовала прошить считыватели свежей прошивкой и понаблюдать дальше, а если сбои повторятся, то отправлять к ним в ремонт или для замены. Продолжаем наблюдение.

Источник

12 типичных ошибок при бэкапе баз данных

Изначально эта статья задумывалась только для разработчиков и администраторов СУБД Firebird, но после общения с администраторами других БД выяснилось, что большинство ошибок общие, и на очень похожие грабли наступают буквально все. Если Вы можете что-то добавить к этому списку (пусть даже специфическое для конкретной СУБД), пишите в личную почту или в комментариях.
In English: 12 Common Mistakes while Backing Up Databases

Наша компания занимается инструментами восстановления, резервного копирования, оптимизации и поддержкой СУБД (в основном Firebird, но есть и MSSQL, PostgreSQL, InterBase и др.) и, как результат многочисленных аудитов и ремонтов, накопила коллекцию ошибок, связанных с резервным копированием. Все пункты ниже изложены по мотивам реальных случаев с повреждением баз, потерей и повреждением бэкапов, дисков, сбоями серверов, и прочих «радостей» администраторов БД.

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

Итак, приступим.

1. Удаление предыдущей копии бэкапа до того, как будет создана новая копия бэкапа
Чаще всего эту ошибку совершают новички, которые не понимают, что основная цель существования резервной копии БД – обеспечить минимальный простой информационной системы (важной частью которой является БД), а не просто создание копии БД.
В результате, с момента удаления последнего бэкапа до создания нового, система находится в незащищенном состоянии, потому что в этот период у базы данных нет ни одной резервной копии. Так как бэкап может создаваться достаточно долго, то это идеальное время для срабатывания закона Мерфи. Особенно хорошо этот подход работает в связке с пунктом 7 (см. ниже).
Рекомендация: не удаляйте предыдущий бэкап до того момента, как создан новый! (и не делайте новый бэкап в уже существующий файл)

2. Перезапись существующей базы данных при восстановлении из бэкапа
Эту ошибку совершают реже, но вот результаты могут быть гораздо печальнее. Если бэкап не проверялся и был поврежден (см. пункт 6), то в результате перезаписи у вас не будет ни предыдущей копии базы, ни валидного бэкапа.
Обычно это безобразие случается в пятницу вечером, в момент дерготни, неразберихи и противоречивых указаний со стороны начальства. Немного отрицательного везения и томные выходные в серверной обеспечены.
У Firebird есть некая защита от этой ошибки – создание рестора из бэкапа с помощью утилиты gbak с дефолтным ключом –create не сработает в случае, если указанное имя файла указывает на существующую БД. К сожалению, есть и обход этой защиты – переключатель –rep, который позволяет-таки переписать существующий файл.
Рекомендации: никогда не перезаписывайте файл боевой БД, не получив письменного указания руководства и, желательно, не получив предложения о новой работе.

3. Использование одношагового бэкапа-рестора, без создания промежуточного файла бэкапа
Стандартные потоки ввода-вывода позволяют провернуть с многими СУБД (с Firebird в том числе) интересный трюк: выполнять потоковый бэкап с немедленным восстановлением БД из него. В результате не создается промежуточный файл бэкапа. Это удобно для проведения регламентных работ и запуска проверочного восстановления (при наличии другой резервной копии), но ни в коем случае не надо использовать это для автоматического бэкапа!
Если в процессе такого бэкап-рестора произойдет серьёзный сбой диска, например, то может повредиться исходная база данных, а новая еще не будет создана. Конечно, если п.1 соблюдается, и есть копия БД от предыдущей попытки, то произойдет только потеря данных, которые были созданы или изменены в БД с момента создания ее копии.
Рекомендации: не используйте одношаговый бэкап-рестор в автоматическом режиме, а в ручном всегда проверяйте наличие достаточно свежей копии.

4. Хранение бэкапа и базы данных на одном и том же физическом устройстве
Тут многие могут посмеяться, что советы мы какие-то детские даем – это же азбука системного администрирования. Так-то оно так, но в связи с распространением виртуальных сред и БД, и диск могут находиться на одной СХД. А она обязательно сломается в самый неподходящий для бизнеса момент. Плюс, все еще существуют люди, которые верят в то, что если они используют RAID (от 1 и выше), то с их данными вообще ничего не может случиться. Еще есть люди, которые верят в сверхнадежность «брендового» железа, но это особый случай.
Рекомендации: не храните бэкап и БД на одном и том же физическом устройстве, каким бы надежным оно не казалась.

5. Отсутствие проверки успешного окончания бэкапа
Вот это довольно частая ошибка и администраторов, и руководителей ИТ подразделений. Если результат бэкапа не проверять, то можно бэкап не делать вообще — результат в общем тот же. Обязательно нужны нотификации по email об успешном бэкапе, а еще лучше и по СМС. Причем, отсутствие нотификации это признак проблемы!
А причем тут руководители, спросит внимательный читатель, дочитавший до этого места? А притом, что администратор обычно бэкап настроит, но вот нотификации ему проверять лень, тем более что лежат они у него в отдельной папочке, и поэтому руководителю ИТ-отдела надо периодически запрашивать дополнительный отчет о состоянии всех бэкапов. Это к вопросу, кого наказывать, если бэкапы вроде есть, но в нужный момент их не оказалось 🙂
! А при комбинировании с пунктом 2 получаем отсутствие и базы, и бэкапа.
Рекомендации: использовать инструменты автоматизации бэкапов, которые умеют отслеживать успешные и неуспешные бэкапы, сообщать пользователям о проблемах, и имеют обзорные средства контроля (особенно актуально, когда нужно контролировать десятки и сотни бэкапов на разных серверах).

6. Отсутствие валидации бэкапов
То, что бэкапы куда-то кладутся, не означает, что они оттуда могут быть прочитаны.
Поэтому обязательна периодическая верификация создаваемых бэкапов, чтобы быть уверенным, что создаваемые бэкапы не повреждены, не были скопированы в /dev/null
Рекомендации: никому не доверять, даже себе. Всех надо проверять.

7. Отсутствие health check базы данных при использовании неверифицированных бэкапов
Обычно СУБД имеют несколько видов бэкапа – дампы, просто бэкапы и т.д. Не вдаваясь в конкретику, можно выделить 2 категории – верифицированные и неверифицированные бэкапы. У Firebird это gbak и nbackup.
Gbak читает всю БД на уровне записей для создания файла бэкапа, и создает БД путем вставки записей в новую БД, и таким образом верифицирует и бэкап (есть варианты, как ошибки могут просочиться в отресторенную копию, но это уже другой вид факапа администратора БД, связанный с неверной миграцией), и саму базы данных (если она может быть прочитана от начала до конца, то с большой долей вероятности она не повреждена).
Nbackup (он же инкрементальный бэкап) – временно блокирует основной файл БД на запись (в консистентном состоянии), и позволяет быстро скопировать файл базы данных (полностью или частично/инкрементально).
Для больших БД Firebird (более 500Гб), предпочтительно делать nbackup, чтобы не тормозить работу пользователей, но при этом нужно проверять БД, ведь созданные неверифицированные бэкапы – это страничные копии БД, и если ошибка гнездится на уровне записей (такое случается из-за сбоя RAM) или на логическом уровне, то неверифицированный бэкап будет ее содержать так же, как и оригинальная БД.
Для этого нужно использовать онлайн-валидацию исходной базы данных (в Firebird начиная с версии 2.5.4 доступна онлайн-валидация при помощи gfix, а наш инструмент FBDataGuard поддерживает онлайн-проверку БД для версий 1.5-2.5).
Также, в дополнение к неверифицированному бэкапу желательно периодически (раз в неделю, например) делать верифицированный бэкап.
Для других СУБД необходимо использовать соответствующие средства и комбинации проверок.

8. Отсутствие контроля за свободным местом для бэкапа
В общем-то, это классическая ошибка — при недостатке места бэкап занимает все свободное место и аварийно завершается. При размещении бэкапа на одном диске вместе с БД может привести к остановке работы с БД, при размещении на системном диске – к поломке системы.
В комбинации с пунктом 4 в лучшем случае получим остановку работы системы, потому что базе данных тоже нужно свободное место, а оно кончилось из-за бэкапа.
А в комбинации с пунктами 5 и 2 опять получаем в результате отсутствие и базы, и бэкапа.
Рекомендации: использовать инструменты для бэкапа, которые делают прогноз размера бэкапа и предупреждают о возможной нехватке места.

9. Отсутствие контроля времени продолжительности бэкапа
Буквально полгода назад бэкап длился 40 минут, и вдруг стал 3 часа – почему? Возможно, вырос размер БД, а может быть, выпал диск из RAID-массива, отчего скорость записи резко деградировала, и все ваши бэкапы вот-вот покинут этот бренный мир. А может быть, добрый коллега одновременно включил еще одну систему резервного копирования (кстати, в Firebird можно запустить несколько бэкапов сразу, только не очень понятно, зачем это может быть нужно).
Если не контролировать время исполнения бэкапа, то можно проглядеть возникшую проблему и упустить шанс исправить ее до того, как она станет большой.
Также, в случае, если система резервного копирования не отслеживает состояния заданий, а запускает их просто по графику, легко можно попасть на «утренний троллейбус» — это когда новый бэкап может начаться в момент, пока предыдущий еще не закончился.
Рекомендации: использовать средства контроля продолжительности процесса бэкапа.

10. Исполнение бэкапа БД во время применения апдейтов ОС
Очень частая проблема, особенно в комбинации с п.9 и включенными автоматическими апдейтами Windows (которые по умолчанию происходят в 3 ночи). В лучшем случае приводит к замедлению процесса, а если ОС перегружается для применения апдейтов, то бэкап будет испорчен. Хорошо еще, что апдейты ОС не каждый день случаются.
Рекомендации: Если нельзя отключить, то назначьте апдейты ОС на такое время, когда они не смогут помешать бэкапам.

11. Бэкап базы данных средствами файлового бэкапа или средствами бэкапа виртуальной машины целиком, при включенном сервере БД
Многие администраторы забывают о том факте, что любая СУБД имеет активный и сложный кэш, в котором содержатся читаемые и записываемые данные, а сами файлы БД открываются в режиме случайного доступа.
Именно поэтому необходимо использовать специальные виды бэкапа, а не простой файловый бэкап (включая простое копирование файлов БД) или бэкап виртуальной машины. Файловые средства бэкапа читают БД последовательно и, особенно для больших БД, могут идти продолжительное время, поэтому нельзя гарантировать целостность созданной копии.
Для желающих осуществлять бэкап БД с помощью файловых средств или средств бэкапа виртуальных машин можно предложить 2 способа:

1. полностью выключать сервисы и процессы СУБД, чтобы ничего не находилось в кэше,
2. использовать агенты и/или скрипты, переводящие базы данных в специальный режим, когда копирование файла БД последовательным образом является безопасным.

Для Firebird необходимо блокировать основной файл БД с помощью nbackup до начала резервного копирования и разблокировать после окончания, для других СУБД есть аналогичные средства включения/выключение соответствующих режимов.

Кое-кто из администраторов БД убежден, что если в СУБД есть лог транзакций, то такую БД можно безопасно бэкапить стандартными файловыми средствами, в крайнем случае будет повреждение только этого лога. Это опасное заблуждение, которое не поддерживается производителями СУБД.

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

12. Подмена бэкапа репликацией
Бэкап и репликация данных служат повышению надежности и предотвращению потери данных, но все же существенно отличаются.
Все любят репликацию за способность синхронизировать данные на другом сервере с минимальном задержкой, однако и у бэкапа есть ряд неоспоримых преимуществ. Например, в случае случайного (или намеренного) удаления данных репликация быстро и невозмутимо оттранслирует изменения на реплику, а бэкап, особенно на read-only носителе, к таким операциям невосприимчив. Настроить правильную репликацию, как и правильный бэкап, стоит определенных усилий, и вероятность ошибок там также существует.
Рекомендации: Если у вас настроена репликация, не пренебрегайте бэкапами, используйте их совместно.

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

Ну, и конечно – не забывайте холить и лелеять свою админскую паранойю, например, возьмите и проверьте свои бэкапы… вот прямо сейчас!

Господа, просьба откликнуться в личку тех, кто использует CBT на VMWare для ВМ с БД.

Как исправить ошибки MS SQL и восстановить базу данных

Приглашаем разобраться в важных темах – устранения ошибок MS SQL и восстановления базы данных. Получите представление о разных способах устранения проблемы, которые следует использовать при различных обстоятельствах.

Восстановление баз данных

Специалисты пользуются несколькими способами восстановления баз данных (БД). Наиболее простой и удобный ­– воспользоваться программой (SSMS) SQL Server Management Studio.

Как восстановить

Узнать, где находится SQL Server Management Studio, довольно легко. Microsoft Windows Server 2012 R2 располагается в стандартном перечне программных продуктов. В Microsoft Windows Server 2008 R2 следует зайти в меню Пуск и отыскать Microsoft Windows Server 2012. Там смотреть Microsoft SQL Server Management Studio.

Далее следует ввести тип сервера с именем, а чтобы подтвердить подлинность – информацию, требуемую для прохождения авторизации. Нажать Соединить (Connect).

В левом углу из обозревателя (Object Explorer) раскрыть Базы данных (Server Objects). Из представленного перечня отобрать базу, подлежащую восстановлению либо ту, данные которой будут восстанавливаться. На выбранном файле кликнуть мышкой и в выпавшем перечне выбрать Задачи (Tasks), затем Восстановить (Restore), потом База данных… (Databases …).

Проделанные шаги дадут старт процессу Restore Database, а значит требуемая база данных начнет восстанавливаться. Следует сделать выбор источника для Restore Database.

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

1. Переключить соответствующую кнопку на Устройство (From device).
2. Прописать, откуда восстановится БД.
3. Выбрать инфобазу, в которую произведется загрузка данных (Destination for restore). Ею может выступать любая БД, которая регистрировалась на SQL Server (в том числе и база, с которой создавалась резервная копия).

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

Если требуется провести копирование БД, то во вкладке Файлы (Files) нужно будет прописать путь к файлам выбранной инфобазы.

Настройка дополнительных параметров

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

• Которая опубликована не на сервере, где она создавалась, сохранились настройки репликации, поможет отметка «Сохранить параметры репликации). Он важен, если при резервном копировании была реплицирована БД;
• была проведена перезапись файлов БД с именем, которое указывалось в качестве базы назначения – нужно поставить отметку «Перезаписать существующую базу данных»;
• сузить доступность к базе всем, кто не sysadmin, db_owner, dbcreator – нужно поставить флажок «Ограничение доступа к восстановленной базе данных»;
• старту должен предшествовать перевод БД в режим одного пользователя, а по его завершению вернуть в пользование для множества пользователей – поставить отметку «Закрыть существующие соединения»;
• чтобы провести требуемое резервное копирование завершающего фрагмента журнала транзакций, следует поставить отметку «Создание резервной копии заключительного фрагмента журнала перед восстановлением». Если в окошке Временная шкала резервного копирования (Backup Timeline) для временной точки требуется эта резервная копия, то отметка будет поставлена системой, без возможности снятия;
• чтобы после завершения восстановления каждой резервной копии уточнялась необходимость продолжения процесса – следует поставить отметку «Выдавать приглашение перед восстановлением каждой резервной копии» (Prompt before restoring each backup). Достаточно полезен, т.к. после того, как восстановлено определенное количество резервных копий можно остановить дальнейшую цепочку восстановительных процессов.

Настроив все важные параметры следует нажать ОК. Тем самым запустится процесс. Соответствующее уведомление сообщит об его окончании.

Восстановление базы в новое место

Чтобы перенести базу данных MSSQL Server по другому пути каталога либо сделать ее копию, следует знать, как восстановить БД в новую папку. Полезно знать как ее переименовывать. Для этого можно воспользоваться вышеупомянутой программой SSMS и T-SQL.

Подготовка к восстановлению базы данных

Перед стартом процесса восстановления нужно соблюдать ряд требований:

1. Когда осуществляется процесс восстановления базы, доступ к ней может быть только у системного администратора. Для остальных пользователей доступ должен быть ограничен.
2. Перед восстановлением нужно сделать резервную копию активного журнала транзакций.
3. Чтобы восстановить зашифрованную базу необходим доступ к сертификату либо ассиметричному ключу, который применялся в качестве ее шифратора. Не имея доступа к ним, восстановление зашифрованной БД становится невозможным. Потому, такой сертификат следует хранить, пока может понадобиться резервное копирование.

После того, как база данных версии SQL Server 2005 (9.x) либо более поздней, восстановится, произойдет автоматическое обновление, и она станет доступной.

Если присутствуют полнотекстовые индексы

В том случае, когда в БД SQL Server 2005 (9.x) присутствуют полнотекстовые индексы, в момент ее обновления произойдет импорт, сброс либо перестроение. Результат зависит от того, какое значение проставлено в свойствах сервера upgrade_option.

При обновлении такие индексы станут недоступны, если upgrade_option имеет значения:

• 2 в режиме импорта;
• 0 в режиме перестроения.

Продолжительность поцессов импорта и перестроения зависит от того, какой объем занимают данные. Импорт может длиться пару часов, а процесс перестроения – гораздо дольше (может продолжаться в 10 раз дольше).

В том случае, когда выбран процесс Импорт, а доступ к полнотекстовому каталогу отсутствует, то произойдет перестроение одноименных индексов, которые связаны с ним. Для изменения свойств upgrade_option необходимо воспользоваться процедурой sp_fulltext_service.

Соблюдение правил безопасности

Чтобы обезопасить себя, крайне не рекомендуется проводить присоединение либо восстановление БД, которые были получены из ненадежных или вовсе неизвестных источников. Они могут содержать вредоносные коды, способные:

• запускать выполнение инструкций T-SQL, не предусмотренных системой;
• вызывать ошибки в результате изменения схемы либо самой структуры БД

Если БД получена из источников, не внушающих доверия, то перед началом ее использования необходимо:

• протестировать по инструкции DBCC CHECKDB;
• исследовать исходный и иные коды БД, изучить процедуры.

Инструкции RESTORE

На ход реализации этих инструкций влияет факт существования восстанавливаемой базы. Если база:

• присутствует, то разрешения получают пользователи sysadmin, dbcreator, dbo (владелец БД) по умолчанию;
• отсутствует, то пользователям потребуются разрешения CREATE DATABASE.

Разрешения на реализацию таких инструкций выдаются в соответствии с ролями. В соответствии с ними сервер всегда имеет доступ к данным о членстве. Разрешение RESTORE отсутствует у пользователей с ролями db_owner. Причина в том, что членство может быть проверено лишь в тех случаях, когда к базе данных всегда есть доступ и она не повреждена. А это иногда не соблюдается в процессе выполнения инструкций RESTORES.

Пошаговая инструкция восстановления БД в новую папку в SSMS

1. Открыть SSMS и произвести подключение к SQL Server Database Engine.
2. Щелкнуть мышкой по имени сервера, чтобы развернулось его дерево.
3. Кликнуть мышкой на Базы данных, потом – по Восстановить базу данных.
4. В разделе Источник выбрать Общие, чтобы определить соответственное расположение и источник копий, подлежащих восстановлению. Пользователю предлагается выбрать нужный вариант (Базы данных либо Устройства). Особенности:
5. При выборе Базы данных открывается перечень БД, где можно выбрать нужную. В нем представлены лишь те базы, у которых резервные копии создавались по журналу msdb. Стоит отметить, что для БД на целевом сервере, резервные копии которых поступили с иных серверов, подобный журнал будет отсутствовать. В таких ситуациях следует выбирать вариант Устройство. Это позволит руками прописать файл, а в случае необходимости – обозначить устройство для выполнения восстановления.
6. Устройство можно выбрать, воспользовавшись кнопкой обзора (…). В результате появится окошко Выбор устройств резервного копирования. Перейти в окошко Тип носителя резервной копии, в котором из списка выбрать необходимый тип устройства. Если требуется добавить ряд устройств, это можно сделать с помощью кнопки Добавить в окошке Носитель резервной копии. Когда все необходимые устройства добавлены, необходимо вновь перейти на страницу Общие. Для этого следует нажать ОК в списке Носитель резервной копии. Обратившись к списку Источник: Устройство: База данных обозначить название БД, куда будет производиться восстановление. Пользователь может воспользоваться данным списком только при выборе Устройства. Можно выбирать лишь те БД, у которых на отобранном устройстве имеются резервные копии.
7. Название новой базы для проведения восстановления автоматом сформируется в поле База данных в разделе Назначение. При желании оно может быть изменено. Для этого желаемое название вводится в окошке База данных.
8. Далее перейти к Восстановить до. Пользователь может оставить значение До последней выбранной резервной копии (по умолчанию) либо кликнуть по Временной шкале. При выбре второго варианта всплывет соответствующее окошко Временная шкала …. В нем нужно указывать точное время.
9. Необходимые резервные копии для восстановления можно выбрать в соответствующей сетке. В ней отражены все наборы, доступные в выбранном месте. Система сама предложит план восстановления отобранных копий, который будет использован по умолчанию. Он может быть переопределен, если в сетке изменить отобранные элементы.
10. Для указания другого места расположения файлов базы, необходимо выбрать страницу Файлы после чего нажать на Переместить все файлы в папку. Следует указать вновь выбранное место расположения папок файлов данных и журнала.
11. Если возникла необходимость – провести настройку параметров, как было рассказано выше.

Чтобы начать процесс, в котором будет восстанавливаться БД в новую папку с возможностью переименовывать ее, можно воспользоваться инструкциями Transact-SQL.

Как просмотреть отчет

Стандартный отчет «События резервного копирования и восстановления» позволяет получить сведения о том, когда проводилось:

• Резервное копирование определенной БД;
• операции восстановления базы MS SQL из них.

Данный отчет включает данные, касающиеся создания резервных копий:

• время, затраченное на это в среднем (Average Time Taken For Backup Operations);
• операции, которые прошли успешно (Successful Backup Operations);
• ошибки, которые были допущены (Backup Operation Errors);
• удачно прошедших восстановлений баз (Successful Restore Operations).

Чтобы он начал формироваться, следует в Обозревателе объектов выбрать нужную БД и щелкнуть по ней мышкой. Выбрать в меню Отчеты, а затем – Стандартный отчет. После этого кликнуть на События резервного копирования и восстановления.

Чтобы просмотреть информацию из сформированного отчета следует выбрать нужную группировку и раскрыть данные по ней.

Для восстановления поврежденной БД можно воспользоваться еще одним инструментом.

Как исправить ошибки в MS SQL с помощью Recovery Toolbox for SQL Server

Для восстановления поврежденной базы данных можно обратиться к помощи Recovery Toolbox for SQL Server. Для исправления ошибки (Error), следует воспользоваться пошаговой инструкцией восстановления данных из файла *.mdf, который был поврежден. Для этого необходимо:

1. Скачать Recovery Toolbox for SQL Server.
2. Установить программу следуя инструкциям и запустить ее.
3. Из списка файлов выбрать файл *.mdf, который был поврежден.
4. Осуществить предварительный просмотр тех данных, которые в процессе выполнения программы могут быть подвергнуты извлечению из базы MS SQL сервер, которая подверглась повреждению.
5. Выбрать наиболее приемлемый способ, которым будут экспортироваться данные:
6. сохранением на диск в качестве SQL-скрипта;
7. выполнением SQL-скрипта в самой БД.
8. Произвести выборку информации, требующей восстановления и сохранения.
9. Начать восстановление нажатием Start recovery.

Данная программа создавалась, чтобы облегчить процесс восстановления поврежденных БД. Специально разработанная, оптимизированная для восстановления SQL Server, утилита поможет устранить ошибки и внести правки в разные типы повреждений *.mdf файлов и базы данных MS SQL Server.

Как становится понятно, для исправления ошибок и восстановления БД необходимо уметь пользоваться различными инструментами. Читайте, изучайте материалы по данной теме. Если возникнут вопросы – обязательно задавайте.

Инструкция по созданию/восстановлению резервных копий баз данных

Резервные копии рабочих баз данных, т.н. backup (бэкап), рекомендуется делать регулярно (на случай аппаратных и/или программных сбоев на сервере) с использованием планировщиков заданий, процесс настройки которых подробно описан в инструкциях по установке сетевых версий программ Альта-Софт (включая «Альта-ГТД»). Кроме того, в самой программе «Альта-ГТД» имеется функция, позволяющая создать резервную копию рабочей базы – см. меню Сервис/Бэкап БД SQL.

В процессе создания резервной копии «живая» база данных выгружается в файл на диск компьютера (на котором установлен SQL Server). В результате получается целостный файл, из которого в любой момент можно гарантированно восстановить базу данных до состояния, в котором она находилась на момент создания резервной копии. Причем по заверениям корпорации Microsoft резервную копию можно создавать даже во время активной работы пользователей с базой, однако «при прочих равных» мы рекомендуем делать копии, когда с базой никто не работает (хотя бы чтобы понимать в каком состоянии она находилась на момент копирования).

Перенос базы данных с одного SQL-сервера на другой также необходимо делать с помощью операций:

Создание резервной копии базы данных (backup)

1. Запустить утилиту SQL Server Management Studio (из состава MS SQL Server).
2. Подключиться к серверу под учетной записью администратора или владельца БД (можно использовать встроенную учетную запись «sa», пароль для которой задавался при установке SQL Server, либо выбрать вариант «Проверка подлинности Windows» в случае если текущий пользователь сеанса Windows обладает правами администратора в SQL Server, а также использовать любую другую учетную запись SQL Server или Windows, которая включена в роль «db_owner» копируемой базы):
3. Нажать правой кнопкой мыши на имени копируемой БД (в разделе «Базы данных») и выбрать меню «Задачи/Создать резервную копию»:
4. В разделе «Назначение» указать путь и имя файла (путь всегда задается для компьютера, где установлен сам SQL Server!), в который будет выгружена база данных, для чего использовать кнопки «Удалить» и «Добавить» до тех пор, пока в поле «Создать резервную копию на» не будет отображен ровно один желаемый путь:
5. На странице «Параметры» установить переключатель «Создать резервную копию в новом наборе носителей…» и галочку «Проверить резервную копию после завершения»:
6. Нажать кнопку «ОК».

Примечание. Резервные копии баз данных SQL Server обычно хорошо сжимаются архиваторами (WinRAR, WinZIP и т.п.), поэтому размер полученного файла (*.bak) можно сильно уменьшить с их помощью.

Восстановление базы данных из резервной копии (restore)

1. Запустить утилиту SQL Server Management Studio (из состава MS SQL Server).
2. Подключиться к серверу под учетной записью администратора или владельца БД (можно использовать встроенную учетную запись «sa», пароль для которой задавался при установке SQL Server, либо выбрать вариант «Проверка подлинности Windows» в случае если текущий пользователь сеанса Windows обладает правами администратора в SQL Server, а также использовать любую другую учетную запись SQL Server или Windows, которая включена в роль «db_owner» восстанавливаемой базы при наличии таковой или серверную роль «dbcreator»):
3. Нажать правой кнопкой мыши на разделе «Базы данных» и выбрать меню «Восстановить базу данных»:
4. На странице «Общие» выполнить следующие действия:
   • В поле «В базу данных» ввести имя для восстанавливаемой базы (если будет указано имя существующей базы, то это эквивалентно тому, что сначала полностью удалить существующую базу и затем восстановить из резервной копии новую базу, т.е. все данные существующей базы будут утеряны!);
   • Установить переключатель «С устройства» и указать путь к файлу резервной копии, нажав кнопку «…»;
   • Установить галочку «Восстановить» в нужной строке (которых может быть несколько, если один файл *.bak содержит несколько резервных копий базы):
5. На странице «Параметры» установить галочку «Перезаписать существующую базу данных» и проверить пути в списке «Восстановить файлы базы данных как» (должны указывать на существующую папку на SQL-сервере, к которой предоставлены права на запись – пути по умолчанию обычно должны заканчиваться папкой DATA, а не просто MSSQL):
6. Нажать кнопку «ОК».

Примечание. После восстановления базы данных на другой версии SQL Server (например, при переносе с SQL2005 на SQL2008) рекомендуется в свойствах базы данных переключить параметр «Уровень совместимости» на последнюю версию (см. страницу «Параметры» в свойствах БД).

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

Для переноса большого количества «имен входа» (логинов) с их паролями на новый сервер можно воспользоваться способом, описанным в статье базы знаний Microsoft. Однако, следует иметь в виду, что данный способ не переносит серверные права логинов (принадлежность «серверным ролям», право на «просмотр состояния сервера» и т.п.), а также не подходит для переноса с SQL 2012 на более ранние версии SQL Server.