Резервиране на данни в общинската администрация

Резервирането на данни е тема, която засяга всяка общинска администрация — независимо от размера, бюджета или вида на използваните системи. В настоящия брой я разглеждаме на разбираем език: не само като задача на системния администратор, а като управленска гаранция, че администрацията ще може да продължи работа при срив, вирус, повреден сървър, грешно изтрита папка или неуспешна актуализация.

Основният въпрос не е просто „има ли backup“, а: какво точно се пази, къде се пази, колко назад може да се върне информацията и за колко време може да се възстанови работата.

Представете си следната ситуация

Понеделник сутрин. Служителите не могат да отворят деловодната система. Данъчната система не стартира. Споделените папки не се виждат. Оказва се, че сървърът е повреден или файловете са криптирани от вирус. В този момент най-важният въпрос не е кой е виновен, а дали има работещо резервно копие.

Backup-ът е като резервен ключ за сградата. Докато всичко работи, почти никой не мисли за него. Когато обаче основният ключ се изгуби, именно резервният ключ решава дали ще продължим работа, или ще спрем дейността на цялата администрация.

1. Backup ≠ Архивиране — две различни операции с различни цели

В общинската практика двата термина се използват взаимозаменяемо — и това е грешка с реални последствия.

Резервирането (backup) е като да направите копие на ключа и да го оставите у доверен съсед. Оригиналът остава при вас и продължавате да го ползвате. Ако се загуби, вземате копието и продължавате нормалната си работа. Backup-ът защитава от технически сривове — при проблем системата се възстановява бързо. Процесът е автоматизиран и се управлява от системния администратор.

Архивирането е друго нещо. То е като предаване на документи в архивното помещение — документите вече не са за ежедневна работа, а трябва да се пазят по определен ред и срок. При електронните документи това означава не просто „да стоят някъде“, а да са подредени, описани и придружени с нужните данни за тяхното търсене и доказване.

Мини речник на човешки език

Backup: резервно копие, от което можем да върнем данни при проблем.
Retention: колко дни назад пазим старите копия — например 30 дни.
Snapshot: снимка на цяла виртуална машина в конкретен момент.
Възстановяване: реалният тест дали копието може да върне системата, файл или база данни в работещо състояние.

Сравнение: Backup срещу Архивиране

Резервиране (Backup)	Архивиране
Данните остават в системата	Данните напускат оперативния достъп
Цел: бързо възстановяване при срив	Цел: дългосрочно съхранение по закон
Автоматизиран, непрекъснат процес	Изисква структура, метаданни, формат
Управлява го системният администратор	Управляват го архиварят и ИТ заедно

Какво трябва да направите

Проверете дали в администрацията ви съществува документирана процедура за резервиране — не само устна договорка с доставчиците на системи.
Определете ясен отговорник за всяка система — системният администратор или фирмата доставчик — и го запишете в договора или вътрешна заповед.
Не приемайте backup за архивиране. Backup защитава от сривове. Архивирането е нормативно задължение с различни изисквания — то ще бъде разгледано подробно в следващите броеве.

Препоръка: Backup е техническата основа — без него всяко говорене за архивиране е безсмислено. Осигурете работещото резервиране първо за всички системи.

2. Резервирането засяга всички системи — не само АИС

Честа грешка е резервирането да се разглежда само като задача, свързана с административната информационна система (АИС). В действителност всяка информационна система в общината, която обработва данни, трябва да има обезпечен backup — независимо дали е собственост на общината или се ползва като услуга от доставчик. Казано просто: ако системата е важна за ежедневната работа, тя трябва да може да бъде възстановена.

Административна информационна система (АИС)

АИС обикновено е инсталирана на виртуална машина (VM). Препоръчителна практика е седмично да се прави пълен образ (snapshot) — запазват се около 4 образа назад (≈ 1 месец покритие). Освен VM образа са необходими и ежедневни backup-и на файловете (сканирани документи, файлове от СЕОС/ССЕВ) и на базата данни, съдържаща метаданните. Без базата данни файловете са безполезни — нямат контекст.

Данъчна система, счетоводен и ТРЗ софтуер

Специализираните системи — местни данъци и такси, счетоводен и ТРЗ софтуер, системи за управление на общинска собственост — съдържат данни с висока чувствителност. Изискват ежедневен backup на базата данни и конфигурационните файлове. При SaaS решения проверете изрично в договора кой носи отговорност за backup и каква е гарантираната честота и период на съхранение.

В договорите с доставчици е добре да се посочат не само честотата на резервиране, но и RPO — колко данни може да бъдат загубени при срив, и RTO — за колко време системата трябва да бъде възстановена. Без тези две величини backup-ът остава общо обещание, а не управляем процес.

Активна директория (Active Directory)

Активната директория е централната система за управление на потребителски акаунти, права и политики в мрежата. Загубата й при срив означава невъзможност за вход в системите за всички служители. Регулярният backup на AD е критично важен и често пропускан. Препоръчително: седмичен пълен backup и ежедневен инкрементален.

Файлови сървъри

Споделените папки, сканираните документи и работните файлове изискват ежедневен backup с минимален retention период от 30 дни. Инкременталният подход е подходящ — записва се само промяната от предишния ден, което пести значително дисково пространство.

Какво трябва да направите

Направете инвентаризация на всички системи в общината и проверете дали за всяка съществува ясна, документирана backup процедура с посочен отговорник.
При SaaS и облачни системи поискайте писмено потвърждение за честотата на backup, retention периода и процедурата за възстановяване — преди подновяване на договора.
Не пропускайте активната директория — тя е невидима до момента на срив, но последствията от загубата й са незабавни и засягат целия персонал.

Важно: Снимка на VM образа е добра практика преди всяка значима актуализация на система — осигурява бързо връщане назад при проблем. Тествайте реалното възстановяване поне веднъж на три месеца за всяка критична система.

3. Правило 3-2-1: три копия, два носителя, едно извън обекта

Retention период и инкрементален backup

Retention период е времето, за което резервните копия се пазят, преди да бъдат автоматично изтрити. При 30-дневен retention backup-ът от преди 30 дни се изтрива при създаването на нов. Изборът на период е баланс между разходи за съхранение и необходимия буфер за реакция — достатъчно дълъг, за да се открие проблем, достатъчно кратък, за да не се злоупотребява с ресурси.

Инкременталният backup записва само промените от последния backup, а не целия обем данни. В понеделник — пълен backup (100 GB). Вторник — само новите файлове (2 GB). Сряда — само промените от вторник (1,5 GB). Спестява значително място и ускорява процеса. При възстановяване са нужни пълният backup плюс всички последващи инкрементални копия.

Локации на съхранение

Правило 3-2-1 е утвърден стандарт: 3 копия на данните, на 2 различни носителя, като 1 е извън физическия обект на администрацията. Офлайн копие защитава от ransomware атаки, при които онлайн копията могат да бъдат криптирани заедно с оригинала. При облачно съхранение е задължително криптиране на данните.

Какво трябва да направите

Проверете дали резервните копия се пазят на поне две физически различни локации. Ако всичко е само на локалния сървър — при пожар, наводнение или кражба губите данни и backup едновременно.
Планирайте тест на реалното възстановяване поне веднъж на три месеца за всяка критична система.
Документирайте процедурата — кой прави backup, кога, на каква локация, кой отговаря при срив. Устната договорка не е достатъчна.

Правило за запомняне: 3-2-1 — три копия, два различни носителя, едно извън обекта. Прилага се еднакво за АИС, данъчна система, счетоводен софтуер, активна директория и файлови сървъри.

4. RPO, RTO, логове и тестово възстановяване

Всяка критична система трябва да има предварително определени граници за възстановяване. За хора без ИТ опит най-лесният начин да се разбере е чрез два въпроса:

RPO (Recovery Point Objective): „Колко информация можем да си позволим да загубим?“ Ако backup-ът е веднъж дневно, при срив може да се загуби работата от последния ден.
RTO (Recovery Time Objective): „Колко време можем да си позволим системата да не работи?“ За деловодството това може да са няколко часа, а за по-малко критична система — повече.

Контрол, логове и известяване

Не е достатъчно backup задачата да е „настроена“. Необходимо е да има известяване при неуспешен backup, периодичен преглед на логовете и лице, което потвърждава, че процесът реално се изпълнява. При ransomware сценарий администрацията трябва да знае дали разполага с офлайн, отделено или неизменяемо копие, което не може да бъде криптирано заедно с основните данни.

Минимален тестов сценарий

Поне веднъж на тримесечие е добре да се прави тестово възстановяване в контролирана среда: възстановяване на файл, база данни или виртуална машина; проверка дали приложението стартира; проверка дали потребителите могат да влязат; записване на резултата в кратък протокол. Това е доказателството, че backup-ът не е само наличен, а използваем.

Какво трябва да направите

Определете за всяка критична система допустима загуба на данни (RPO) и допустимо време за възстановяване (RTO).
Настройте известяване при неуспешен backup и изисквайте периодичен отчет от системния администратор или доставчика.
Съхранявайте кратки протоколи от тестово възстановяване — дата, система, какво е възстановено, резултат и отговорник.

Практическо правило: Backup, който никога не е възстановяван тестово, е само предположение. За администрацията важният резултат не е наличието на файл с копие, а възможността работата да бъде възстановена в приемлив срок.

5. Най-честите грешки, които изглеждат дребни — докато не стане инцидент

Чести грешки

Backup има, но никой не знае кога последно е бил успешен.
Копието се пази на същия сървър, който трябва да защити.
Разчита се само на доставчика, без писмено описание на процедурата.
Никога не е правено тестово възстановяване.

Въпроси, които управителят трябва да може да получи отговор на

Кои системи се резервират и кои не?
Колко често се правят копията и колко дни назад се пазят?
Къде се пази копието — в сградата, извън сградата или в облак?
Ако утре сървърът изгори, след колко време ще работим отново?

Най-простият управленски тест: Поискайте на един лист да бъде описано за всяка важна система: кой я поддържа, къде е backup-ът, колко назад се пази, кой получава известие при грешка и кога последно е правено възстановяване. Ако този лист не може да се попълни — процедурата не е достатъчно ясна.

6. Архивирането в общинската администрация — нормативната рамка предстои

Наредбата за реда за организирането, обработването, експертизата, съхранението и използването на документите в учрежденските архиви на държавните и общинските институции изисква електронните документи да се архивират структурирано — не само да се натрупват в системата. Прилагат се същите архивни срокове като за хартиените документи. Метаданните трябва да са неотделими от документа.

На практика в повечето АИС липсва модул за архивен export — документите просто се натрупват в системата, а файловете и метаданните им стоят на различни места. Това разминаване между нормативното изискване и техническата реалност е тема, която заслужава самостоятелен и подробен анализ.

В следващите броеве ще разгледаме подробно нормативните изисквания за архивиране — видове архивиране, задължителни формати (PDF/A и XML метаданни), срокове по категории документи и отговорности.
За сега: задайте въпроса към доставчика на АИС писмено — планира ли модул за архивен export в стандартен формат и в какъв срок.

7. NAS устройства, виртуализация и AI автоматизация — практически инструменти

Съвременните подходи за резервиране вече не се ограничават до копиране на файлове върху външен диск. При работа с деловодни системи, виртуални сървъри, бази данни и електронни регистри е важно да се мисли не само за „копие“, а и за бързо възстановяване на работоспособността.

NAS устройства — достъпен вариант за общини

Все повече администрации използват NAS устройства (Network Attached Storage) — специализирани мрежови системи за съхранение и архивиране. Те осигуряват автоматични резервни копия по график, съхранение на няколко версии на файловете, защита при повреда на диск чрез RAID технологии, отделен backup на виртуални машини, синхронизация към второ устройство или облак, и централизирано място за архиви. Подобни решения са значително по-достъпни от изграждането на класическа backup инфраструктура — за малки и средни администрации NAS с правилна конфигурация е добра първа стъпка.

Виртуализация — възстановяване на цели сървъри

При платформи за виртуализация като Proxmox VE, VMware vSphere или Microsoft Hyper-V резервирането може да се извършва на ниво виртуална машина, а не само на отделни файлове. При срив се възстановява целият сървър заедно с операционната система, инсталирания софтуер, настройките, базите данни и потребителските конфигурации. Тези системи поддържат snapshot копия, инкрементални backup-и, репликация към друг сървър и дори стартиране на виртуалната машина директно от архива — което значително намалява времето за възстановяване след срив или криптовирус.

AI и автоматизация на резервните копия

Изкуственият интелект вече се използва и при автоматизацията на backup процесите. Чрез AI инструменти могат да се генерират PowerShell скриптове, Python автоматизации, rsync задачи и автоматични известия по имейл при грешка. Задачите се изпълняват чрез Windows Task Scheduler, cron задачи при Linux или вградени scheduler механизми. В практиката все по-ефективна е комбинацията от безплатен backup софтуер, NAS устройство, виртуализация и AI-генерирани скриптове — така дори с ограничен бюджет може да се изгради надеждна стратегия за резервиране.

Препоръка: Изборът на инструменти зависи от бюджета и инфраструктурата. Не е нужно всичко наведнъж — дори NAS устройство с правилна конфигурация е значителна стъпка напред. Важното е документирана процедура, тествано възстановяване и ясен отговорник за всяка система.

Повечето администрации разбират колко важен е backup-ът едва след инцидент. Добрата практика е това да се случи преди проблема, а не след него. Резервното копие не е просто техническа задача — то е гаранция, че администрацията ще може да продължи работа при срив, атака или човешка грешка.