Резервная копия личного ассистента — это точка, где надёжность и приватность прямо противоречат друг другу. Копия на том же диске не переживёт отказ этого диска. Копия в облачном хранилище переживёт что угодно и одновременно отменит всё, ради чего вы держали данные у себя: архив окажется на чужом сервере, только теперь целиком и одним файлом.
Компромисс существует, но он требует принять одну вещь: копия — это второй экземпляр всех ваших данных, и защищать её надо как первый.
#Что понадобится
- Понимание, что именно копируется. Снимок базы ассистента — это не «настройки», а вся переписка, память, распознанный с экрана текст и хранящиеся в базе секреты одним файлом.
- Внешний носитель либо второе место хранения. Копия рядом с оригиналом не является копией в смысле надёжности.
- Пароль для шифрования копии, записанный в менеджер паролей.
- Полчаса на первую настройку и час раз в полгода на проверку восстановления.
#Что попадает в снимок
Прежде чем выбирать схему, полезно понять объём проблемы. В снимок базы попадает всё, что в ней лежит:
- сообщения всех чатов и извлечённые факты памяти;
- распознанный с экрана текст и метаданные снимков;
- заметки, граф связей, настройки;
- секреты в открытом виде — ключи API и токены ботов, которые в базе не зашифрованы.
Последний пункт — причина, по которой снимок нельзя раздавать. У экземпляра с несколькими участниками он содержит ключи каждого из них. Именно поэтому снимок базы в Persona доступен только владельцу экземпляра и намеренно закрыт участникам: он инстанс-глобальный по своей природе, отфильтровать его «по пользователю» нельзя. Участнику вместо этого доступна выгрузка только своих данных, где вместо значений ключей стоит отметка о наличии и длина.
#Таблица: шесть схем и их риски
Смотреть надо на две правые колонки вместе. Схема, у которой обе оценки высокие, встречается ровно одна — и она же самая трудоёмкая.
| Схема | Приватность | Надёжность | Главный риск |
|---|---|---|---|
| Копия на том же диске | Высокая | Низкая | Отказ диска уносит и оригинал, и копию |
| Внешний диск, лежит дома | Высокая | Средняя | Пожар, залив, кража забирают оба носителя |
| Внешний диск, хранится в другом месте | Высокая | Высокая | Копия устаревает: её надо возить и обновлять |
| Облачное хранилище без шифрования | Низкая | Высокая | Полный архив у стороннего сервиса одним файлом |
| Облачное хранилище с шифрованием у себя | Средняя | Высокая | Забытый пароль — потеря копии; метаданные видны хранилищу |
| Свой сервер или сетевое хранилище дома | Высокая | Средняя | Та же квартира, та же розетка, та же сеть |
Вывод: строка «облачное хранилище без шифрования» — это отказ от локальности, оформленный как забота о надёжности. Если вы держите данные у себя ради приватности, а копию кладёте в чужое облако открытым файлом, приватность закончилась — просто в менее заметном месте.
Рабочий компромисс — комбинация: одна копия рядом для быстрого восстановления, одна копия в другом физическом месте, и если используется облако — только с шифрованием, выполненным до отправки.
#Шаг 1. Снимайте копию правильным способом
Файл базы SQLite нельзя просто копировать «на живую»: приложение может писать в него в момент копирования, и вы получите повреждённый файл или копию без последних записей. Правильный способ — штатная операция снимка, которая делает согласованную копию.
Проверяемый признак: снимок, снятый корректно, открывается без ошибок и содержит записи вплоть до момента снятия. Техническая сторона разобрана в гайде по резервному копированию и восстановлению SQLite.
#Шаг 2. Зашифруйте копию до того, как она куда-то уедет
Порядок именно такой: сначала шифрование, потом перемещение. Копия, побывавшая в облачной папке в открытом виде хотя бы на минуту, считается ушедшей.
Шифруйте архивом с паролем или средствами шифрования тома на внешнем носителе. Требование к паролю — длина; функция выведения ключа делает перебор дорогим, но короткий пароль не спасает. Что именно защищает шифрование, а что нет, разобрано в статье про шифрование данных ассистента, а хранение самого пароля — в гайде про хранилище под паролем.
#Шаг 3. Разнесите копии физически
Правило трёх копий, которым пользуются уже несколько десятилетий: три экземпляра данных, на двух разных типах носителей, один — вне вашего помещения. Для домашнего сценария это обычно выглядит так: рабочая база на ноутбуке, копия на внешнем диске дома, зашифрованная копия у родственника или в облаке.
Ключевой пункт — третий. Копия на внешнем диске в том же ящике стола защищает от отказа диска и не защищает от всего, что случается с квартирой целиком.
#Шаг 4. Ограничьте срок жизни копий
Копии живут дольше оригинала, и это одновременно их достоинство и их проблема. Удалили факт из базы — он остаётся в каждой копии, сделанной до удаления, пока эта копия существует.
Практическое решение — ротация с известной глубиной: держать, например, последние несколько ежедневных и несколько ежемесячных копий, остальные удалять. Тогда на вопрос «когда удалённые данные исчезнут окончательно» есть конкретный ответ, а не «когда-нибудь».
#Проверка результата: восстановление, а не наличие файла
Резервная копия, которую ни разу не восстанавливали, — это предположение о резервной копии. Проверка делается раз в полгода и занимает час.
- Скопируйте архив на отдельный носитель или в отдельный каталог. Никогда не восстанавливайте поверх рабочей базы: неудачное восстановление уничтожит и её.
- Расшифруйте и распакуйте. Уже на этом шаге выясняется половина проблем: забытый пароль, повреждённый архив, неполная выгрузка.
- Откройте базу и проверьте дату последней записи. Она должна соответствовать моменту снятия копии, а не быть на месяц старше.
- Выполните поиск по знакомому фрагменту. Полнотекстовый индекс должен работать: если поиск ничего не находит, а записи на месте, индекс не попал в копию.
- Проверьте, что зашифрованные записи открываются тем паролем, который у вас есть. Копия, из которой не открывается защищённый контур, восстанавливает не всё.
- Удалите тестовое восстановление. Оставленная расшифрованная копия — это второй незащищённый архив.
Успешный результат: копия распаковалась, база открылась, дата свежая, поиск работает, защищённые записи читаются.
#Что может пойти не так
Копия делалась «на живую». Файл получился повреждённым, и выяснится это в момент, когда копия понадобилась.
Пароль от архива не записан. Та же ловушка, что и с зашифрованными заметками: восстановления нет. Записывайте до первого шифрования.
Копия уехала в облако до шифрования. Порядок операций здесь важнее самого шифрования.
Копий много, но все в одном месте. Десять снимков на том же диске защищают от вашей ошибки и не защищают от отказа диска.
Восстановление проверялось поверх рабочей базы. Единственная ошибка в этом гайде, которая может стоить вам всех данных сразу.
Забыли про переезд. Перенос экземпляра на другой диск или машину — отдельная процедура, и делать её через резервную копию не всегда правильно; порядок описан в гайде про перенос экземпляра на другой диск.
#Частые вопросы
#Можно ли просто синхронизировать папку с базой в облачное хранилище?
Технически можно, практически плохо по двум причинам. Файл базы меняется постоянно, и синхронизация будет заливать его целиком снова и снова, иногда — в несогласованном состоянии. И это ровно та схема, где полный архив оказывается у стороннего сервиса в открытом виде. Правильнее делать снимок, шифровать его и загружать уже архив.
#Чем резервная копия отличается от экспорта памяти?
Назначением. Копия — это точный снимок для восстановления работы, включая служебные структуры. Экспорт — переносимый набор данных, обычно в читаемом формате, для переезда или анализа. Копия не подойдёт для переноса в другой продукт, экспорт не подойдёт для восстановления после отказа диска. Про второе — в статье про экспорт и перенос памяти ИИ.
#Нужно ли шифровать копию, если внешний диск лежит дома?
Да. Диск теряют, у диска меняют владельца, диск сдают в ремонт. Шифрование внешнего носителя стоит одной операции при первой настройке и снимает весь этот класс ситуаций.
#Что делать с копиями при запросе на удаление данных?
Обычно от оператора не требуют вскрывать каждый архив, но требуют не восстанавливать удалённое и дать копиям выйти из ротации. Поэтому известная глубина ротации — это и есть ваш ответ на вопрос «когда данные исчезнут окончательно».
#Насколько часто снимать копию?
По цене потери: сколько работы вы готовы потерять. Для личного ассистента с ежедневным использованием разумный ориентир — ежедневный снимок с ротацией и еженедельный вынос копии в другое место. Для эпизодического использования достаточно еженедельного.
#Меняется ли что-то, если я работаю на чужом экземпляре?
Существенно: копии делает владелец экземпляра, они содержат данные всех участников, и вы на них не влияете. Ваш инструмент — самостоятельная выгрузка своих данных, которую надо забирать самому и хранить у себя. Общая рамка того, что где лежит, — в статье про приватный ИИ и локальное хранение.
#Вывод
Минимум, который закрывает большинство сценариев: ежедневный снимок штатным способом, шифрование до перемещения, одна копия вне вашего помещения и проверка восстановления раз в полгода. Если вы держите данные локально ради приватности — не сливайте эту приватность обратно незашифрованным архивом в облачной папке. А если восстановление ни разу не проверялось, считайте, что копий у вас нет: файл на диске и работающая резервная копия — разные вещи, и разницу между ними обнаруживают в худший момент.