Резервно копие и възстановяване

Приложението се казва „Ticket System Backup & Restore“. То стои до системата за заявки и има собствена икона на работния плот.

Има версия за Windows и версия за Linux. Това е едно и също приложение, само построено за всяка операционна система.

То има шест раздела. „Restore“ изброява наличните резервни копия, „Create Backup“ прави ново, „Schedule“ урежда времето, „Encryption“ показва ключа за възстановяване, „Settings“ показва пътищата, а „Log“ — протокола.

Настройките вече са попълнени. При първото си стартиране приложението само установява къде живее системата за заявки.

Папката за резервните копия стои под „Backup directory“. Можете да я промените, например към друго устройство.

На Windows приложението иска администраторски права, когато се стартира. Настройките му важат за всеки администратор на компютъра и живеят в „%ProgramData%\SMITEY\backup-app“.

Инсталацията сама настройва ежедневното резервно копие. То се изпълнява в 23:00 в часовата зона на системата за заявки.

Графикът живее в операционната система. На Windows това е Task Scheduler, на Linux — услугата cron. Затова не работи допълнителна услуга само заради резервните копия.

Резервното копие не изисква някой да е влязъл. На сървър, на който никой никога не влиза, то пак се изпълнява.

Редът под бутоните ви казва дали задачата наистина съществува в операционната система. Поставената отметка казва само какво е било запазено.

Резервните копия се пазят на пет степени: 14 дни, 4 седмици, 12 месеца, 4 тримесечия и 5 години. Едно резервно копие остава, докато е най-новото за своя период в някоя от тези степени.

Броят се календарни дни, а не файлове. Две резервни копия в един ден са един ден.

Резервните копия, които създавате на ръка, никога не се изтриват автоматично. Точно това означава 0 при „Keep manual“.

Ако промените графика, промяната ви преживява обновяване. Инсталацията го задава само ако никога не сте задавали график. Ако сте изключили резервното копиране, то остава изключено. „Remove all scheduled tasks“ също трае: след това обновяването не настройва графика отново.

Резервното копие съдържа всичко, което съставя състоянието на вашата система. Това са базата данни, прикачените файлове, архивът и ключовете. Липсва само база данни извън SMITEY.

Ключовете са частта, която лесно се пропуска. Те разшифроват запазените данни за достъп, например тези на вашия пощенски профил. Без тях възстановяването би се върнало с мъртви данни за достъп.

Всяко ново резервно копие е един-единствен шифрован файл с окончание „.smbk“. Той съдържа по един файл за всеки том, списък на съдържанието си и базата данни като текстов файл, ако е включена.

Системата продължава да работи, докато това се случва. Вашите оператори изобщо не забелязват резервното копие.

„Estimate size“ ви казва предварително колко голяма е базата данни. Томовете с прикачените файлове се добавят към нея. Резервното копие не се компресира.

Нищо никога не се презаписва. Всяко резервно копие е отделен файл и само почистването премахва старите.

Само администратори могат да четат резервните копия. Същото важи за конфигурационния файл и за файла с първия вход в папката на инсталацията. Инсталаторът и всяко обновяване задават тези права сами.

Ако базата ви данни работи на собствен сървър, а не в контейнера на SMITEY, приложението не може да я запази. Запазете я тогава със собствени инструменти. В този случай резервното копие съдържа само прикачените файлове, архивите и ключовете, шифровани както обикновено. Обновяването открива такава база данни само и превключва приложението. Дотогава ежедневното резервно копие при такава инсталация не успява, освен ако първо не превключите на ръка. В командния ред можете да го направите и на ръка с „config --database external“. С „config --database bundled“ превключвате обратно.

Всяко ново резервно копие е шифровано. Това важи за копията по график, за ръчно направените и за копията преди обновяване. Не е нужно да включвате нищо.

Резервните копия се шифроват с AES-256. Инсталацията създава ключа сама. При съществуваща инсталация той се създава с първото обновяване до версия с шифроване. Съхранява се защитен на сървъра. Само администраторите могат да го прочетат.

Това защитава копията извън сървъра. Който намери резервно копие на мрежов диск, на USB стик или в онлайн хранилище, не може да го прочете без ключа. Който контролира самия сървър, има и ключа.

Ключът за възстановяване е същият ключ във вид, който можете да запишете. Започва с „SMBK-“. Ще го намерите в раздела „Encryption“ и във файла „SMITEY-credentials.txt“ в папката на инсталацията. Ако сте изтрили този файл, ключът пак е в раздела „Encryption“.

„Copy“ слага ключа в клипборда. „Save to file...“ го записва с идентификатора на ключа и датата в текстов файл. Съхранете го например в мениджър на пароли или на хартия в сейф.

Докато не потвърдите, че ключът е запазен, приложението показва жълта лента най-горе. За да потвърдите, щракнете „I stored the key outside this server“ и отговорете на въпроса с „Yes“. Лентата изчезва. След това разделът показва кога сте потвърдили.

Идентификаторът на ключа показва към кой сървър принадлежи резервното копие. Ако резервно копие не принадлежи към този сървър, приложението назовава идентификатора на неговия ключ. След това иска подходящия ключ за възстановяване.

Ако приложението не може да прочете ключа, не прави резервно копие. Не прави и нешифровано. В този случай разделът „Encryption“ казва, че ключът не може да се прочете. Ако файлът с ключа липсва изцяло, следващото резервно копие създава нов ключ. Жълтата лента се появява отново, защото и новият ключ трябва да се съхрани. По-старите резервни копия могат да се отварят само със стария ключ за възстановяване.

По-старите резервни копия във формат ZIP не са шифровани. Все още можете да ги възстановите. Разделът показва колко са. Почистването ги премахва по същите правила като всяко друго резервно копие.

На сървър без работен плот „key --show“ показва същото в командния ред.

В раздела „Restore“ избирате резервното копие, което искате обратно. После щраквате върху „Restore“.

Приложението първо пита. То казва какво ще стане: днешното състояние се презаписва, а приложението рестартира контейнерите. Ако в днешното състояние има анонимизирани хора, следва втори въпрос. Той посочва броя им и пита дали да бъдат анонимизирани отново след възстановяването. „Yes“ е избрано предварително. С „No“ копието се възстановява без тази стъпка. Ако вместо това затворите прозореца, нищо не се възстановява.

Отметката „Wipe target volumes before restore“ първо изпразва томовете. Така не остава файл, който не е съществувал при създаването на резервното копие.

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

Ако резервното копие съдържа базата данни, пълното състояние се връща. Заявките, коментарите, историята, прикачените файлове, отчетеното време и базата знания са отново налице такива, каквито са били в момента на резервното копие.

След това системата отново е използваема. При малка инсталация това отнема по-малко от минута.

Ако резервното копие съдържа базата данни, тя се връща изцяло или изобщо не. Томовете следват след нея. Ако някой том не успее, базата данни вече е върната, но може да липсват файлове; разделът „Log“ показва коя стъпка не е успяла. Във всеки случай приложението след това стартира контейнерите отново, дори ако възстановяването не е успяло.

Резервно копие от по-стара версия може да бъде възстановено в по-нова. При следващото си стартиране системата привежда базата данни до своята версия.

Съгласията и отписванията за проучването за удовлетвореност се пренасят без въпрос. Това важи и ако отговорите „No“ на втория въпрос. Приложението ги чете от работещата инсталация преди възстановяването. След това ред в раздела „Log“ дава броя, например „12 consent and unsubscribe record(s) were carried over.“ Системата за заявки ги поема при първото си стартиране. Съгласие или отписване, направено след резервното копие, затова остава валидно. Ако пренасянето не успее, журналът показва предупреждение. Възстановяването все пак се брои за успешно.

Приложението първо проверява напълно шифрованото резервно копие. През това време редът за състоянието показва „Checking the encrypted backup before anything is changed...“. Едва след това спира контейнерите. Ако файлът е повреден или е променян, то спира и съобщава „The backup file is damaged. Nothing was changed.“

Ако резервното копие идва от друг сървър, приложението иска ключа за възстановяване на този сървър. Това става след въпросите. Прозорецът „Recovery key needed“ назовава идентификатора на ключа на резервното копие. Същият прозорец се появява, ако ключът на този сървър липсва.

Грешка при въвеждането се забелязва, преди да е променено каквото и да е. Тогава редът за състоянието съобщава „The recovery key has a typing error. Check each character.“ След това прозорецът пита отново. Ако ключът принадлежи на друго резервно копие, редът за състоянието съобщава „This recovery key does not belong to this backup.“ С „Cancel“ приложението спира и съобщава „Restore cancelled. Nothing was changed.“

Приложението не приема въведения от вас ключ. То запазва своя. Новите резервни копия все още се правят с ключа на този сървър. Ако възстановявате на нов сървър, запазете и ключа за възстановяване на този сървър.

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

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

Сървърът често няма работен плот. Затова същото приложение работи и като команда.

Пет команди са ви нужни всеки ден: „backup“ запазва, „list“ показва наличните резервни копия, „restore“ връща едно обратно, „schedule“ задава времето, а „config“ показва настройките. За ключа се добавят „key“ и „decrypt“.

Зад тях стои същото приложение както в прозореца. Няма втори път, който да прави нещо друго.

Приложението стои в „/opt/smitey/Backup“. Извиквате го със „sudo“ и добавяте командата. Контейнерите работят като „root“, затова и резервното копие се нуждае от тези права.

Можете да копирате шестте кутии отдолу. Те покриват това, което наистина е нужно в ежедневието.

Възстановяването и тук пита. То се изпълнява само когато добавите „--yes“. Тогава то пренася и анонимизациите от днешното състояние, както „Yes“ в прозореца. С „--no-reapply“ то се изпълнява без тази стъпка.

На сървъра има файл, в който можете да прочетете всичко това. Той се казва „BACKUP-RESTORE.txt“ и стои в „/opt/smitey“. Той минава още веднъж през графика, всяка команда и пътя назад, със собствено темпо. Той съществува на немски и на английски: ако при инсталирането сте избрали немски, получавате немския, иначе английския. И двете версии стоят също под „/opt/smitey/docs“.

„key --show“ показва ключа за възстановяване, идентификатора на ключа и броя на нешифрованите резервни копия. Щом ключът е запазен извън сървъра, го потвърждавате с „key --confirm-stored“.

Резервно копие от друг сървър възстановявате с „--key-file“. Файлът, който посочвате, съдържа ключа за възстановяване. Файлът от „Save to file...“ също върши работа. Вместо файла можете да ползвате и променливата на средата „SMITEY_BACKUP_KEY“. С „sudo“ я поставяте директно пред програмата, тоест „sudo SMITEY_BACKUP_KEY=<ключ> /opt/smitey/Backup/TicketSystemBackup restore …“. Тогава ключът попада в историята на обвивката. Ако ключът не пасва, нищо не се променя.

„decrypt“ записва съдържанието на резервно копие като нешифровани файлове в празна папка. Тези файлове не са шифровани. Те съдържат пароли и лични данни. Изтрийте ги, щом приключите.

Резервните копия са файлове в папката, която сте задали. Тази папка е на същата машина като системата за заявки.

За обичайните случаи това работи добре. Изтрити по погрешка данни, обновяване, което се е объркало, или грешка в данните са покрити.

То не помага срещу отказ на диска. Ако дискът го няма, резервните копия ги няма заедно с него.

Затова копирайте файловете другаде. Мрежов диск, втори сървър или хранилище в мрежата са достатъчни.

Копиран файл може да бъде зареден обратно на всеки сървър. На друг сървър за това ви трябва ключът за възстановяване. С „Import backup file…“ връщате файла в списъка.

Копията са шифровани. Никой не може да ги прочете без ключа за възстановяване. Затова не пазете ключа до копията. По-старите резервни копия с окончание „.zip“ не са шифровани.

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

То запазва същото както винаги: базата данни, прикачените файлове, архивите и ключовете. Ако базата данни работи извън SMITEY, обновяването запазва само прикачените файлове, архивите и ключовете.

Това резервно копие се прави от приложението „Ticket System Backup & Restore“. То е шифровано като всяко друго и стои в същата папка. В списъка видът му е „Update“. Трите най-нови такива резервни копия се пазят. По-старите приложението изтрива само.

Съобщението преди обновяването ви го казва. Не е нужно сами да помните да запазите първо.

Ако това резервно копие не успее, обновяването спира, преди да бъде заменено каквото и да е. Базата данни извън SMITEY не задържа обновяването. Тогава обновяването превключва приложението така, че ежедневното резервно копие също да пропуска базата данни. Запазете тази база данни със собствени инструменти.