Понял!

Хочу добавить, что если ваш Cloud Key перестал отвечать, но вы всё ещё можете подключиться к нему через ssh, можно вручную извлечь резервную копию.

Путь к файлу:
./srv/unifi/data/backup/

Учтите, что этот файл в бинарном формате. Для подключения и скачивания понадобится SFTP.

Кроме того, есть вероятность, что хоть контроллер и офлайн, программное обеспечение Cloud Key всё ещё доступно через браузер. Там можно попытаться сбросить CK, перезапустить контроллер и восстановить резервную копию. Но если у вас нет файла UNF, сначала его нужно получить.

Нет SFTP под рукой, а надо скопировать UNF-файл? Есть небольшой лайфхак.

root@UniFi-CloudKey:/# ls /srv/unifi/data/backup  
5.5.24.unf  5.6.22.unf  meta.json

root@UniFi-CloudKey:/# cp /srv/unifi/data/backup/5.6.22.unf /usr/share/cloudkey-webui/www/config.unf

Если открыть в браузере http://[IP_CLOUDKEY]/config.unf — начнётся скачивание вашей конфигурации.

После этого можно сбросить Cloud Key к заводским настройкам:  
/sbin/ubnt-systool reset2defaults

Подождите около минуты, затем зайдите в браузере на IP-адрес Cloud Key и восстановите всё с помощью только что скачанного файла конфигурации UNF.

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

Ты вообще можешь получить доступ к cloud key? Если скопировать папку Unifi с cloud key на другой компьютер, а потом запустить установщик Unifi поверх этой папки, можно как-то оживить контроллер, чтобы сделать резервную копию. Эту копию потом можно использовать для восстановления на другом cloud key или контроллере.

Это решило мою проблему. Как только я переместил или удалил эти самые файлы размером 0, индикатор загорелся синим, и я смог войти в систему как обычно. Спасибо!

Дата в каком файле? Я совсем не понимаю ssh, но могу открыть putty и зайти в свой cloud key. Какие шаги нужно сделать, чтобы проверить дату файла?

Как проверить, какая версия резервной копии самая свежая? Я знаю, что она у меня есть, но нервничаю, потому что не вижу, когда была сделана последняя. Мне нужно всего несколько правил переадресации портов из конфигурации, и я не хочу их потерять — они всего около месяца назад создавались.

Похоже, у меня такая же проблема. Что нужно сделать, чтобы это исправить?

Как я уже говорил, я тоже думал, что проблемы с CK связаны напрямую с перебоями с питанием. Но после того, как я переконфигурировал пострадавшие CK, больше не могу восстановить эту проблему. Единственная разница, которую вижу между твоей и моей ситуацией — это то, что я не знал, что можно решить через ssh. Я пошёл по жёсткому пути и сделал полную перенастройку с нуля. Резервных копий не было, пришлось вручную сбрасывать каждую точку доступа. Возможно, именно в этом и дело. Ты пытался исправить ситуацию частично и, наверное, застрял на каких-то поломанных файлах, а я начал с чистого листа. Может, остались какие-то хвосты, из-за которых твои CK стали более уязвимы к сбоям при отключении питания. Обновление прошивки или программного обеспечения контроллера может не убрать эти остатки. Просто моё мнение...

Странно, что у тебя до сих пор эта проблема с последними прошивками. Несколько месяцев назад у меня были похожие неприятности, но я их решил, поставив ИБП на CK, плюс установил более новые прошивки. После этого проблема больше не появлялась. Сейчас я "мучаю" несколько CK — в том числе те, что раньше падали — подключая их к обычной электросети, отключая от ИБП. Условия разные: некоторые за USG, некоторые — нет, версии прошивок разные — 5.2.x, 5.3.x и бета 5.4.x. Некоторые CK сильно загружены (+20 UAP, +200 клиентов), другие — всего пару UAP и немного клиентов. У меня накопилось пару сотен отключений питания, и ни один из CK не сдался. Я полагал, что это благодаря новым прошивкам, но твоя ситуация показывает, что дело может быть не в этом.