# Основы резервного копирования

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

Платформа состоит из следующих компонентов, перечисленных с указанием путей установки по умолчанию:

### Приложение

Backend:

* /home/java/api-server
* /home/java/sms-server
* /home/java/tcp-server

Frontend:

* /var/www/panel-v2
* /var/www/pro-ui

### База данных

Следующие базы данных MySQL используются Navixy:

* google
* tracking

Если ваша платформа Navixy работает на виртуальной машине в облачной платформе, вы можете периодически создавать снимки (snapshots) машины и дополнительно выполнять дамп MySQL. Создание дампа необходимо для поддержания согласованности базы данных. Дополнительную информацию о mysqldump можно найти здесь:

<https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html>

Базы данных "google" и "tracking" должны быть включены в резервное копирование. Вы можете создать дамп MySQL на работающей базе данных без блокировки таблиц и прерывания сервиса, используя `--single-transaction` опцию.

Если вы запускаете Navixy на физическом сервере, вы можете сделать резервную копию компонентов один раз после установки, а затем после каждого обновления платформы, чтобы всегда иметь актуальную версию backend и frontend. После этого необходимо лишь периодически создавать резервные копии базы данных с помощью дампа MySQL.

Ниже приведен пример bash-скрипта, который создаёт дампы MySQL обеих баз данных, пропускает их через gzip для уменьшения размера, затем удаляет все резервные копии в каталоге резервных копий старше 1 года. Не стесняйтесь изменять скрипт в соответствии с вашими потребностями.

{% code overflow="wrap" %}

```bash
#!/bin/bash

bak_dir=/home/navixy-backups
sql_user=root
sql_passwd=rootpasswd
now=$(date +"%Y-%m-%d")

mysqldump -u$sql_user -p$sql_passwd --single-transaction google | gzip > $bak_dir/google-bak-$now.sql.gz
mysqldump -u$sql_user -p$sql_passwd --single-transaction tracking | gzip > $bak_dir/tracking-bak-$now.sql.gz

find $bak_dir -maxdepth 1 -type f \( -name "google-bak-*.sql.gz" -o -name "tracking-bak-*.sql.gz" \) -mtime +365 -delete
```

{% endcode %}

{% hint style="info" %}
Вы также можете использовать сторонние решения для резервного копирования MySQL, например: <https://www.percona.com/doc/percona-xtrabackup/LATEST/index.html>. Это проверенное рабочее решение, предоставляющее расширенные возможности резервного копирования баз данных. Оно успешно тестируется и используется многими системными инженерами On-premise. Для ознакомления с рекомендуемой Navixy практикой резервного копирования MySQL обратитесь к [этой странице](https://www.navixy.com/docs/on-premise/ru/on-premise/how-to-guide/maintenance/backup/mysql-backup).
{% endhint %}

## Резервное копирование лицензионного ключа

При планировании резервного копирования платформы Navixy важно учитывать лицензионный ключ. Ключ (также известный как fingerprint) обновляется на нашем лицензионном сервере примерно раз в неделю. Это означает, что если вы восстановите резервную копию, сделанную до последнего обновления ключа, платформа не будет работать, и вам потребуется обратиться в нашу техническую поддержку для получения нового ключа.

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

```sql
SELECT value FROM google.variables WHERE var='fingerprint';
```

Результат представляет собой простую текстовую строку, которую можно сохранить в файл или в другую базу данных. Рекомендуем выполнять резервное копирование ключа как минимум 2–3 раза в день.

Если вам пришлось восстановить платформу из резервной копии, достаточно записать ключ обратно в базу данных, перезапустить сервисы, и платформа должна начать работать:

```sql
UPDATE google.variables SET value='<your_key>' WHERE var='fingerprint';
```