Резервни копия
Важно
Резервните копия са отговорност на клиента и интеграторът може да помогне за разработването на стратегия за резервно копие, която да отговори на нуждите и средата на клиента.
Ежедневните резервни копия се извършват автоматично в полунощ и 2 часа сутринта за изследвания и MongoDB.
Базата данни и MongoDB са подкрепени от: \\server\Briefcam\ServerData\Backups..
Резервните файлове на RESEARCH се записват на\\server\Briefcam\ServerData\Backups\RESEARCH: ..
Резервни Копия За Системи С Висока Наличност И/Или Широкомащабни
За системи с висока активност най-добре е да планирате резервното копие, докато системата е неактивна (например през уикендите). Ако това не е възможно, репликацията на друг сървър е правилното решение.
В системи, където 24/7 обработка е конфигуриран, автоматичното резервно копие може да доведе до прекъсване на базата данни. За тези видове системи се препоръчва да се свържете с поддръжката BriefCamна компанията, за да изготвите стратегия за резервно копие, която отговаря на изискванията на клиентите.
Като цяло, при широкомащабни системи или когато системата работи 24 часа в денонощието, 7 дни в седмицата, е силно препоръчително да се настрои репликация и да се деактивират планираните задачи за автоматично резервно копие.
Препоръчително е да настроите друго резервно копие на друга машина или да копирате резервните копия на друга машина.
Компонентите, които трябва да бъдат архивирани, са:
Component | Какво да направите резервно копие | Метод на резервно копие |
PostgreSQL база данни | Дъмпинг на базата данни | Пусни |
Споделена папка на BriefCam – | Цялото пространство за съхранение, използвано от BriefCam | Огледало на диск, репликация, RAID конфигурация, външни резервни копия |
BI данни – | Файловете с данни на QLIK | Пусни |
MongoDB – само в мащабни среди | Петната за активиране на камерата | Свържете се с поддръжката на BriefCam |
Лицензионни данни | Файлът за активиране на лиценза | Файлът за активиране на лиценза |
Конфигуриране на файлове от бази данни |
| Резервно копие на файлове в друг сървър |
Балансиране на натоварването |
| Резервно копие на файлове в друг сървър |
IIS |
| Резервно копие на файлове в друг сървър |
Промяна на времето за архивиране
Планираните часове за архивиране могат да бъдат променени в планирането на задачи на Windows.
Щракнете двукратно върху задачата за архивиране.
Щракнете върху Редактиране.
Редактиране на графика.
Промяна на папката на RESEARCH Backup
За да смените местоположението на резервното копие на RESEARCH след инсталирането:
Отваряне на
BI_Backupпартида скрипт, който се намира в:BriefCamServer\scripts\db\backup\.Промяна на стойността на
BACKUP_PATHпараметъра.
Възстановяване на PostgreSQL Database Backup (Резервно копие за база данни)
Важно
Преди да възстановите базата данни, препоръчително е първо да се свържете с екипа за поддръжка на BriefCam.
От услугите на Windows спрете услугата VService.
За да възстановите базите данни (с изключение на BriefCam v6.4 HF3), изпълнете следните команди:
.\pg_dump.exe --no-password --verbose --blobs --format=c --file="<pg_dump_file.dump>" .\pg_restore.exe --verbose -d briefcam -U "<pg_superuser(dbadmin is the default)>" -h" <hostname>" -p <db port(5432)> "<pg_dump_file.dump>"Рестартирайте услугите.
Възстановяване На Резервните Копия На Базите Данни На Research Dashboard (Qlik)
Изпълнете планираната задача за архивиране.
Копирайте създадените файлове в сайта за миграция.
Стартирайте инсталиращата програма на модула ИЗСЛЕДВАНЕ (Research).
Спри всички услуги на Qlik.
Стартирайте само услугата за база данни на хранилището (услугата PostgreSQL).
Пуснете свежия PostgreSQL db:
dropdb -h localhost -p 4432 -U postgres QSRСъздайте нов PostgreSQL db:
createdb -h localhost -p 4432 -U postgres -T template0 QSRВъзстановява PostgreSQL db от резервните файлове:
pg_restore.exe -h localhost -p 4432 -U postgres -d QSR "c:\QSR_backup.tar"Копирайте папката за споделяне на приложения в папката за споделяне.
Стартирайте услугата за хранилище в режим на зареждане:
repository.exe -bootstrap -standalone -restorehostnameСлед като приключи, го стартирайте отново без -
restorehostname:repository.exe -bootstrap -standaloneВлизане в qmc с Firefox като <previous machine>\bcuser.
Актуализирайте ръчно собственика на всички връзки с данни на потребителя/паролата към,
<newmachine>\bcuserвключително паролата (12 връзки).Директно актуализиране на локалното BCUser да бъде RootAdmin в PostgreSQL db (table = users)
Актуализирайте директно потребителя в PostgreSQL:
<newmachine>\bcuser (table = ServiceClusterSettingsSharedPersistencePropertiesИзпълнете задачите за презареждане.
Възстановяване на MongoDB резервното копие
От услугите на Windows спрете услугата VService.
Убийте сесията, като изпълните командата Session Kill Run.
Възстановява базата данни, като изпълнява следната команда: PS> ./db-tool.exe recovery-mongodb --backup-path "{backup directory path}" --no-auth -y
Например: PS> ./db-tool.exe restore-mongodb --backup-path "d:\my\mongo\bak\briefcam_mongodb_backup_2022-03-31_09-52-37" --no-auth -y
Параметрите на командата са:
--Резервно копие-път | Път до директорията на резервното копие |
-- не-удостоверяване | Не използвайте удостоверяване. Понастоящем това е единствената опция. |
-Y, --Да | Потвърдете възстановяването. Ако това не бъде добавено, ще се появи потвърдено съобщение. |
Помощ | Показване на помощния текст и изход. |
Забележка:
Възстановяването работи само върху колекциите, които съществуват в конкретната директория за резервно копие.
Ако вече съществува колекция, която трябва да бъде възстановена, тя ще бъде заменена от резервната версия.
Индексите също са възстановени.