Первое - логин на Huawei по ssh ключу. И сразу это ввергло меня в поиск. То есть, в документации такая фича есть, но ключ он принимает только в HEX виде и никакие популярные команды преобразования, которые на раз гуглятся, не привели ключ в тот вид, чтобы его сожрал Huawei.

Сначала генерируем ключ на сервере (у меня хуавей принял только 1024 бита, но поскольку ssh открыт только с белого списка адресов, я сочла это приемлемым. вы же можете поэкспериментировать с битностью). На вопрос о парольной фразе просто нажмите enter.

ssh-keygen -f ~/.ssh/id_rsa -t rsa -b 1024

А теперь делаем магию. Я нашла нужную команду в самом конце комментов под заплюсованным ответом на stackoverflow. Команда из заплючованного ответа не работала и кто-то скромно написал, что не работает, но вот для моего хуавея делаю вот так и работает, тысяча плюсов в карму этому господину.

ssh-keygen -e -m pem -f ~/.ssh/id_rsa.pub | sed '1d;$d' | tr -d '\n' | base64 -d | xxd -c 24 -g 4 -u | sed -e "s/^.*: //" -e "s/.\{25\}$//g"

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

Дальше заводим ключ на Huawei. Ключ надо будет копировать в команды прямо так, как он вам вывелся на предыдущем этапе. На Huawei AR6120 команды следующие (если у вас белый список на логин по ssh не забудьте также разрешить ip вашего сервера логиниться):

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

На коммутатор Huawei S5735 команда чуть-чуть отличается, есть по ссылке в конце.

Для обращения к устройствам из скрипта я завела БД на sqlite, но вы можете брать информацию из текстовых файлов или ещё откуда. Поле пароля в базе будет пустым, оно оставлено для устройств, которые не поддерживают логин по ключу (вдруг такие будут)

Структура базы:

Вставка происходит примерно так:

`insert into netdev (hostname,ip,login,pass,tag,model) values ( 'ufa-ar6120-2', '10.2.100.2','backuper','','huawei','AR6120');`

Теперь про скрипт. И на цисках, и на микротиках, и на D-Link прекрасно работала следующая схема:

На хуавее же логин при такой схеме происходит, в логах это видно, но никакие команды, переданные таким способом, не выполняются. Никакие манипуляции c -i -T -t не работают. Я закопалась в процессе в логи ssh, в переменные окружения и прочее. Примерно понятно, что открытый терминал не считается терминалом и это даже нормально, но никакие опции, которые туда должны впихать команды, не работают. Моего скилла победить эту конструкцию не хватило. Пришлось использовать expect.
Кстати, если кто может нормально описать почему оно не работает и как это побеждать - будет здорово. А то я как собачка - вроде частично понимаю, а нормально написать не могу.

Всего использоваться будут 5 скриптов (напомню, код текстом по ссылке в конце).

Первый скрипт разбирает базу и запускает бэкап для каждого устройства в параллель.

Сначала у меня был один скрипт expect на все устройства (команды то одинаковые), но на коммутаторах он в 20% случаев не успевал с первой командой, так как на них очень-очень долгая загрузка после логина. А на роутерах наоборот, он завершался, не успев получить вывод от tftp и завершал сессию. Пришлось расставить костыли в виде sleep и разделить на два скрипта.

Для роутеров вот, для коммутаторов по ссылке в конце.

У Huawei и cisco немного по-разному сделан текущий конфиг.

Текущий конфиг (аналог running-config) по команде save сохраняется на Huawei в vrpcfg.zip. Как уже писалось выше, при попытке сохранять это по tftp/ftp это падает всегда zip архивом и при распаковке у конфига внутри архива всегда одно и тоже имя. То есть, на такие автоматические бэкапы всё равно надо накручивать скрипт распаковки и переименования. НО! Конфиг можно сохранить в текстовом виде с любым именем .cfg и уже его сливать.

Если вам нужно добавить дату - можно добавить её в имя конфига, который будет падать по tftp (чтоб на роутере память не занимать - там всегда сохраняем с одинаковым именем). Я не добавляю дату, так как всё падает в git, там версионность поддерживается и так.

Далее идет скрипт для оценки того, что у нас накопировалось - хочется понимать, что успешно, что нет. А также коммит, пуш и отсылка отчета на почту.

Зачем каждый раз выбирать ключ ssh? Huawei сожрал только 1024 бита, а gitea хотела минимум 2048. Так что пришлось завести два и менять - один для логина, другой для коммитов.

Теперь сам анализатор логов analyse_result. Он простой как валенок, тут ваша фантазия может разгуляться. Я просто смотрю что написано success на сохранении и на копировании. Заметьте, у роутеров и коммутаторов строчки вывода разные.

Я в таких вспомогательных скриптах придерживаюсь понятного стиля написания, не гоняясь за умещением всего в одну строчку (чтоб потом вспомнить, что там вообще было), так что стиль такой не просто так)

Ну и пихаем в cron чтоб выполнялся каждый день:

Изменения в Gitea выглядят примерно вот так

Сколько времени на это ушло? Ну вот столько:

9 дней работы от 30 минут до 3х часов в день или 19 коммитов. Больше всего я боролась с логином по ключу и с удаленным выполнением команд.

Весь код текстом тут.

Осталось раскатать это на 260 устройств :) Потом можно что угодно раскатывать сразу на все, используя эти наработки. Например, в планах составить рамочный access-list (он как бы есть, но слишком пошли различия от филиала к филиалу, хочется причесать). Ну а пока - залогиниться на каждое устройство ручками и вписать пользователя с ключом.

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

Понятное дело, сейчас Huawei такого типа (малый офис, скажем так) не очень распространены в РФ. Уже не домашний роутер, ещё не энтерпрайз. Однако, он завозится активно, а материалов хрен да нихрена. Надеюсь, кому-то когда-то пригодится.

Старая - Windows 7 x64 Домашняя базовая

Новая - Windows 10 x64 Домашняя

Видеокарта - Nvidia GeForce GTS 450

Ссылка - https://social.technet.microsoft.com/Forums/ru-RU/a328c253-4de9-4811-8086-b56b32cfcb35/1057108010891090107710841072?forum=ruwinserver2016

Дополнительная информация при необходимости

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

Программа тестировалась и усовершенствовалась на операционных системах Windows XP SP3, Windows Vista, Windows 8, Windows 8.1, Windows 10, Windows 11, а также соответствующих им серверных версиях, показала себя с лучшей стороны и не вызывает нареканий.

Системные требования:
- Windows XP SP3 (домашняя редакция не поддерживается из-за .NET Framework 4.0) и выше
- Windows Server 2003 SP2 и выше

Загрузить установочный файл (размер: 0,5 МБ): setup_eclatsoftversidoc_1.1.zip

Загрузить установочный файл (включает в себя библиотеку .NET Framework 4.0, размер: 50,3 МБ)  можно по ссылке: http://dl.eclatsoft.ru/files/setup_eclatsoftversidoc_1.1_dot4.zip

Отчёт VirusTotal: https://www.virustotal.com/gui/file/14054e3daeb597aa371aacffc66cbb06da574bbb111d0616cdb7a8bfdbbdc06b/detection

Ограничения данной версии: Версии любых файлов старше 7 дней автоматически удаляются, файлы в папке Документы затронуты не будут.

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

Методология бессмертия:

Объём:

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

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

- То, что вы не знаете что, надо не хранить, а разбирать - если вы в идеальном виде пронесёте сквозь десятилетия образ диска Цэ с вашего любимого ноута, где в глубинах каталогов есть бесценные файлики, там их потом никто не найдёт, предел срока жизни таких данных равен вашему сроку жизни, рабочий_ноут_диск-с.img 300ГБ выкинут на ваших похоронах.

- Хранить надо не программы, а данные*. На самом деле нет, но тут нюансы. В принципе программы относятся к легкоскачиваемому контенту и не требуют хранения по пункту 1. Кроме того работоспособный сетап из ОСи и прог, которым вы работаете со своими данными, попадает во вторую категорию и при попытке "сохранить всё!!!!!1111" вы только снизите шансы полезных данных на выживание. Но если в качестве единицы хранения вы для себя сформулировали фотоархив, то положить в папку с ним портейбл версию софта, в котором вы его ведёте, это практика, которая вам в будущем несколько упростит жизнь. (При условии, что вы как-то этот архив ведёте, а не просто сваливаете файлы в папки.) Может быть через тридцать лет формат например библиотеки лайтрума станет стандартом, как сейчас PDF, а может вы получите ситуацию как сейчас с видео в smk, заранее такое знать не дано.

- Сжатие дело хорошее, но не стоит возводить его в культ. Например 7zip с MFilter плагином поставят любой проц на колени, но сожмут джипеги процентов на 20, с точки зрения любого другого беспотерьного сжатия это феноменальный результат! Но с точки зрения архивного хранения за это надо гвоздь в голову вбить. Старообрядческого zip более чем достаточно. Вы не скажете себе (и мне) спасибо за этот выбор, вы просто не будете замечать тот геморрой, которого с ним избежали. Часто даже имеет смысл архивирование без сжатия - большинство современных форматов уже сжаты сами по себе внутри и зипование просто сложит их в единый, во многих случаях более удобный к хранению, файл. Сложность хранения в долгую представляет не объем файлов, а их количество. Именно количество файлов является множителем сложности хранения при плохой организации сокращения хранимого и его корректного именования и метаописания.

- Куда-то надо внести этот пункт, пусть в объёме будет. Не надо в процессе хранения контент пережимать с потерями в свеже выходящие форматы. Каждое такое пережатие будет ухудшать качество. Даже если несильно, то через несколько пережатий ухудшения накопятся. А если такую практику не пресечь сразу, то на одном пережатии вы вряд-ли остановитесь. Дёрнули когда-то видео с VHS в MPEG2, вот в нём пусть и лежит. От того, что оно станет в 4 раза меньше в H.265 ничего принципиально не изменится, если двадцать лет справлялись те пару гигов хранить, то и дальше справитесь.

Тезисы:

- Данные, существующие на единственном носителе, в долгосрочной перспективе можно сразу считать утерянными. Это не вопрос если, это вопрос когда.

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

- Стоит осознать возможные сценарии утраты данных и строить защиту от них.

- Сценарии утраты данных проще себе представить в категориях - софтварные, хардварные, природные (в смысле влияние окружающей среды, environmental)

- хардварные потери данных встречаются реже, чем софтварные, но чаще чем природные, исходя из этого нужно выбирать места хранения архивов

Нычки:

- Арендуем стойки в трёх датацентрах тир4 в разных концах света, ставим там ленточные роботизированные библиотеки и синхронизируем через квантовый спутниковый канал

- идеального сценария не будет, его универсального не существует в природе, но попробую описать подход в общих чертах, который можно было бы по месту подогнать напильником

айн

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

- ещё лучше будет, если эту сетевую шару вы не будете использовать как подключаемую букву диска, а только как таргет для программы бэкапера, стойкость к софтварным причинам потери данных в таком случае резко вырастает

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

- сетевая шара это удобно, но требует навыка создания и использования. если навыка нет, то пойдёт и usb hdd в тумбочке. в принципе пойдёт и любой другой съемный физический носитель, но usb универсальнее, а hdd стабильнее. важный момент - его нормальное состояние это отключённое. если он постоянно подключен к компу, то он подвержен всем напастям компа и местом бэкапа не считается.

- архив на первой линии должен быть свежим, регулярно обновляемым, может по событиям документогенерации, а может например еженедельно бэкапером по расписанию

цвай

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

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

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

драй

- кстати хуяк и пожар/ограбление/землетрясение/наводнение/военные действия

- с бумажными документами такое не прокатит, а вот данные можно обезопасить копированием

- если у вашей мамы, или вашего сына, или вашего лучшего друга будет лежать комплект болванок, или ещё один хард с копией бэкапа, то пожалуй это максимум безопасности данных, которого можно достичь в быту

- если при этом мама/сын/друг живут в другом городе/стране/планете, то актуальность бэкапа падает, но сохранность вырастает

- раз в год-то можно и свежих данных на хранение завезти

швайн

- облачные хранилища наверное надо упомянуть

- в трёхслойной обороне они ни один слой полноценно заменить не могут

- но за неимением горничной можно поиметь и дворника

- важно понимать, что любое облако это очень временно

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

Инструменты:

Эх, тут бы пообсуждать программы резервного копирования, но я уже выдохся, чукча не писатель. Скажу только, что для домашних (хоть и обширно задротских) нужд мне хватает бесплатного Veeam.