Самодельный архиватор данных (09.04.2024).

Не получилось слезть с Python: в Qt не нашлась возможность отлавливать работу архиватора TAR в реальном времени. Выполняя os.system(sCommand), на чёрном терминале Linux показывается каждый обрабатываемый архиватором файл (не удалось сделать изменяющейся одну строку терминала - каждая строка появляется под предыдущей). Практика показала, что этот функционал необходим (например, удобство контроля работы утилиты), - даже с учётом засирания логов сервера. Python - отстой: это как раньше сайты на PHP в блокноте программировали - компилятора нет - ошибки видишь только в логе сервера (среда разработки Python v.3.2 для устаревшей Astra Linux v.1.4 не была найдена).

Для тестирования ядра утилиты (архиватора TAR и немного 7z) потребовалось 2 мощных ПК с жёсткими дисками по 2ТБ и 1 слабый ПК для фиксации всего и вся. 2ТБ пришлось из дома тащить, т.к. такие объёмы нужны были ещё в 2022 году - а до сих пор не дали (даже если заказать сейчас - ждать месяца 2). 2ТБ, на одном из ПК, оказалось мало - пришлось расширять до 3ТБ. Тестирование заняло 12 дней (с периодическим оставлением мощных ПК на ночь, в т.ч. на выходные), подготовка 2 ПК к состоянию "идентичный серверу заказчика" - 1 день (быстро: использовался слепок системы), подготовка информации к состоянию "превосходящая сервер заказчика" - 1 день. Так как мануал по архиваторам того времени скудный (man), приходилось тестировать как чёрный ящик - определяя граничные значения, которые заказчик точно никогда не превысит. Так как архиваторы в составе ОС не поддерживают многопоточность - пришлось разогнать первое ядро процессоров до 4.3ГГц и отключить все остальные ядра (ОС предательски может кинуть задачу на любой поток).

Вообще, функционал файла архивирования допиливался не столько из-за пожеланий заказчика, сколько из-за страховки в будущем от возникших ранее обвинений. Утилита должна быть нафарширована сообщениями, выдаваемыми избыточно на экран (т.е., и в логи сервера) - и кратко в отдельный файл в папке созданной группы архивов. В отдельный файл пишется:
- запускающий архивацию (теперь он будет крайним);
- выбранные пользователем опции и объекты архивирования;
- время начала архивации;
- результат проверки целостности каждого созданного архива сразу после его создания;
- контрольная сумма архива и каждой его составной части (если было разбиение);
- при отладке: время, затраченное на создание архива, объём архива;
- при окончании архивации - работы с самим файлом лога: записать время последнего изменения, присвоить атрибут "только чтение". В файл с расширением MD5, расположенный рядом с логом и одноимённый ему, записать объём файла и его контрольную сумму, присвоить атрибут "только чтение". Сделать копии этих двух файлов, скрыв от глаз пользователя (с точкой в начале файла).

Если архивируется БД SQL - она тоже должна быть сжата после выгрузки из postgresql и удалена (остался серьёзный вопрос: как проверить корректность самого снятия дампа). Её размеры могут быть чрезвычайно велики - перед созданием дампа нужно проверять наличие 32-40ГБ свободного места в /tmp (df -B1 --output=avail /tmp). Перед созданием каждого архива, требуется проверка наличия свободного места на диске, равного размеру сжимаемых данных (эмпирически выводится, исходя из свойств данных заказчика, - в моём случае это 1/2 от разжатых). Перед проверкой целостности архива - проверять свободное место на диске, равное трехкратному размеру архива (по-хорошему, нужно определять размер распаковываемых данных самим TAR). Строгий контроль удаления мусора, порождаемого утилитой.

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

Разное:
- требуется слежение за временем, вписываемым ОС в свойства создаваемых файлов. Был косяк, когда это время отличалось на 3ч от системного, - исправляется с помощью touch (sudo touch -t время_в_формате_%Y%m%d%H%M.%S путь_файла);
- опционально можно сделать выключение ПК после окончания архивации (sudo init 0);
- мало смысла останавливать утилиту архивирования, если какой-то из архивов оказался неисправен. Так как архивируется много всего, и может оставляться заказчиком на ночь, - есть смысл накапливать ошибки и вывести их в конце архивации (подкрашивая другим цветом: printf с ключами цвета - не echo).

Что из всего этого возьмёт на вооружение программист утилиты архивирования - его дело; но написанное выше можно считать обязательным к исполнению: заказчик точно больше до нас не докопается.

С утилитой разархивирования - дела обстоят иначе: она использует готовый продукт утилиты архивирования - и её совершенно не волнуют ни граничные значения данных заказчика, ни контрольные суммы архивов, ни информация в логе архивирования. Корректная логика её работы с каждым архивом не совсем проста:
- контроль свободного места в разархивируемом месте, согласно информации из архива (или фиксированный коэффициент, исходя из свойств архивируемых данных, - по сути, заимствуется из файла архивирования);
- защитить данные заказчика от самой себя, переименовав на диске текущую разархивируемую папку в "имя_tmp", если имеется;
- разархивировать архив в уже "несуществующую" разархивируемую папку назначения;
- если разархивирование корректно - убить папку "имя_tmp", если нет - уведомить, результаты разархивации удалить, восстановить название папки "имя_tmp" в исходное;
- если требуется выключать автоматом ПК после разархивирования - иметь свой собственный упрощённый лог разархивации: кто, когда, что выбрал, результаты распаковки каждого архива, итоговый результат разархивации.

Чтобы оттестировать утилиту разархивации - требуется анализ самих данных, а не их количества или свойств их обслуживающего функционала. Значит, требуется полная предсказуемость этих данных, с точностью до бита. Ранее программа "Генератор телеметрии" использовалась дважды: для имитации отсутствующего в реальности изделия, для имитации отсутствующего в реальности отдающего данные сервера. Для имитации данных заказчика бинарники не подходят - в ход идёт созданный в лохматых годах Генератор рэндомных файлов. Известно количество файлов, их названия, наполнение, контрольные суммы, контрольная сумма и название содержащей их папки. Играясь с создаваемыми данными и контрольными суммами - можно создать много вариантов тестирования данных до архивации и после разархивации.

Это - самая рутинная работа, поэтому она требует оптимизации и автоматизации:
- идентичность md5sum обрабатываемой директории, до архивации и после восстановления, - избавит от необходимости постоянно лазить внутрь папки и смотреть на файлы. diff идёт как дополнительный контроль правильности результата;
- идентичность md5sum "файла с md5sum файлов директории по отдельности", до архивации и после восстановления, - тот же эффект;
- добавление в начало утилиты и в её конец показа свободного места на диске в байтах - должно быть примерно похожим (сторонние программы в фоновом режиме тоже на диск пишут);
- тестирование идентичности данных алгоритмом "архивирование-восстановление-архивирование - всё архивированное должно быть дубликатами по содержимому-имени-размеру";
- рутинная проверка дампа SQL после восстановления - предварительно туда внеся много изменений в разные места. Использовать diff для оценки изменений в дампах, в т.ч. идентичности (работает быстро, требуется расширение терминала на 2 монитора для удобства сравнения большого количества полей).