mirror of
https://github.com/YunoHost/doc.git
synced 2024-09-03 20:06:26 +02:00
Merge pull request #1727 from YunoHost/enh-backup
[enh] Add a lot of details about backup in fr page
This commit is contained in:
ljf (zamentur)
GitHub
commit
dbbb5c85b6
24 changed files with 1387 additions and 179 deletions
BIN
images/administrate/specific_use_cases/virtualbox-snapshot.jpg
Normal file
BIN
images/administrate/specific_use_cases/virtualbox-snapshot.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 68 KiB |
BIN
images/administrate/specific_use_cases/virtualbox-snapshot2.webp
Normal file
BIN
images/administrate/specific_use_cases/virtualbox-snapshot2.webp
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 16 KiB |
BIN
images/administrate/specific_use_cases/virtualbox-snapshot3.webp
Normal file
BIN
images/administrate/specific_use_cases/virtualbox-snapshot3.webp
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 14 KiB |
BIN
images/administrate/specific_use_cases/virtualbox-snapshot4.webp
Normal file
BIN
images/administrate/specific_use_cases/virtualbox-snapshot4.webp
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 21 KiB |
|
|
@ -1,31 +1,39 @@
|
|||
---
|
||||
title: Sauvegarder son serveur et ses apps
|
||||
title: Sauvegarder son serveur
|
||||
template: docs
|
||||
taxonomy:
|
||||
category: docs
|
||||
routes:
|
||||
default: '/backup'
|
||||
page-toc:
|
||||
active: true
|
||||
depth: 3
|
||||
---
|
||||
|
||||
Dans le contexte de l'auto-hébergement, les sauvegardes (backups) sont un élément important pour pallier les événements inattendus (incendies, corruption de base de données, perte d'accès au serveur, serveur compromis...). La politique de sauvegardes à mettre en place dépend de l'importance des services et des données que vous gérez. Par exemple, sauvegarder un serveur de test aura peu d'intérêt, tandis que vous voudrez être très prudent si vous gérez des données critiques pour une association ou une entreprise - et dans ce genre de cas, vous souhaiterez stocker les sauvegardes *dans un endroit différent*.
|
||||
|
||||
## Les sauvegardes avec YunoHost
|
||||
## Sauvegarde manuelle
|
||||
|
||||
### Sauvegarder
|
||||
|
||||
YunoHost contient un système de sauvegarde, qui permet de sauvegarder (et restaurer) les configurations du système, les données « système » (comme les mails) et les applications si elles le supportent.
|
||||
|
||||
Vous pouvez gérer vos sauvegardes via la ligne de commande (`yunohost backup --help`) ou la webadmin (dans la section Sauvegardes) bien que certaines fonctionnalités ne soient pas disponibles via celle-ci.
|
||||
|
||||
La méthode de sauvegarde actuelle consiste à créer des archives `.tar.gz` qui contiennent les fichiers pertinents. Pour le futur, YunoHost envisage de supporter nativement [Borg](https://www.borgbackup.org/) qui est une solution plus flexible, performante et puissante pour gérer des sauvegardes.
|
||||
La méthode de sauvegarde actuelle consiste à créer des archives `.tar` qui contiennent les fichiers pertinents.
|
||||
|
||||
## Créer des sauvegardes
|
||||
#### Créer une sauvegarde
|
||||
|
||||
#### Depuis la webadmin
|
||||
[ui-tabs position="top-left" active="0" theme="lite"]
|
||||
[ui-tab title="À partir de l'interface web"]
|
||||
|
||||
Vous pouvez facilement créer des archives depuis la webadmin en allant dans Sauvegardes > Archives locales et en cliquant sur "Nouvelle sauvegarde". Vous pourrez ensuite sélectionner les éléments à sauvegarder (configuration, données « système », applications).
|
||||
Vous pouvez facilement créer des archives depuis la webadmin en allant dans `Sauvegardes > Archives locales` et en cliquant sur `Nouvelle sauvegarde`. Vous pourrez ensuite sélectionner les éléments à sauvegarder (configuration, données "système", applications).
|
||||
|
||||
|
||||
|
||||
#### Depuis la ligne de commande
|
||||
|
||||
|
||||
[/ui-tab]
|
||||
[ui-tab title="À partir de la ligne de commande"]
|
||||
|
||||
Vous pouvez créer de nouvelles archives depuis la ligne de commande. Voici quelques exemples de commandes et leur comportement correspondant :
|
||||
|
||||
|
|
@ -56,118 +64,109 @@ yunohost backup create --system data_mail --apps wordpress
|
|||
|
||||
Pour plus d'informations et d'options sur la création d'archives, consultez `yunohost backup create --help`. Vous pouvez également lister les parties du système qui sont sauvegardables avec `yunohost hook list backup`.
|
||||
|
||||
#### Configuration spécifique à certaines apps
|
||||
[/ui-tab]
|
||||
[/ui-tabs]
|
||||
|
||||
Certaines apps comme Nextcloud sont potentiellement rattachées à des quantités importantes de données. Il est possible de ne pas les sauvegarder par défaut. Dans ce cas, on dit que l'app « sauvegarde uniquement le core » (de l'app).
|
||||
Lors d'une mise à jour, les apps contenant une grande quantité de données effectuent généralement une sauvegarde sans ces données.
|
||||
#### Télécharger la sauvegarde
|
||||
[ui-tabs position="top-left" active="0" theme="lite"]
|
||||
[ui-tab title="À partir de l'interface web"]
|
||||
Après avoir créé des sauvegardes, il est possible de les lister et de les inspecter grâce aux vues correspondantes dans l'interface d'administration web. Un bouton propose de télécharger l'archive. Si l'archive fait plus de 3Go, il peut être préférable de procéder via SFTP.
|
||||
|
||||
Pour désactiver manuellement la sauvegarde des données volumineuses, pour les applications qui implémentent cette fonctionnalité, vous pouvez définir la variable `BACKUP_CORE_ONLY`. Pour ce faire, la variable doit être définie avant la commande de backup : `sudo BACKUP_CORE_ONLY=1 yunohost backup create --apps nextcloud`. Soyez prudent : il vous faudra alors sauvegarder vous-même les données des utilisateurs de Nextcloud. Choisir ce type de sauvegarde vous permettra de mettre en place manuellement des sauvegardes incrémentielles ou différentielles (que YunoHost ne permet pas encore de faire automatiquement).
|
||||
`Sauvegarde > Archives locales > <Nom de l'archive> > Télécharger`
|
||||
|
||||
## Télécharger et téléverser des sauvegardes
|
||||
[/ui-tab]
|
||||
[ui-tab title="Via un client SFTP"]
|
||||
À l'heure actuelle, la solution la plus accessible pour récupérer les sauvegardes de grosse taille est d'utiliser le programme FileZilla comme expliqué dans [cette page](/filezilla).
|
||||
|
||||
Après avoir créé des sauvegardes, il est possible de les lister et de les inspecter grâce aux vues correspondantes dans la webadmin, ou via `yunohost backup list` et `yunohost backup info <nom_d'archive>` depuis la ligne de commande. Par défaut, les sauvegardes sont stockées dans `/home/yunohost.backup/archives/`.
|
||||
Par défaut, les sauvegardes sont stockées dans `/home/yunohost.backup/archives/`.
|
||||
|
||||
À l'heure actuelle, la solution la plus accessible pour récupérer les sauvegardes est d'utiliser le programme FileZilla comme expliqué dans [cette page](/filezilla).
|
||||
[/ui-tab]
|
||||
[ui-tab title="À partir de la ligne de commande"]
|
||||
Les commandes `yunohost backup list` et `yunohost backup info <nom_d'archive>` permettent d'obtenir des infiormations sur les noms et tailles des sauvegardes.
|
||||
|
||||
Une autre solution alternative consiste à installer une application comme Nextcloud et à la configurer pour être en mesure d'accéder aux fichiers dans `/home/yunohost.backup/archives/` depuis un navigateur web.
|
||||
|
||||
Enfin, il est possible d'utiliser `scp` (un programme basé sur [`ssh`](/ssh)) pour copier des fichiers entre deux machines grâce à la ligne de commande. Ainsi, depuis une machine sous GNU/Linux, vous pouvez utiliser la commande suivante pour télécharger une archive :
|
||||
Il est possible d'utiliser `scp` (un programme basé sur [`ssh`](/ssh)) pour copier des fichiers entre deux machines grâce à la ligne de commande. Ainsi, depuis une machine sous GNU/Linux, vous pouvez utiliser la commande suivante pour télécharger une archive :
|
||||
|
||||
```bash
|
||||
scp admin@votre.domaine.tld:/home/yunohost.backup/archives/<nom_darchive>.tar.gz ./
|
||||
```
|
||||
[/ui-tab]
|
||||
[/ui-tabs]
|
||||
|
||||
De façon similaire, vous pouvez téléverser une sauvegarde depuis une machine vers votre serveur avec :
|
||||
! N'oubliez pas de stocker votre sauvegarde dans un lieu différents de celui ou se trouve votre serveur.
|
||||
|
||||
|
||||
!!! Si vous le souhaitez, vous pouvez connecter un disque externe à votre serveur pour que les archives arrivent directement dessus. Voir ce guide pour [Ajouter un stockage externe à son serveur](/external_storage)
|
||||
|
||||
|
||||
|
||||
### Tester
|
||||
|
||||
Vous devriez tester régulièrement vos sauvegardes à minima en listant le contenu des archives et en vérifiant le poids des données associées. Le mieux est de s'entrainer règulièrement à restaurer.
|
||||
```bash
|
||||
scp /path/to/your/<nom_darchive>.tar.gz admin@votre.domaine.tld:/home/yunohost.backup/archives/
|
||||
# Lister les fichiers
|
||||
tar -tvf /home/yunohost.backup/archives/ARCHIVE.tar | less
|
||||
|
||||
# Lister les exports de base de données
|
||||
tar -tvf /home/yunohost.backup/archives/ARCHIVE.tar | grep "(db|dump)\.sql"
|
||||
|
||||
# Vérifier le poids
|
||||
ls -lh /home/yunohost.backup/archives/ARCHIVE.tar
|
||||
```
|
||||
|
||||
## Restaurer des sauvegardes
|
||||
### Restaurer
|
||||
|
||||
#### Depuis la webadmin
|
||||
!!! SPOILER: Plus votre volume de données et le nombre d'applications sont important, plus votre restauration sera complexe.
|
||||
#### Cas simple : peu de données, archive déjà présente
|
||||
|
||||
Allez dans Sauvegardes > Sauvegardes locales et sélectionnez l'archive. Vous pouvez ensuite choisir les différents éléments que vous voulez restaurer puis cliquer sur "Restaurer".
|
||||
[ui-tabs position="top-left" active="0" theme="lite"]
|
||||
[ui-tab title="À partir de l'interface web"]
|
||||
|
||||
Allez dans `Sauvegardes > Archives locales` et sélectionnez l'archive. Vous pouvez ensuite choisir les différents éléments que vous voulez restaurer puis cliquer sur "Restaurer".
|
||||
|
||||
|
||||
|
||||
#### Depuis la ligne de commande
|
||||
|
||||
Depuis la ligne de commande, vous pouvez utiliser `yunohost backup restore <nom_d'archive>` (sans le `.tar.gz`) pour restaurer une archive. Tout comme `yunohost backup create`, cela restaure tout le contenu par défaut. Si vous souhaitez restaurer seulement certaines parties, vous pouvez utiliser par exemple `yunohost backup restore --apps wordpress` qui restaurera seulement l'app WordPress.
|
||||
[/ui-tab]
|
||||
[ui-tab title="À partir de la ligne de commande"]
|
||||
Depuis la ligne de commande, vous pouvez utiliser `yunohost backup restore <nom_d'archive>` (sans le `.tar`) pour restaurer une archive. Tout comme `yunohost backup create`, cela restaure tout le contenu par défaut. Si vous souhaitez restaurer seulement certaines parties, vous pouvez utiliser par exemple `yunohost backup restore --apps wordpress` qui restaurera seulement l'app WordPress.
|
||||
|
||||
#### Contraintes
|
||||
!!! Dans le cas d'une restauration complète, il est possible de restaurer à la place de lancer la configuration initiale.
|
||||
[/ui-tab]
|
||||
[/ui-tabs]
|
||||
|
||||
Pour restaurer une application, le domaine sur laquelle elle est installée doit déjà être configuré (ou il vous faut restaurer en même temps la configuration correspondante). Aussi, il n'est pas possible de restaurer une application déjà installée... ce qui veut dire que pour restaurer une sauvegarde d'une app, il vous faut déjà la désinstaller.
|
||||
|
||||
#### Restauration d'une archive à la place de la post-installation
|
||||
#### Téléverser une archive
|
||||
Dans de nombreux cas, l'archive n'est pas sur le serveur sur lequel on souhaite la restaurer. Il faut donc la téléverser, ce qui selon son poids peut prend plus ou moins de temps.
|
||||
|
||||
Une fonctionnalité particulière est la possibilité de restaurer une archive entière *à la place* de faire la post-installation. Ceci est utile pour réinstaller un système entièrement à partir d'une sauvegarde existante. Pour faire cela, il vous faudra d'abord téléverser l'archive sur le serveur et la placer dans `/home/yunohost.backup/archives`.
|
||||
[ui-tabs position="top-left" active="0" theme="lite"]
|
||||
[ui-tab title="Via un client SFTP"]
|
||||
À l'heure actuelle, la solution la plus accessible pour téléverser les sauvegardes est d'utiliser le programme FileZilla comme expliqué dans [cette page](/filezilla).
|
||||
|
||||
Ensuite, **à la place de** `yunohost tools postinstall`, réalisez la restauration de l'archive téléversée par cette ligne de commande avec le nom de l'archive (sans le `.tar.gz`) :
|
||||
Par défaut, les sauvegardes sont à placer dans `/home/yunohost.backup/archives/`.
|
||||
[/ui-tab]
|
||||
[ui-tab title="À partir de la ligne de commande"]
|
||||
Vous pouvez téléverser une sauvegarde depuis une machine vers votre serveur avec :
|
||||
|
||||
```bash
|
||||
yunohost backup restore <nom_darchive>
|
||||
scp /path/to/your/<nom_d'archive>.tar.gz admin@your.domain.tld:/home/yunohost.backup/archives/
|
||||
```
|
||||
[/ui-tab]
|
||||
[/ui-tabs]
|
||||
|
||||
Note: si votre archive n'est pas dans `/home/yunohost.backup/archives`, vous pouvez créer le répertoire et déplacer l'archive comme ceci :
|
||||
## Sauvegarde automatique ou distante
|
||||
|
||||
```bash
|
||||
mkdir -p /home/yunohost.backup/archives
|
||||
mv /chemin/vers/<nom_darchive> /home/yunohost.backup/archives/
|
||||
yunohost backup restore <nom_darchive>
|
||||
```
|
||||
Il existe 3 applications YunoHost qui proposent d'étendre YunoHost avec une méthode de sauvegarde automatisées.
|
||||
|
||||
## Pour aller plus loin
|
||||
* [BorgBackup](/backup/borgbackup)
|
||||
* [Restic](/backup/restic)
|
||||
* [Archivist](/backup/archivist)
|
||||
|
||||
#### Stocker les archives sur un autre disque
|
||||
## Aller plus loin
|
||||
|
||||
Si vous le souhaitez, vous pouvez connecter un disque externe à votre serveur pour (parmi d'autres choses) stocker les archives de backup dessus. Pour cela, il faut d'abord déplacer les archives existantes vers le disque, puis créer un lien symbolique:
|
||||
|
||||
```bash
|
||||
PATH_TO_DRIVE="/media/mon_disque_externe" # Par exemple - Tout dépend d'où le disque est monté
|
||||
mv /home/yunohost.backup/archives $PATH_TO_DRIVE/yunohost_backup_archives
|
||||
ln -s $PATH_TO_DRIVE/yunohost_backup_archives /home/yunohost.backup/archives
|
||||
```
|
||||
|
||||
#### Sauvegardes automatiques
|
||||
|
||||
Vous pouvez ajouter une tâche cron pour déclencher automatiquement une sauvegarde régulièrement. Par exemple pour sauvegarder l'application WordPress toutes les semaines, créez un fichier `/etc/cron.weekly/backup-wordpress` avec le contenu suivant :
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
yunohost backup create --apps wordpress
|
||||
```
|
||||
puis rendez-le exécutable :
|
||||
|
||||
```bash
|
||||
chmod +x /etc/cron.weekly/backup-wordpress
|
||||
```
|
||||
|
||||
Soyez prudent à propos de ce que vous sauvegardez et de la fréquence : il vaut mieux éviter de se retrouver avec un disque saturé car vous avez voulu sauvegarder 30 Go de données tous les jours...
|
||||
|
||||
#### Sauvegarder sur un serveur distant
|
||||
|
||||
Vous pouvez suivre ce tutoriel sur le forum pour mettre en place Borg entre deux serveurs : [https://forum.yunohost.org/t/how-to-backup-your-yunohost-server-on-another-server/3153](https://forum.yunohost.org/t/how-to-backup-your-yunohost-server-on-another-server/3153)
|
||||
|
||||
Il existe aussi l'application Archivist qui permet un système similaire : [https://forum.yunohost.org/t/new-app-archivist/3747](https://forum.yunohost.org/t/new-app-archivist/3747)
|
||||
|
||||
#### Éviter de sauvegarder certains dossiers
|
||||
Si besoin, vous pouvez spécifier que certains dossiers `home` d'utilisateurs ne soient pas sauvegardés par la commande `yunohost backup`, en créant un fichier vide nommé `.nobackup` à l'intérieur.
|
||||
|
||||
|
||||
#### Pour les cartes ARM: sauvegarde complète avec USBimager ou `dd`
|
||||
|
||||
Si vous êtes sur une carte ARM, une autre méthode de sauvegarde consiste à créer une image de la carte SD.
|
||||
|
||||
Ceci peut être effectué avec [USBimager](https://bztsrc.gitlab.io/usbimager/) (N.B. : assurez-vous de télécharger la version 'Read-write' ! Pas la version 'Write-only' !). Le processus est ensuite « l'inverse » du processus de flashage de la carte SD :
|
||||
- Éteignez votre serveur ;
|
||||
- Récupérez la carte SD et branchez la dans votre ordinateur ;
|
||||
- Dans USBimager, cliquez sur "Read" pour créer une image (« photographie ») de la carte SD. Vous pouvez utiliser le fichier obtenu pour plus tard restaurer le système en entier.
|
||||
|
||||
Vous pouvez trouver plus de détails dans [la doc d'USBimager](https://gitlab.com/bztsrc/usbimager/#creating-backup-image-file-from-device).
|
||||
|
||||
Il est possible d'obtenir la même chose avec `dd` si vous êtes à l'aise avec la ligne de commande (remplacez `/dev/mmcblk0` par le vrai nom de votre carte SD) :
|
||||
|
||||
```bash
|
||||
dd if=/dev/mmcblk0 | gzip > ./my_snapshot.gz
|
||||
```
|
||||
* [Évaluer la qualité de sa sauvegarde](/backup/strategies)
|
||||
* [Cloner son système de fichier](/backup/clone_filesystem)
|
||||
* [Éviter une panne matérielle](/backup/avoid_hardware_failure)
|
||||
* [Inclure/exclure des fichiers](/backup/include_exclude_files)
|
||||
* [Méthodes personnalisées](/backup/custom_backup_methods)
|
||||
* [Migrer ou fusionner des serveurs](/backup/migrate_or_merge_servers)
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Backing up your server and apps
|
||||
title: Backing up your server
|
||||
template: docs
|
||||
taxonomy:
|
||||
category: docs
|
||||
|
|
@ -7,25 +7,29 @@ routes:
|
|||
default: '/backup'
|
||||
---
|
||||
|
||||
Backing up your server, apps and data is an important concern when administrating a server. This protects you from unexpected events that could happen (server lost in a fire, database corruption, loss of access, server compromised...). The backup policy you will put in place depends of the importance of the services and data hosted. For instance you won't care too much about having backup on a test server, but you will care about having a backup of critical data of your association or company, and having this backup *in a different physical place*.
|
||||
In the context of self-hosting, backups are an important element to compensate for unexpected events (fire, database corruption, loss of access to the server, compromised server...). The backup policy to implement depends on the importance of the services and data you manage. For example, backing up a test server will be of little interest, while you will want to be very careful if you are managing critical data for an association or a company - and in such cases, you will want to store the backups *in a different location or locations*.
|
||||
|
||||
## Backups in the context of YunoHost
|
||||
## Manual backup
|
||||
|
||||
### Backup
|
||||
|
||||
YunoHost comes with a backup system, that allows to backup (and restore) system configurations and data (e.g. mails) and apps if they support it.
|
||||
|
||||
You can manage backups either from the command line (`yunohost backup --help`) or from the web administration (in the Backups section) though some features are not yet available in the webadmin.
|
||||
|
||||
The current default method consists in creating a `.tar.gz` archive containing all relevant files. In the future, YunoHost plans to support [Borg](https://www.borgbackup.org/) which is a more flexible, efficient and powerful solution.
|
||||
The current default method consists in creating a `.tar` archive containing all relevant files.
|
||||
|
||||
## Creating backups
|
||||
#### Creating backups
|
||||
|
||||
### From the webadmin
|
||||
[ui-tabs position="top-left" active="0" theme="lite"]
|
||||
[ui-tab title="From the webadmin"]
|
||||
|
||||
You can easily create backup archives from the webadmin by going in Backups > Local storage and clicking on "New backup". You will then be asked to select which configuration, data and apps you want to backup.
|
||||
You can easily create backup archives from the webadmin by going in `Backups > Local storage` and clicking on `New backup`. You will then be asked to select which configuration, data and apps you want to backup.
|
||||
|
||||
|
||||
|
||||
### From the command line
|
||||
[/ui-tab]
|
||||
[ui-tab title="From the command line"]
|
||||
|
||||
You can create a new backup archive with the command line. Here are a few simple example of commands and their corresponding behavior:
|
||||
|
||||
|
|
@ -60,122 +64,110 @@ You can create a new backup archive with the command line. Here are a few simple
|
|||
```
|
||||
|
||||
For more informations and options about backup creation, consult `yunohost backup create --help`. You can also list system parts that can be backuped with `yunohost hook list backup`.
|
||||
[/ui-tab]
|
||||
[/ui-tabs]
|
||||
|
||||
### Apps-specific configuration
|
||||
#### Downloading backups
|
||||
|
||||
Some apps such as Nextcloud may be related to a large quantity of data. If you want you can backup the app without the user data. This practice is referred to "backing up only the core" (of the app).
|
||||
When performing an upgrade, apps with large quantity of data will, usually, do a backup without those data.
|
||||
[ui-tabs position="top-left" active="0" theme="lite"]
|
||||
[ui-tab title="From the webadmin"]
|
||||
After creating backups, it is possible to list and inspect them using the corresponding views in the web administration interface. A button offers to download the archive. If the archive is larger than 3GB, it may be better to proceed via SFTP.
|
||||
|
||||
To manually disable the backup of large data, for application that implement that feature, you can set the variable `BACKUP_CORE_ONLY`. To do so, the variable have to be set before the backup command: `sudo BACKUP_CORE_ONLY=1 yunohost backup create --apps nextcloud`. Be careful though that mean you will have to backup user data yourself. But doing so, you will be able to do incremental or differential backups of this large amount of data (which is not an option provided by yunohost yet).
|
||||
`Backup > Local Archives > <Archive name> > Download`
|
||||
|
||||
## Downloading and uploading backups
|
||||
[/ui-tab]
|
||||
[ui-tab title="With a SFTP client"]
|
||||
Currently, the most accessible way to download big archives is to use the program FileZilla as explained in [this page](/filezilla).
|
||||
|
||||
After creating backup archives, it is possible to list and inspect them via the corresponding views in the webadmin, or via `yunohost backup list` and `yunohost backup info <archivename>` from the command line. By default, backups are stored in `/home/yunohost.backup/archives/`.
|
||||
By default, backups are stored in `/home/yunohost.backup/archives/`.
|
||||
|
||||
Currently, the most accessible way to download archives is to use the program FileZilla as explained in [this page](/filezilla).
|
||||
[/ui-tab]
|
||||
[ui-tab title="From the command line"]
|
||||
The `yunohost backup list` and `yunohost backup info <archive_name>` commands provide information about the names and sizes of backups.
|
||||
|
||||
Alternatively, a solution can be to install Nextcloud or a similar app and configure it to be able to access files in `/home/yunohost.backup/archives/` from a web browser.
|
||||
|
||||
One solution consists in using `scp` (a program based on [`ssh`](/ssh)) to copy files between two machines via the command line. Hence, from a machine running GNU/Linux, you should be able to run the following to download a specific backup:
|
||||
It is possible to use `scp` (a program based on [`ssh`](/ssh)) to copy files between two machines via the command line. So, from a GNU/Linux machine, you can use the following command to download an archive:
|
||||
|
||||
```bash
|
||||
scp admin@your.domain.tld:/home/yunohost.backup/archives/<archivename>.tar.gz ./
|
||||
scp admin@your.domain.tld:/home/yunohost.backup/archives/<archive_name>.tar ./
|
||||
```
|
||||
[/ui-tab]
|
||||
[/ui-tabs]
|
||||
|
||||
Similarly, you can upload a backup from a machine to your server with:
|
||||
! Don't forget to store your backup in a different place than your server.
|
||||
|
||||
|
||||
!!! If you want, you can connect an external disk to your server so that the archives arrive directly on it. See this guide for [Add an external storage to your server](/external_storage)
|
||||
|
||||
### Testing
|
||||
|
||||
You should regularly test your backups by at least listing the contents of the archives and checking the weight of the associated data. It is best to practice restoring regularly.
|
||||
```bash
|
||||
scp /path/to/your/<archivename>.tar.gz admin@your.domain.tld:/home/yunohost.backup/archives/
|
||||
# List the files
|
||||
tar -tvf /home/yunohost.backup/archives/ARCHIVE.tar | less
|
||||
|
||||
# List database exports
|
||||
tar -tvf /home/yunohost.backup/archives/ARCHIVE.tar | grep "(db|dump)`.sql"
|
||||
|
||||
# Check the weight
|
||||
ls -lh /home/yunohost.backup/archives/ARCHIVE.tar
|
||||
```
|
||||
|
||||
## Restoring backups
|
||||
### Restoring backups
|
||||
!!! SPOILER: The larger your data volume and the more applications you have, the more complex your recovery will be.
|
||||
|
||||
### From the webadmin
|
||||
#### Simple case: little data, archive already present
|
||||
[ui-tabs position="top-left" active="0" theme="lite"]
|
||||
[ui-tab title="From the webadmin"]
|
||||
|
||||
Go in Backup > Local storage and select your archive. You can then select which items you want to restore, then click on 'Restore'.
|
||||
Go in `Backup > Local storage` and select your archive. You can then select which items you want to restore, then click on 'Restore'.
|
||||
|
||||
|
||||
|
||||
### From the command line
|
||||
[/ui-tab]
|
||||
[ui-tab title="From the command line"]
|
||||
|
||||
From the command line, you can run `yunohost backup restore <archivename>` (without the `.tar.gz`) to restore an archive. As for `yunohost backup create`, this will restore everything in the archive by default. If you want to restore only specific items, you can use for instance `yunohost backup restore --apps wordpress` which will restore only the wordpress app.
|
||||
From the command line, you can run `yunohost backup restore <archivename>` (without the `.tar`) to restore an archive. As for `yunohost backup create`, this will restore everything in the archive by default. If you want to restore only specific items, you can use for instance `yunohost backup restore --apps wordpress` which will restore only the wordpress app.
|
||||
|
||||
### Constraints
|
||||
!!! In the case of a complete restoration, it is possible to restore instead of launching the initial configuration.
|
||||
[/ui-tab]
|
||||
[/ui-tabs]
|
||||
|
||||
To restore an app, the domain on which it was installed should already be configured (or you need to restore the corresponding system configuration). You also cannot restore an app which is already installed... which means that to restore an old version of an app, you must first uninstall it.
|
||||
|
||||
### Restoring during the postinstall
|
||||
#### Upload an archive
|
||||
|
||||
One specific feature is the ability to restore a full archive *instead* of the postinstall step. This makes it useful when you want to reinstall a system entirely from an existing backup. To be able to do this, you will need to upload the archive on the server and place it in `/home/yunohost.backup/archives`. Then, **instead of** `yunohost tools postinstall` you can run:
|
||||
In many cases, the archive is not on the server on which you want to restore it. So it has to be uploaded, which depending on its weight can take more or less time.
|
||||
|
||||
[ui-tabs position="top-left" active="0" theme="lite"]
|
||||
[ui-tab title="With an SFTP client"]
|
||||
Currently, the most accessible solution for uploading backups is to use the FileZilla program as explained in [this page](/filezilla).
|
||||
|
||||
By default, backups are to be placed in `/home/yunohost.backup/archives/`.
|
||||
[/ui-tab]
|
||||
[ui-tab title="From the command line"]
|
||||
You can upload a backup from a machine to your server with :
|
||||
|
||||
```bash
|
||||
yunohost backup restore <archivename>
|
||||
scp /path/to/your/<archive_name>.tar.gz admin@your.domain.tld:/home/yunohost.backup/archives/
|
||||
```
|
||||
[/ui-tab]
|
||||
[/ui-tabs]
|
||||
|
||||
Note: If your archive isn't in `/home/yunohost.backup/archives`, you can create the directory, move the archive into it, and restore it like this:
|
||||
## Automatic or remote backup
|
||||
|
||||
```bash
|
||||
mkdir -p /home/yunohost.backup/archives
|
||||
mv /path/to/<archivename> /home/yunohost.backup/archives/
|
||||
yunohost backup restore <archivename>
|
||||
```
|
||||
There are 3 YunoHost applications that offer to extend YunoHost with an automated backup method.
|
||||
|
||||
## To go further
|
||||
* [BorgBackup](/backup/borgbackup)
|
||||
* [Restic](/backup/restic)
|
||||
* [Archivist](/backup/archivist)
|
||||
|
||||
### Storing backups on a different drive
|
||||
## Go further
|
||||
|
||||
If you want, you can connect and mount an external drive to store backup archives on it (among other things). For this, plug in the drive and make sure that next time it is mounted automatically, by following the instruction at [Adding an external storage to your server](https://yunohost.org/#/external_storage).
|
||||
* [Evaluate the quality of your backup](/backup/strategies)
|
||||
* [Clone your file system](/backup/clone_filesystem)
|
||||
* [Avoid a hardware failure](/backup/avoid_hardware_failure)
|
||||
* [Include/exclude files](/backup/include_exclude_files)
|
||||
* [Custom methods](/backup/custom_backup_methods)
|
||||
* [Migrate or merge servers](/backup/migrate_or_merge_servers)
|
||||
|
||||
Then, move the existing archives and then add a symbolic link.
|
||||
|
||||
```bash
|
||||
PATH_TO_DRIVE="/media/my_external_drive" # For instance, depends of where you mounted your drive
|
||||
mkdir $PATH_TO_DRIVE/yunohost_backup_archives # On your external drive create the folder where the backups will go
|
||||
mv /home/yunohost.backup/archives $PATH_TO_DRIVE/yunohost_backup_archives # Move the archive folder including existing backups (if you made them) to the new folder on the external drive
|
||||
ln -s $PATH_TO_DRIVE/yunohost_backup_archives /home/yunohost.backup/archives # Create a symbolic link from the old local folder to the new folder on the external drive
|
||||
```
|
||||
|
||||
### Automatic backups
|
||||
|
||||
You can add a simple cron job to trigger automatic backups regularly. For instance, to backup your wordpress weekly, create a file `/etc/cron.weekly/backup-wordpress` with the following content:
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
yunohost backup create --apps wordpress
|
||||
```
|
||||
|
||||
then make it executable:
|
||||
|
||||
```bash
|
||||
chmod +x /etc/cron.weekly/backup-wordpress
|
||||
```
|
||||
|
||||
Be careful what you backup exactly and when: you don't want to end up with your whole disk space saturated because you backuped 30 GB of data every day.
|
||||
|
||||
#### Backing your server on a remote server
|
||||
|
||||
You can follow this tutorial on the forum to setup Borg between two servers: <https://forum.yunohost.org/t/how-to-backup-your-yunohost-server-on-another-server/3153>
|
||||
|
||||
Alternatively, the app Archivist allows to setup a similar system: <https://forum.yunohost.org/t/new-app-archivist/3747>
|
||||
|
||||
#### Avoiding the backup of some folders
|
||||
If needed, you can specify that some `/home/user` folders are left out of the `yunohost backup` command, by creating a blank file named `.nobackup` in them.
|
||||
|
||||
#### For ARM boards: full backup with USBimager or `dd`
|
||||
|
||||
If you are using an ARM board, another method for doing a full backup can be to create an image of the SD card.
|
||||
|
||||
This can be done easily using [USBimager](https://bztsrc.gitlab.io/usbimager/) (N.B. be sure to get the Read-Write version! Not the write-only version!). The process is basically the *reverse* of flashing the SD card.
|
||||
- Poweroff your server
|
||||
- Get the SD card and plug it into your computer
|
||||
- Using USBimager, click the *Read* button to create an image (snapshot) of the sd card. You can use it later to restore the entire system.
|
||||
|
||||
More details [in the USBimager doc](https://gitlab.com/bztsrc/usbimager/#creating-backup-image-file-from-device)
|
||||
|
||||
Alternatively you can use `dd` if you're comfortable with the command line with something like:
|
||||
|
||||
```bash
|
||||
dd if=/dev/mmcblk0 | gzip > ./my_snapshot.gz
|
||||
```
|
||||
|
||||
(replace `/dev/mmcblk0` with the actual device of your SD card)
|
||||
|
|
|
|||
|
|
@ -0,0 +1,64 @@
|
|||
---
|
||||
title: Stratégies de sauvegarde
|
||||
template: docs
|
||||
taxonomy:
|
||||
category: docs
|
||||
routes:
|
||||
default: '/backup_strategies'
|
||||
page-toc:
|
||||
active: true
|
||||
depth: 3
|
||||
---
|
||||
|
||||
Dans le contexte de l'auto-hébergement, les sauvegardes (backup) sont un élément important pour pallier les événements inattendus (incendies, corruption de base de données, perte d'accès au serveur, serveur compromis...). La politique de sauvegardes à mettre en place dépend de l'importance des services et des données que vous gérez. Par exemple, sauvegarder un serveur de test aura peu d'intérêt, tandis que vous voudrez montrer beaucoup plus de prudence si vous gérez des données critiques pour une association ou une entreprise - et dans ce genre de cas, vous souhaiterez stocker les sauvegardes *dans un ou des endroits différents*.
|
||||
|
||||
## Qu'est-ce qu'une bonne sauvegarde ?
|
||||
Une bonne sauvegarde est constituée d'au moins **3 copies des données** (en comptant les données originales), sur au moins **2 stockages distincts**, dans au moins **2 lieux distincts** (suffisamment éloignés) et idéalement avec 2 méthodes distinctes. Si vos sauvegardes sont chiffrées **ces règles s'appliquent aussi à la phrase/clé de déchiffrement**.
|
||||
|
||||
Une bonne sauvegarde est aussi dans de nombreux cas, une sauvegarde récente, il faut donc soit beaucoup de rigueur, soit **automatiser** le processus.
|
||||
|
||||
Une bonne sauvegarde est vérifiée régulièrement afin de s'assurer de l'effectivité et de l'intégrité des données.
|
||||
|
||||
Enfin, une bonne sauvegarde est une sauvegarde **restaurable dans des délais acceptables** pour vous. Pensez notamment à documenter votre méthode de restauration et à estimer le temps de transfert d'une copie notamment si les connexions internet en jeu ne sont pas symétriques.
|
||||
|
||||
!!! Exemple d'**une combinaison** robuste et comfortable:
|
||||
* une sauvegarde distante et automatique avec borg
|
||||
* une sauvegarde sur disque externe et automatique avec borg
|
||||
* un snapshot/image régulier (et avant les mises à jour)
|
||||
* une grappe RAID 1 monitorée (ou un VPS du commerce qui sera aussi sur une grappe)
|
||||
* une passphrase de déchiffrement stockée sur 3 supports dans 2 lieux
|
||||
|
||||
|
||||
## Quelques méthodes possibles
|
||||
|
||||
* [générer une archive et la télécharger manuellement (méthode par défaut de YunoHost)](/backup#sauvegarde-manuelle)
|
||||
* [sauvegarder automatiquement (méthode conseillée)](/backup#sauvegarde-automatique-ou-distante)
|
||||
* [générer une archive directement sur un autre disque](/external_storage)
|
||||
* [faire une image du disque ou un snapshot](/backup/clone_filesystem)
|
||||
* [sauvegarder les données utiles via une méthode personnalisée](/backup/custom_backup_methods)
|
||||
|
||||
## Risques
|
||||
Ci-dessous, une liste de risques triés du plus au moins probable, dont la probabilité reste à adapter selon votre situation (lieu du serveur, qualité des installations, profils d'usagers, etc.). À vous de mettre le curseur là où il faut, notamment en considérant les conséquences d'une perte de données.
|
||||
|
||||
!!! Gardez en tête que les vrais accidents sont liés à la survenue de 2 événements de façon simultanée.
|
||||
|
||||
* **Manque de rigueur**: les stratégies à base de sauvegardes manuelles nécessitent beaucoup de rigueur dans la régularité
|
||||
* **Mauvaise manipulation**: il peut arriver d'effacer une sauvegarde par erreur lors d'une restauration ou si vous comptez sur un système de synchronisation, vous pourriez supprimer un fichier et que la suppression soit synchronisée de façon instantanée
|
||||
* **Cryptolocker**: il s'agit de virus qui chiffrent les fichiers et réclament une rançon. Si vos utilisateurs ou utilisatrices utilisent nextcloud et windows, un windows infecté pourrait synchroniser des fichiers chiffrés et ainsi vous perdriez votre copie.
|
||||
* **Panne matérielle**: les cartes SD sont les supports les moins fiables dans le temps (~2ans de vie dans un serveur), viennent ensuite les disques SSD (environ 3 ans de vie) et les disques durs (3 ans). À noter qu'un équipement neuf a aussi une probabilité non nulle de tomber en panne lors des 6 premiers mois. Dans tous les cas, vos copies ne devraient pas être sur le même support physique.
|
||||
* **Panne logicielle/bug**: un bug logiciel peut aboutir à la suppression de données ou vous pourriez ne pas savoir réparer un problème et souhaiter restaurer votre système.
|
||||
* **Panne d'électricité ou d'internet**: avez-vous un plan si ça arrive ? Quid si vous êtes en vacances ?
|
||||
* **Catastrophe ou événement naturel ou non**: un petit enfant, un chat, la foudre ou une simple fuite peuvent détruire votre matériel. Les incendies ou inondations peuvent aussi mettre à mal votre copie de sauvegarde à l'autre bout de votre logement...
|
||||
* **Compromission du serveur**: une personne malveillante ou un robot pourrait attaquer votre serveur et supprimer vos données.
|
||||
* **Vol de machine**: un cambriolage ou le vol d'un ordinateur sur lequel se trouve votre gestionnaire de mots de passe pour déchiffrer vos sauvegardes.
|
||||
* **Perquisition**: que vous soyez coupable ou non, une perquisition peut aboutir à la saisie entière du matériel informatique d'un lieu (voir de plusieurs lieux).
|
||||
* **Décès/problème de santé**: vous pourriez ne plus être en mesure de taper votre phrase de passe.
|
||||
|
||||
## À propos de la synchronisation Nextcloud ou Thunderbird (IMAP)
|
||||
Une méthode qui permet une sauvegarde partielle consiste à sauvegarder les fichiers et les emails via des logiciels de synchronisation comme Nextcloud client ou ThunderBird. De cette façon, vous évitez le risque de panne matérielle.
|
||||
|
||||
Si cette méthode est simple à mettre en place, elle n'est pas sans risque du fait de la synchronisation elle-même. Par exemple, si vous êtes sur windows ou mac, vous augmentez de façon non négligeable le risque de perte de données suite au chiffrement des fichiers par un virus de type [cryptolocker](https://fr.wikipedia.org/wiki/Ran%C3%A7ongiciel). Sur tout type de système, une fausse manipulation peut supprimer l'ensemble de vos copies sur le serveur et sur les équipements qui synchronisent. Ce souci est aggravé par le fait que la synchronisation de suppression est en général plutôt instantanée.
|
||||
|
||||
Si le risque de fausse manipulation peut être atténué via des logiciels de sauvegarde pour PC de bureau comme TimeShift, seule une sauvegarde sur un disque dur externe déconnecté vous protège vraiment des rançongiciels.
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,64 @@
|
|||
---
|
||||
title: Backup strategies
|
||||
template: docs
|
||||
taxonomy:
|
||||
category: docs
|
||||
routes:
|
||||
default: '/backup_strategies'
|
||||
page-toc:
|
||||
active: true
|
||||
depth: 3
|
||||
---
|
||||
|
||||
|
||||
In the context of self-hosting, backups are an important element to compensate for unexpected events (fire, database corruption, loss of access to the server, compromised server...). The backup policy to implement depends on the importance of the services and data you manage. For example, backing up a test server will be of little interest, while you will want to be very careful if you are managing critical data for an association or a company - and in such cases, you will want to store the backups *in a different location or locations*.
|
||||
|
||||
## What is a good backup ?
|
||||
A good backup consists of at least **3 copies of the data** (including the original data), on at least **2 separate storages**, in at least **2 separate locations** (far enough apart) and ideally with 2 separate methods. If your backups are encrypted **these rules also apply to the decryption phrase/key**.
|
||||
|
||||
A good backup is also in many cases, a recent backup, so it takes either a lot of rigor or to **automate** the process.
|
||||
|
||||
A good backup is checked regularly to ensure the effectiveness and integrity of the data.
|
||||
|
||||
Finally, a good backup is one that is **restorable within an acceptable timeframe** for you. Remember to document your restoration method and to estimate the transfer time of a copy, especially if the Internet connections involved are not symmetrical.
|
||||
|
||||
|
||||
!!! Example of **a robust and comfortable combination**:
|
||||
* a remote and automatic backup with borg
|
||||
* a backup on external disk and automatic with borg
|
||||
* a regular snapshot/image (and before updates)
|
||||
* a monitored RAID 1 array (or a commercial VPS that will also be on an array)
|
||||
* a decryption passphrase stored on 3 media in 2 locations
|
||||
|
||||
## Some possible methods
|
||||
|
||||
* [generate an archive and download it manually (default method of YunoHost)](/backup#manual-backup)
|
||||
* [backup automatically (recommended method)](/backup#automatic-or-remote-backup)
|
||||
* [generate an archive directly on another disk](/external_storage)
|
||||
* [make a disk image or snapshot](/backup/clone_filesystem)
|
||||
* [save useful data via a custom method](/backup/custom_backup_methods)
|
||||
|
||||
|
||||
## Risks
|
||||
Below, a list of risks sorted from the most to the least probable, whose probability remains to be adapted according to your situation (location of the server, quality of the installations, user profiles, etc.). It is up to you to put the cursor where it should be, especially considering the consequences of a data loss.
|
||||
|
||||
!!! Keep in mind that real accidents are linked to the occurrence of 2 events simultaneously.
|
||||
|
||||
* **Lack of rigor**: strategies based on manual backups require a lot of rigor in the regularity
|
||||
* **Bad handling**: it can happen that a backup is erased by mistake during a restoration or if you rely on a synchronization system, you could delete a file and the deletion would be synchronized instantly
|
||||
* **Cryptolocker**: this is a virus that encrypts files and demands a ransomware. If your users are using nextcloud and windows, an infected windows could synchronize encrypted files and thus you lose your copy.
|
||||
* **Hardware failure**: SD cards are the least reliable media over time (~2 years of life in a server), followed by SSD disks (about 3 years of life) and hard drives (3 years). Note that a new equipment has also probability to break down during the first 6 months. In all cases, your copies should not be on the same physical media.
|
||||
* **Software failure/bug**: a software bug may result in data deletion or you may not know how to fix a problem and want to restore your system.
|
||||
* **Electricity or internet failure**: do you have a plan if this happens? What if you are on vacation?
|
||||
* **Disaster or natural or unnatural event**: a small child, a cat, lightning or a simple leak can destroy your equipment. Fires or floods can also destroy your backup copy at the other end of your home...
|
||||
* **Server compromise**: a malicious person or a robot could attack your server and delete your data
|
||||
* **Machine theft**: a burglary or theft of a computer on which your password manager is located to decrypt your backups
|
||||
* **Search**: whether you are guilty or not, a search can result in the seizure of the entire computer equipment of a place (or even several)
|
||||
* **Death/health problem**: you may not be able to type your passphrase anymore
|
||||
|
||||
## About Nextcloud or Thunderbird (IMAP) synchronization
|
||||
A method that allows a partial backup is to backup files and emails via synchronization software like Nextcloud client or ThunderBird. This way, you avoid the risk of hardware failure.
|
||||
|
||||
If this method is easy to set up, it is not without risk because of the synchronization itself. For example, if you are on Windows or Mac, you increase the risk of data loss following the encryption of files by a [cryptolocker](https://en.wikipedia.org/wiki/Ransomware) type virus. On any type of system, a false manipulation can delete all your copies on the server and on the equipment that synchronizes. This concern is aggravated by the fact that the deletion synchronization is usually rather instantaneous.
|
||||
|
||||
While the risk of false manipulation can be mitigated by desktop backup software such as TimeShift, the risk of false manipulation can only be mitigated by a backup on a hard drive. Only a backup on a disconnected external hard drive really protects you from ransomware.
|
||||
|
|
@ -0,0 +1,85 @@
|
|||
---
|
||||
title: BorgBackup
|
||||
template: docs
|
||||
taxonomy:
|
||||
category: docs
|
||||
routes:
|
||||
default: '/backup/borgbackup'
|
||||
page-toc:
|
||||
active: true
|
||||
depth: 3
|
||||
---
|
||||
|
||||
|
||||
YunoHost propose un couple d'applications pour [BorgBackup](https://www.borgbackup.org/).
|
||||
|
||||
## Fonctionnalité
|
||||
Cette application propose:
|
||||
* la sauvegarde des données sur un disque externe ou sur un dépôt borg distant
|
||||
* la déduplication et la compression des fichiers ce qui permet de conserver de nombreuses copies antérieures
|
||||
* le chiffrement des données, ce qui permet de pouvoir stocker chez un tiers
|
||||
* de définir finement la fréquence et le type de données à sauvegarder
|
||||
* un système d'alerte mail en cas de défaut de sauvegarde.
|
||||
|
||||
Il existe des [fournisseurs de dépôts borg distants](https://www.borgbackup.org/support/commercial.html), il est également possible de créer son propre dépôt sur un autre YunoHost avec l'[application borgserver](https://github.com/YunoHost-Apps/borgserver_ynh).
|
||||
|
||||
La future méthode de sauvegarde intégrée par défaut dans YunoHost sera basée sur ce logiciel.
|
||||
|
||||
## Mise en place de la sauvegarde
|
||||
!!! Pour la mise en place, il faut d'abord installer l'[application borg](https://github.com/YunoHost-Apps/borg_ynh), puis éventuellement l'[application borgserver](https://github.com/YunoHost-Apps/borgserver_ynh).
|
||||
|
||||
|
||||
|
||||
## Tester
|
||||
Avec les apps borg un email est envoyé pour dire si la sauvegarde échoue ou si le repo distant n'a rien reçu. On peut toutefois analyser manuellement pour s'assurer que tout va bien de façon plus complète.
|
||||
|
||||
```bash
|
||||
# Lister les fichiers
|
||||
app=borg; BORG_PASSPHRASE="$(yunohost app setting $app passphrase)" BORG_RSH="ssh -i /root/.ssh/id_${app}_ed25519 -oStrictHostKeyChecking=yes " borg list "$(yunohost app setting $app repository)" | less
|
||||
|
||||
# Lister les exports de base de données
|
||||
app=borg; BORG_PASSPHRASE="$(yunohost app setting $app passphrase)" BORG_RSH="ssh -i /root/.ssh/id_${app}_ed25519 -oStrictHostKeyChecking=yes " borg list "$(yunohost app setting $app repository)" | grep "(db|dump)\.sql"
|
||||
|
||||
# Lister les fichiers de l'archive
|
||||
app=borg; BORG_PASSPHRASE="$(yunohost app setting $app passphrase)" BORG_RSH="ssh -i /root/.ssh/id_${app}_ed25519 -oStrictHostKeyChecking=yes " borg list "$(yunohost app setting $app repository)::ARCHIVE" | less
|
||||
|
||||
# Voir les infos de l'archive
|
||||
app=borg; BORG_PASSPHRASE="$(yunohost app setting $app passphrase)" BORG_RSH="ssh -i /root/.ssh/id_${app}_ed25519 -oStrictHostKeyChecking=yes " borg info "$(yunohost app setting $app repository)::ARCHIVE"
|
||||
|
||||
# Vérifier l'intégrité des données
|
||||
app=borg; BORG_PASSPHRASE="$(yunohost app setting $app passphrase)" BORG_RSH="ssh -i /root/.ssh/id_${app}_ed25519 -oStrictHostKeyChecking=yes " borg check "$(yunohost app setting $app repository)::ARCHIVE" --verify-data
|
||||
```
|
||||
|
||||
## Restaurer
|
||||
|
||||
Si on est dans le cas d'une migration ou d'une réinstallation, il faut réinstaller borg de la même façon. Si le repo est distant il faut changer la clé publique.
|
||||
|
||||
Lister les archives disponibles
|
||||
```
|
||||
app=borg; BORG_PASSPHRASE="$(yunohost app setting $app passphrase)" BORG_RSH="ssh -i /root/.ssh/id_${app}_ed25519 -oStrictHostKeyChecking=yes " borg list "$(yunohost app setting $app repository)"
|
||||
```
|
||||
|
||||
Créer les archives tar (une archive par app et partie de système)
|
||||
```
|
||||
app=borg; BORG_PASSPHRASE="$(yunohost app setting $app passphrase)" BORG_RSH="ssh -i /root/.ssh/id_${app}_ed25519 -oStrictHostKeyChecking=yes " borg export-tar "$(yunohost app setting $app repository)::ARCHIVE" /home/yunohost/archives/ARCHIVE.tar
|
||||
```
|
||||
|
||||
Puis restaurer l'archive de façon classique.
|
||||
|
||||
### Restaurer des grosses archives
|
||||
Si l'espace disponible est inférieur au poids de votre archive, des données décompressées et des dépendances, vous devrez restaurer partie par partie, app par app.
|
||||
|
||||
Si restaurer app par app ne suffit pas OU si une archive est trop grosse, il peut être judicieux de générer une archive tar sans les "grosses" données d'une app comme si elle avait été générée avec l'[option BACKUP_CORE_ONLY](/backup/include_exclude_files#ne-pas-sauvegarder-les-grosses-quantites-de-donnees). Exemple avec Nextcloud:
|
||||
```
|
||||
app=borg; BORG_PASSPHRASE="$(yunohost app setting $app passphrase)" BORG_RSH="ssh -i /root/.ssh/id_${app}_ed25519 -oStrictHostKeyChecking=yes " borg export-tar -e apps/nextcloud/backup/home/yunohost.app "$(yunohost app setting $app repository)::ARCHIVE" /home/yunohost/archives/ARCHIVE.tar
|
||||
```
|
||||
|
||||
Il faudra ensuite extraire ces données directement avec borg
|
||||
```
|
||||
cd /home/yunohost.app/
|
||||
app=borg; BORG_PASSPHRASE="$(yunohost app setting $app passphrase)" BORG_RSH="ssh -i /root/.ssh/id_${app}_ed25519 -oStrictHostKeyChecking=yes " borg extract "$(yunohost app setting $app repository)::ARCHIVE" apps/nextcloud/backup/home/yunohost.app/
|
||||
mv apps/nextcloud/backup/home/yunohost.app/nextcloud ./
|
||||
rm -r apps
|
||||
```
|
||||
|
||||
Puis restaurer de façon classique
|
||||
|
|
@ -0,0 +1,85 @@
|
|||
---
|
||||
title: BorgBackup
|
||||
template: docs
|
||||
taxonomy:
|
||||
category: docs
|
||||
routes:
|
||||
default: '/backup/borgbackup'
|
||||
page-toc:
|
||||
active: true
|
||||
depth: 3
|
||||
---
|
||||
|
||||
|
||||
YunoHost offers a couple of applications for [BorgBackup](https://www.borgbackup.org/).
|
||||
|
||||
## Functionality
|
||||
This application offers:
|
||||
* backup of data on an external disk or on a remote Borg repository
|
||||
* deduplication and compression of files, which allows to keep many previous copies
|
||||
* data encryption, which allows you to store data with a third party
|
||||
* to define the frequency and type of data to be backed up
|
||||
* a mail alert system in case of backup failure.
|
||||
|
||||
There are [remote borg repository providers](https://www.borgbackup.org/support/commercial.html), it is also possible to create your own repository on another YunoHost with the [borgserver application](https://github.com/YunoHost-Apps/borgserver_ynh).
|
||||
|
||||
The future default backup method integrated in YunoHost will be based on this software.
|
||||
|
||||
## Setting up the backup
|
||||
!!! To set up, first install the [borg application](https://github.com/YunoHost-Apps/borg_ynh), then optionally the [borgserver application](https://github.com/YunoHost-Apps/borgserver_ynh).
|
||||
|
||||
|
||||
## Test
|
||||
With the borg apps an email is sent to say if the backup fails or if the remote repo has received nothing. However, you can manually test to make sure everything is fine in a more complete way.
|
||||
|
||||
|
||||
```bash
|
||||
# List files
|
||||
app=borg; BORG_PASSPHRASE="$(yunohost app setting $app passphrase)" BORG_RSH="ssh -i /root/.ssh/id_${app}_ed25519 -oStrictHostKeyChecking=yes " borg list "$(yunohost app setting $app repository)" | less
|
||||
|
||||
# List database exports
|
||||
app=borg; BORG_PASSPHRASE="$(yunohost app setting $app passphrase)" BORG_RSH="ssh -i /root/.ssh/id_${app}_ed25519 -oStrictHostKeyChecking=yes " borg list "$(yunohost app setting $app repository)" | grep "(db|dump)\.sql"
|
||||
|
||||
# List files from the archive
|
||||
app=borg; BORG_PASSPHRASE="$(yunohost app setting $app passphrase)" BORG_RSH="ssh -i /root/.ssh/id_${app}_ed25519 -oStrictHostKeyChecking=yes " borg list "$(yunohost app setting $app repository)::ARCHIVE" | less
|
||||
|
||||
# View archive info
|
||||
app=borg; BORG_PASSPHRASE="$(yunohost app setting $app passphrase)" BORG_RSH="ssh -i /root/.ssh/id_${app}_ed25519 -oStrictHostKeyChecking=yes " borg info "$(yunohost app setting $app repository)::ARCHIVE"
|
||||
|
||||
# Verify data integrity
|
||||
app=borg; BORG_PASSPHRASE="$(yunohost app setting $app passphrase)" BORG_RSH="ssh -i /root/.ssh/id_${app}_ed25519 -oStrictHostKeyChecking=yes " borg check "$(yunohost app setting $app repository)::ARCHIVE" --verify-data
|
||||
```
|
||||
|
||||
## Restore
|
||||
|
||||
If we are in the case of a migration or a reinstallation, we must reinstall borg in the same way. If the repo is remote you have to change the public key.
|
||||
|
||||
List the available archives
|
||||
```
|
||||
app=borg; BORG_PASSPHRASE="$(yunohost app setting $app passphrase)" BORG_RSH="ssh -i /root/.ssh/id_${app}_ed25519 -oStrictHostKeyChecking=yes " borg list "$(yunohost app setting $app repository)"
|
||||
```
|
||||
|
||||
Create tar archives (one archive per app and system part)
|
||||
```
|
||||
app=borg; BORG_PASSPHRASE="$(yunohost app setting $app passphrase)" BORG_RSH="ssh -i /root/.ssh/id_${app}_ed25519 -oStrictHostKeyChecking=yes " borg export-tar "$(yunohost app setting $app repository)::ARCHIVE" /home/yunohost/archives/ARCHIVE.tar
|
||||
```
|
||||
|
||||
Then restore the archive in the usual way.
|
||||
|
||||
### Restore large archives
|
||||
If the available space is less than the weight of your archive, decompressed data and dependencies, you will have to restore part by part, app by app.
|
||||
|
||||
If restoring app by app is not enough OR if an archive is too big, it may be a good idea to generate a tarball without the "big" data of an app as if it had been generated with the [BACKUP_CORE_ONLY option] (/backup/include_exclude_files#don't-save-large-quantities-of-data). Example with Nextcloud:
|
||||
```
|
||||
app=borg; BORG_PASSPHRASE="$(yunohost app setting $app passphrase)" BORG_RSH="ssh -i /root/.ssh/id_${app}_ed25519 -oStrictHostKeyChecking=yes " borg export-tar -e apps/nextcloud/backup/home/yunohost.app "$(yunohost app setting $app repository)::ARCHIVE" /home/yunohost/archives/ARCHIVE.tar
|
||||
```
|
||||
|
||||
You will then have to extract these data directly with borg
|
||||
```
|
||||
cd /home/yunohost.app/
|
||||
app=borg; BORG_PASSPHRASE="$(yunohost app setting $app passphrase)" BORG_RSH="ssh -i /root/.ssh/id_${app}_ed25519 -oStrictHostKeyChecking=yes " borg extract "$(yunohost app setting $app repository)::ARCHIVE" apps/nextcloud/backup/home/yunohost.app/
|
||||
mv apps/nextcloud/backup/home/yunohost.app/nextcloud ./
|
||||
rm -r apps
|
||||
```
|
||||
|
||||
Then restore in the classic way
|
||||
|
|
@ -0,0 +1,22 @@
|
|||
---
|
||||
title: Restic
|
||||
template: docs
|
||||
taxonomy:
|
||||
category: docs
|
||||
routes:
|
||||
default: '/backup/restic'
|
||||
page-toc:
|
||||
active: true
|
||||
depth: 3
|
||||
---
|
||||
|
||||
|
||||
## Fonctionnalité
|
||||
|
||||
Cette application propose:
|
||||
* la sauvegarde des données sur un stockage distant (support de différents types de stockage)
|
||||
* la déduplication et la compression des fichiers ce qui permet de conserver de nombreuses copies antérieures
|
||||
* le chiffrement des données, ce qui permet de pouvoir stocker chez un tiers
|
||||
|
||||
Le paquet permet aussi de définir finement la fréquence et le type de données à sauvegarder et intègre un système d'alerte mail en cas de défaut de sauvegarde.
|
||||
|
||||
|
|
@ -0,0 +1,21 @@
|
|||
---
|
||||
title: Restic
|
||||
template: docs
|
||||
taxonomy:
|
||||
category: docs
|
||||
routes:
|
||||
default: '/backup/restic'
|
||||
page-toc:
|
||||
active: true
|
||||
depth: 3
|
||||
---
|
||||
|
||||
|
||||
## Functionality
|
||||
|
||||
This application offers:
|
||||
* backup of data to remote storage (support for different types of storage)
|
||||
* deduplication and compression of files, which makes it possible to keep many previous copies
|
||||
* data encryption, which allows to store data at a third party
|
||||
|
||||
The package also allows you to finely define the frequency and type of data to be backed up and integrates an email alert system in case of backup failure.
|
||||
|
|
@ -0,0 +1,22 @@
|
|||
---
|
||||
title: Archivist
|
||||
template: docs
|
||||
taxonomy:
|
||||
category: docs
|
||||
routes:
|
||||
default: '/backup/archivist'
|
||||
page-toc:
|
||||
active: true
|
||||
depth: 3
|
||||
---
|
||||
|
||||
|
||||
## Fonctionnalité
|
||||
Cette application se base sur rsync et GPG, elle propose:
|
||||
* la sauvegarde des données sur un stockage distant (support de différents types de stockage)
|
||||
* le chiffrement des données, ce qui permet de pouvoir stocker chez un tiers
|
||||
|
||||
Le paquet permet aussi de définir finement la fréquence et le type de données à sauvegarder et intègre un système d'alerte mail en cas de défaut de sauvegarde.
|
||||
|
||||
Pour plus d'information : [https://forum.yunohost.org/t/new-app-archivist/3747](https://forum.yunohost.org/t/new-app-archivist/3747)
|
||||
|
||||
|
|
@ -0,0 +1,22 @@
|
|||
---
|
||||
title: Archivist
|
||||
template: docs
|
||||
taxonomy:
|
||||
category: docs
|
||||
routes:
|
||||
default: '/backup/archivist'
|
||||
page-toc:
|
||||
active: true
|
||||
depth: 3
|
||||
---
|
||||
|
||||
|
||||
## Functionality
|
||||
This application is based on rsync and GPG, it offers:
|
||||
* backup of data on a remote storage (support for different types of storage)
|
||||
* data encryption, which allows to store data at a third party
|
||||
|
||||
The package also allows you to finely define the frequency and type of data to be backed up and integrates an email alert system in case of backup failure.
|
||||
|
||||
For more information: [https://forum.yunohost.org/t/new-app-archivist/3747](https://forum.yunohost.org/t/new-app-archivist/3747)
|
||||
|
||||
|
|
@ -0,0 +1,158 @@
|
|||
---
|
||||
title: Créer une image du système
|
||||
template: docs
|
||||
taxonomy:
|
||||
category: docs
|
||||
routes:
|
||||
default: '/backup/clone_filesystem'
|
||||
page-toc:
|
||||
active: true
|
||||
depth: 3
|
||||
---
|
||||
L'outil de sauvegarde de YunoHost ne sauvegarde que les fichiers utiles et se base sur des scripts de restauration pour réinstaller les dépendances de vos applications. Autrement dit, le mécanisme de YunoHost revient à réinstaller, puis réincorporer les données.
|
||||
|
||||
Réaliser des images complètes du système peut être un moyen complémentaire ou alternatif de sauvegarder votre machine. L'intérêt est que votre système pourra être restauré dans l'état exact du moment de la sauvegarde.
|
||||
|
||||
Selon votre type d'installation, vous pouvez soit créer un snapshot, soit cloner le support de stockage en le retirant de votre serveur (éteint).
|
||||
|
||||
## Déclencher un snapshot
|
||||
Un snapshot permet de figer une image du système de fichiers. Les snapshots sont très pratiques lorsque l'on fait une mise à jour ou des essais, car ils vous permettent de revenir facilement en arrière en cas de pépin. En revanche, en dehors de quelques clusters de très haute disponibilité, les snapshots ne vous protègent pas vraiment face à des pannes matérielles ou des catastrophes (cf. incendie d'OVH à Strasbourg en 2021).
|
||||
|
||||
En général, les snapshots sont assez économes en espace disque, le principe est que votre système de fichier va stocker les différences survenues depuis votre snapshot. Ainsi, seules les modifications consomment de l'espace.
|
||||
|
||||
! Pensez à supprimer les anciens snapshots pour éviter de gâcher votre espace de stockage en stockant toutes les différences depuis cette date !
|
||||
|
||||
Vous pouvez utiliser cette méthode avec la plupart des VPS (souvent payant), des gestionnaires de machines virtuelles ou si vous avez installé YunoHost avec un filesystem avancé comme btrfs, ceph ou ZFS, vous pouvez aussi créer des snapshots via la ligne de commande
|
||||
|
||||
[ui-tabs position="top-left" active="0" theme="lite"]
|
||||
[ui-tab title="VPS"]
|
||||
Ci-dessous, quelques documentations pour les fournisseurs les plus connus:
|
||||
* [DigitalOcean (EN)](https://docs.digitalocean.com/products/images/snapshots/)
|
||||
* [Gandi](https://docs.gandi.net/fr/simple_hosting/operations_courantes/snapshots.html)
|
||||
* [OVH](https://docs.ovh.com/fr/vps/snapshot-vps/)
|
||||
* [Scaleway (EN)](https://www.scaleway.com/en/docs/backup-your-data-with-snapshots/)
|
||||
[/ui-tab]
|
||||
[ui-tab title="VirtualBox"]
|
||||
Sélectionner la machine virtuelle et cliquer sur `Snapshots`, puis spécifier le nom du snapshot et cliquer sur `OK`.
|
||||
|
||||
|
||||
Pour restaurer, sélectionner la machine virtuelle, cliquer sur `Snapshots` puis `Restore Snapshot option`.
|
||||
|
||||
|
||||
Ensuite cliquer sur `Restore Snapshot`.
|
||||
|
||||
[/ui-tab]
|
||||
[ui-tab title="Proxmox"]
|
||||
|
||||
* Sélectionner la machine virtuelle
|
||||
* Aller dans l'onglet `Backup`
|
||||
* Cliquer sur `Backup now`
|
||||
* Choisir le mode `Snapshot`
|
||||
* Valider
|
||||
[/ui-tab]
|
||||
[ui-tab title="BTRFS"]
|
||||
Ci-dessous on considère que `/pool/volume` est le volume à snapshoter.
|
||||
|
||||
Créer un snapshot en lecture seule
|
||||
```
|
||||
btrfs subvolume snapshot /pool/volume /pool/volume/$(date +"%Y-%m-%d_%H:%M")
|
||||
```
|
||||
|
||||
Lister les snapshots
|
||||
```
|
||||
btrfs subvolume show /pool/volume
|
||||
```
|
||||
|
||||
Restaurer un snapshot
|
||||
```
|
||||
btrfs sub del /pool/volume
|
||||
btrfs sub snap /pool/volume/2021-07-22_16:12 /pool/volume
|
||||
btrfs sub del /pool/volume/2021-07-22_16:12
|
||||
```
|
||||
|
||||
Supprimer un snapshot
|
||||
```
|
||||
btrfs subvolume delete /pool/volume/2021-07-22_16:12
|
||||
```
|
||||
!! Attention de ne pas supprimer le volume original
|
||||
|
||||
!!! Voir [ce tutoriel](https://www.linux.com/training-tutorials/how-create-and-manage-btrfs-snapshots-and-rollbacks-linux-part-2/) pour plus d'info
|
||||
[/ui-tab]
|
||||
[ui-tab title="CEPH"]
|
||||
Ci-dessous on considère que `pool/volume` est le volume à snapshoter.
|
||||
|
||||
Créer un snapshot
|
||||
```
|
||||
rbd snap create pool/volume@$(date +"%Y-%m-%d_%H:%M")
|
||||
```
|
||||
|
||||
Lister les snapshots
|
||||
```
|
||||
rbd snap ls pool/volume
|
||||
```
|
||||
|
||||
Restaurer un snapshot
|
||||
```
|
||||
rbd snap rollback pool/volume@2021-07-22_16:22
|
||||
```
|
||||
|
||||
Supprimer un snapshot
|
||||
```
|
||||
rbd snap rm pool/volume@2021-07-22_16:12
|
||||
```
|
||||
[/ui-tab]
|
||||
[ui-tab title="ZFS"]
|
||||
Ci-dessous on considère que `pool/volume` est le volume à snapshoter.
|
||||
|
||||
Créer un snapshot
|
||||
```
|
||||
zfs snapshot pool/volume@$(date +"%Y-%m-%d_%H:%M")
|
||||
```
|
||||
|
||||
Lister les snapshots
|
||||
```
|
||||
zfs list -t snapshot -o name,creation
|
||||
```
|
||||
|
||||
Restaurer un snapshot
|
||||
```
|
||||
zfs rollback pool/volume@2021-07-22_16:22
|
||||
```
|
||||
|
||||
Supprimer un snapshot
|
||||
```
|
||||
zfs destroy pool/volume@2021-07-22_16:12
|
||||
```
|
||||
|
||||
[/ui-tab]
|
||||
[/ui-tabs]
|
||||
|
||||
|
||||
## Créer une image du système de fichier à froid
|
||||
|
||||
Vous pouvez cloner votre support (carte SD, disque ssd, volume de VPS...) pour créer une image disque. Cette image avant compression sera de la taille exacte de votre support, c'est pourquoi cette méthode s'applique plutôt aux machines de moins de 64Go.
|
||||
|
||||
À moins de pouvoir lire un snapshot, cette méthode nécessite d'arrêter le serveur le temps de créer l'image. Avec un VPS, il faut redémarrer en mode rescue depuis l'interface de votre fournisseur.
|
||||
|
||||
[ui-tabs position="top-left" active="0" theme="lite"]
|
||||
[ui-tab title="Avec USBimager"]
|
||||
Ceci peut être effectué avec [USBimager](https://bztsrc.gitlab.io/usbimager/) (N.B. : assurez-vous de télécharger la version 'Read-write' ! Pas la version 'Write-only' !). Le processus consiste ensuite à "l'inverse" du processus de flashage de la carte SD:
|
||||
- Éteignez votre serveur
|
||||
- Récupérez la carte SD et branchez-la dans votre ordinateur
|
||||
- Dans USBimager, cliquez sur "Read" pour créer une image ("photographie") de la carte SD. Vous pouvez utiliser le fichier obtenu pour plus tard restaurer le système en entier.
|
||||
|
||||
Plus de détails dans [la doc d'USBimager](https://gitlab.com/bztsrc/usbimager/#creating-backup-image-file-from-device)
|
||||
[/ui-tab]
|
||||
[ui-tab title="En ligne de commande avec dd"]
|
||||
|
||||
Il est possible d'obtenir la même chose avec `dd` si vous êtes à l'aise avec la ligne de commande:
|
||||
|
||||
```bash
|
||||
dd if=/dev/mmcblk0 | gzip > ./my_snapshot.gz
|
||||
```
|
||||
|
||||
(remplacez `/dev/mmcblk0` par le vrai nom de votre carte SD ou disque dur)
|
||||
|
||||
[/ui-tab]
|
||||
[/ui-tabs]
|
||||
|
||||
|
|
@ -0,0 +1,159 @@
|
|||
---
|
||||
title: Create a filesystem image
|
||||
template: docs
|
||||
taxonomy:
|
||||
category: docs
|
||||
routes:
|
||||
default: '/backup/clone_filesystem'
|
||||
page-toc:
|
||||
active: true
|
||||
depth: 3
|
||||
---
|
||||
|
||||
|
||||
YunoHost's backup tool only backs up useful files and relies on restore scripts to reinstall the dependencies of your applications. In other words, YunoHost's mechanism amounts to reinstalling and then reincorporating the data.
|
||||
|
||||
Making full system images can be a complementary or alternative way to backup your machine. The advantage is that your system can be restored to the exact state it was in at the time of the backup.
|
||||
|
||||
Depending on your type of installation, you can either create a snapshot or clone the storage medium by removing it from your server (turned off).
|
||||
|
||||
## Trigger a snapshot
|
||||
A snapshot allows you to freeze an image of the file system. Snapshots are very useful when doing an update or testing, because they allow you to easily go back in case of a glitch. On the other hand, apart from some very high availability clusters, snapshots do not really protect you against hardware failures or disasters (cf. OVH fire in Strasbourg in 2021).
|
||||
|
||||
In general, snapshots are quite disk space saving, the principle is that your file system will store the differences that occurred since your snapshot. Thus, only the modifications consume space.
|
||||
|
||||
! Remember to delete the old snapshots to avoid wasting your storage space by storing all the differences since that date!
|
||||
|
||||
You can use this method with most VPS (often paying), virtual machine managers or if you have installed YunoHost with an advanced filesystem like btrfs, ceph or ZFS, you can also create snapshots via the command line
|
||||
|
||||
[ui-tabs position="top-left" active="0" theme="lite"]
|
||||
[ui-tab title="VPS"]
|
||||
Below, some documentation for the most known suppliers:
|
||||
* [DigitalOcean (EN)](https://docs.digitalocean.com/products/images/snapshots/)
|
||||
* [Gandi](https://docs.gandi.net/fr/simple_hosting/operations_courantes/snapshots.html)
|
||||
* [OVH](https://docs.ovh.com/fr/vps/snapshot-vps/)
|
||||
* [Scaleway (EN)](https://www.scaleway.com/en/docs/backup-your-data-with-snapshots/)
|
||||
[/ui-tab]
|
||||
[ui-tab title="VirtualBox"]
|
||||
Select the virtual machine and click `Snapshots`, then specify the snapshot name and click `OK`.
|
||||
|
||||
|
||||
To restore, select the virtual machine, click on `Snapshots` then `Restore Snapshot option`.
|
||||
|
||||
|
||||
Then click on `Restore Snapshot`.
|
||||
|
||||
[/ui-tab]
|
||||
[ui-tab title="Proxmox"]
|
||||
|
||||
* Select the virtual machine
|
||||
* Go to the `Backup` tab
|
||||
* Click on `Backup now`.
|
||||
* Choose `Snapshot` mode
|
||||
* Validate
|
||||
[/ui-tab]
|
||||
[ui-tab title="BTRFS"]
|
||||
Below we consider that `/pool/volume` is the volume to snapshot.
|
||||
|
||||
Create a read-only snapshot
|
||||
```
|
||||
btrfs subvolume snapshot /pool/volume /pool/volume/$(date +"%Y-%m-%d_%H:%M")
|
||||
```
|
||||
|
||||
List snapshots
|
||||
```
|
||||
btrfs subvolume show /pool/volume
|
||||
```
|
||||
|
||||
Restore a snapshot
|
||||
```
|
||||
btrfs sub del /pool/volume
|
||||
btrfs sub snap /pool/volume/2021-07-22_16:12 /pool/volume
|
||||
btrfs sub del /pool/volume/2021-07-22_16:12
|
||||
```
|
||||
|
||||
Delete a snapshot
|
||||
```
|
||||
btrfs subvolume delete /pool/volume/2021-07-22_16:12
|
||||
```
|
||||
!! Be careful not to delete the original volume
|
||||
|
||||
!!! See [this tutorial](https://www.linux.com/training-tutorials/how-create-and-manage-btrfs-snapshots-and-rollbacks-linux-part-2/) for more info
|
||||
[/ui-tab]
|
||||
[ui-tab title="CEPH"]
|
||||
Below we consider that `pool/volume` is the volume to snapshot.
|
||||
|
||||
Create a snapshot
|
||||
```
|
||||
rbd snap create pool/volume@$(date +"%Y-%m-%d_%H:%M")
|
||||
```
|
||||
|
||||
List snapshots
|
||||
```
|
||||
rbd snap ls pool/volume
|
||||
```
|
||||
|
||||
Restore a snapshot
|
||||
```
|
||||
rbd snap rollback pool/volume@2021-07-22_16:22
|
||||
```
|
||||
|
||||
Delete a snapshot
|
||||
```
|
||||
rbd snap rm pool/volume@2021-07-22_16:12
|
||||
```
|
||||
[/ui-tab]
|
||||
[ui-tab title="ZFS"]
|
||||
Below we consider that `pool/volume` is the volume to snapshot.
|
||||
|
||||
Create a snapshot
|
||||
```
|
||||
zfs snapshot pool/volume@$(date +"%Y-%m-%d_%H:%M")
|
||||
```
|
||||
|
||||
List snapshots
|
||||
```
|
||||
zfs list -t snapshot -o name,creation
|
||||
```
|
||||
Restore a snapshot
|
||||
```
|
||||
zfs rollback pool/volume@2021-07-22_16:22
|
||||
```
|
||||
|
||||
Delete a snapshot
|
||||
```
|
||||
zfs destroy pool/volume@2021-07-22_16:12
|
||||
```
|
||||
|
||||
[/ui-tab]
|
||||
[/ui-tabs]
|
||||
|
||||
|
||||
## Create a cold image of the file system
|
||||
|
||||
You can clone your media (SD card, ssd disk, VPS volume...) to create a disk image. This image before compression will be the exact size of your media, that's why this method applies rather to machines of less than 64GB.
|
||||
|
||||
Unless you can read a snapshot, this method requires you to stop the server while you create the image. With a VPS, you have to restart in rescue mode from your provider's interface.
|
||||
|
||||
[ui-tabs position="top-left" active="0" theme="lite"]
|
||||
[ui-tab title="With USBimager"]
|
||||
This can be done with [USBimager](https://bztsrc.gitlab.io/usbimager/) (Note: make sure you download the 'Read-write' version! Not the 'Write-only' version!). The process then consists of the "reverse" of the SD card flashing process:
|
||||
- Turn off your server
|
||||
- Retrieve the SD card and plug it into your computer
|
||||
- In USBimager, click on "Read" to create an image ("photograph") of the SD card. You can use the resulting file to restore the whole system later.
|
||||
|
||||
More details in [USBimager documentation](https://gitlab.com/bztsrc/usbimager/#creating-backup-image-file-from-device)
|
||||
[/ui-tab]
|
||||
[ui-tab title="In command line with dd"]
|
||||
|
||||
It is possible to achieve the same thing with `dd` if you are comfortable with the command line:
|
||||
|
||||
```bash
|
||||
dd if=/dev/mmcblk0 | gzip > ./my_snapshot.gz
|
||||
```
|
||||
|
||||
(replace `/dev/mmcblk0` with the real name of your SD card or hard drive)
|
||||
|
||||
[/ui-tab]
|
||||
[/ui-tabs]
|
||||
|
||||
|
|
@ -0,0 +1,48 @@
|
|||
---
|
||||
title: Éviter les pannes matérielles
|
||||
template: docs
|
||||
taxonomy:
|
||||
category: docs
|
||||
routes:
|
||||
default: '/backup/avoid_hardware_failure'
|
||||
page-toc:
|
||||
active: true
|
||||
depth: 3
|
||||
---
|
||||
|
||||
## Sécuriser physiquement votre serveur
|
||||
Très souvent les personnes qui s'autohébergent n'ont pas de rangement correct pour leur système. Laisser le serveur en plusieurs parties, dans un lieu de passage, accessible à des enfants ou des animaux, ou dans un endroit peu aéré peut vite tourner à la catastrophe.
|
||||
|
||||
## Fixer vos disques durs
|
||||
Idéalement, vos disques durs doivent être fixés pour éviter les vibrations qui peuvent accélérer l'usure du matériel voire atténuer ses performances, notamment s'il y a un autre disque à côté.
|
||||
|
||||
## Réduire la swapiness pour les cartes SD et disques SSD
|
||||
Si vous utilisez un fichier de swap avec un SSD ou une carte SD avec une swapiness trop élevée, votre support de stockage pourrait rendre l'âme prématurément en raison d'un trop grand nombre d'écritures.
|
||||
|
||||
Pour éviter ça:
|
||||
```
|
||||
cat /proc/sys/vm/swappiness
|
||||
```
|
||||
Si elle est au-dessus de 10:
|
||||
```
|
||||
sysctl vm.swappiness=10
|
||||
nano /etc/sysctl.conf
|
||||
```
|
||||
Et éditer la valeur `vm.swapiness`.
|
||||
|
||||
## Redondance de stockage
|
||||
Afin de limiter les pannes matérielles des supports de stockage, il peut être pertinent de mettre en place une grappe de disques en miroir (RAID, ZFS). L'idée ici est que tout ce qui est écrit sur un disque le sera sur l'autre. Ainsi, si l'un tombe en panne, l'autre continue de fonctionner et le serveur est toujours pleinement fonctionnel.
|
||||
|
||||
Il existe aussi des grappes plus évoluées qui maximisent la tolérance de panne (panne de 2 disques comme le RAID6) ou le stockage (voir RAID 5).
|
||||
|
||||
Toutefois, ces techniques de grappes de disques ne devraient pas être considérées comme des copies de sauvegarde. Une grappe RAID devrait être considérée comme un seul support de stockage. En effet, si cette technique permet d'éviter de devoir réinstaller en cas de crash probable d'un disque, on est loin du risque zéro.
|
||||
|
||||
Quelques exemples de situations connues des administrateurs systèmes professionnels:
|
||||
* les disques d'une grappe montée avec des disques de la même marque peuvent tomber en panne quasiment en même temps en moins de quelques heures
|
||||
* sans monitoring de la santé des disques, il y a de fortes chances que l'on ne remarque la panne d'un disque de la grappe que lorsqu'un deuxième tombe en panne (><)
|
||||
* si on n'a pas de disque de rechange, le délai d'achat peut aboutir à un crash de l'autre disque
|
||||
* un disque à moitié fonctionnel qui produit des erreurs peut propager son erreur à travers la grappe
|
||||
* les connectiques des disques ou le contrôleur RAID peuvent produire des erreurs aussi ou tomber en panne
|
||||
* plus on complexifie l'architecture avec de nombreux composants, plus il y a de chances que l'un d'eux tombe en panne
|
||||
|
||||
!!! Si vous souhaitez mettre en place une grappe RAID ou utiliser btrfs, le plus simple est de le faire à l'installation avec l'iso YunoHost en mode expert (lors du partitionnement du système).
|
||||
|
|
@ -0,0 +1,49 @@
|
|||
---
|
||||
title: Avoid hardware failure
|
||||
template: docs
|
||||
taxonomy:
|
||||
category: docs
|
||||
routes:
|
||||
default: '/backup/avoid_hardware_failure'
|
||||
page-toc:
|
||||
active: true
|
||||
depth: 3
|
||||
---
|
||||
|
||||
|
||||
## Physically secure your server
|
||||
Very often people who self-host don't have proper storage for their system. Leaving the server in several parts, in a high traffic area, accessible to children or pets, or in a poorly ventilated area can quickly turn into a disaster.
|
||||
|
||||
## Secure your hard drives
|
||||
Ideally, your hard disks should be fixed to avoid vibrations which can accelerate the wear of the equipment or even reduce its performance, especially if there is another disk next to it.
|
||||
|
||||
## Reduce swapiness for SD cards and SSDs
|
||||
If you use a swap file with an SSD or SD card with too much swapiness, your storage media could give up the ghost prematurely due to too many writes.
|
||||
|
||||
To avoid this:
|
||||
```
|
||||
cat /proc/sys/vm/swappiness
|
||||
```
|
||||
If it is above 10:
|
||||
```
|
||||
sysctl vm.swappiness=10
|
||||
nano /etc/sysctl.conf
|
||||
```
|
||||
And edit the value `vm.swapiness`.
|
||||
|
||||
## Storage redundancy
|
||||
In order to limit hardware failures of storage media, it can be relevant to set up a cluster of mirrored disks (RAID, ZFS). The idea here is that everything that is written to one disk will be written to the other. This way, if one fails, the other continues to work and the server is still fully functional.
|
||||
|
||||
There are also more advanced clusters that maximize fault tolerance (failure of 2 disks like RAID6) or storage (see RAID 5).
|
||||
|
||||
However, these disk clustering techniques should not be considered as backups. A RAID array should be considered as a single storage medium. Indeed, if this technique avoids having to reinstall in case of a probable disk crash, it is far from zero risk.
|
||||
|
||||
Some examples of situations known to professional system administrators:
|
||||
* the disks of a cluster mounted with disks of the same brand can fail almost at the same time within a few hours
|
||||
* without monitoring the health of the disks, there is a good chance that the failure of one disk in the cluster will only be noticed when a second one fails (><)
|
||||
* if you don't have a spare disk, the delay in purchasing one may result in the other disk crashing
|
||||
* a half-functional disk that produces errors can propagate its error through the cluster
|
||||
* the disk connectors or the RAID controller can also produce errors or fail
|
||||
* the more complex you make the architecture with many components, the more likely it is that one of them will fail
|
||||
|
||||
!!! If you want to set up a RAID array or use btrfs, the easiest way is to do it at installation with the YunoHost iso in expert mode (when partitioning the system).
|
||||
|
|
@ -0,0 +1,129 @@
|
|||
---
|
||||
title: Inclure/exclure des fichiers
|
||||
template: docs
|
||||
taxonomy:
|
||||
category: docs
|
||||
routes:
|
||||
default: '/backup/include_exclude_files'
|
||||
page-toc:
|
||||
active: true
|
||||
depth: 3
|
||||
---
|
||||
|
||||
## Inclure des fichiers
|
||||
|
||||
YunoHost sait en général déjà ce qui doit être sauvegardé. Toutefois, si vous avez procédé à des modifications manuelles, par exemple en installant une app en dehors du système d'applications de YunoHost, vous pouvez avoir envie d'étendre le mécanisme de YunoHost pour spécifier d'autres fichiers à sauvegarder.
|
||||
|
||||
Par défaut, si des configurations suivies par YunoHost sont modifiées, elles seront sauvegardées. En revanche, une base de données ou une app ajoutée à la main, des modifs sur certaines configurations non suivies, ne le seront pas.
|
||||
|
||||
Vous pouvez créer un hook de sauvegarde et un hook de restauration pour ajouter des données à sauvegarder. Ci-dessous un exemple:
|
||||
|
||||
/etc/yunohost/hooks.d/backup/99-conf_custom
|
||||
```bash
|
||||
#!/bin/bash
|
||||
|
||||
# Source YNH helpers
|
||||
source /usr/share/yunohost/helpers
|
||||
|
||||
ynh_backup_dest (){
|
||||
YNH_CWD="${YNH_BACKUP_DIR%/}/$1"
|
||||
mkdir -p $YNH_CWD
|
||||
cd "$YNH_CWD"
|
||||
}
|
||||
|
||||
# Exit hook on subcommand error or unset variable
|
||||
ynh_abort_if_errors
|
||||
|
||||
# Openvpn
|
||||
ynh_backup_dest "conf/custom/openvpn"
|
||||
ynh_backup "/etc/sysctl.d/openvpn.conf"
|
||||
ynh_backup "/etc/openvpn"
|
||||
ynh_backup "/etc/fail2ban/jail.d/openvpn.conf"
|
||||
ynh_backup "/etc/fail2ban/filter.d/openvpn.conf"
|
||||
|
||||
# Samba
|
||||
ynh_backup_dest "conf/custom/samba"
|
||||
ynh_backup "/etc/samba"
|
||||
ynh_backup "/var/lib/samba"
|
||||
ynh_backup "/etc/yunohost/hooks.d/post_user_create/99-samba"
|
||||
ynh_backup "/etc/yunohost/hooks.d/post_user_delete/99-samba"
|
||||
ynh_backup --src_path="/etc/yunohost/hooks.d/post_user_update/99-samba" --not_mandatory
|
||||
ynh_backup "/etc/cron.daily/clean-trash"
|
||||
|
||||
# MISC
|
||||
ynh_backup_dest "conf/custom/misc"
|
||||
ynh_backup "/etc/sysctl.d/noipv6.conf"
|
||||
ynh_backup "/usr/local/bin/"
|
||||
ynh_backup "/etc/yunohost/hooks.d/backup/99-conf_custom"
|
||||
ynh_backup "/etc/yunohost/hooks.d/restore/99-conf_custom"
|
||||
```
|
||||
|
||||
/etc/yunohost/hooks.d/restore/99-conf_custom
|
||||
```bash
|
||||
#!/bin/bash
|
||||
|
||||
# Source YNH helpers
|
||||
source /usr/share/yunohost/helpers
|
||||
|
||||
ynh_restore_dest (){
|
||||
YNH_CWD="${YNH_BACKUP_DIR%/}/$1"
|
||||
cd "$YNH_CWD"
|
||||
}
|
||||
|
||||
# Exit hook on subcommand error or unset variable
|
||||
ynh_abort_if_errors
|
||||
|
||||
# Openvpn
|
||||
app="custom_openvpn" # Cette variable est importante pour le helper suivant
|
||||
ynh_install_app_dependencies "openvpn openvpn-auth-ldap samba"
|
||||
|
||||
ynh_restore_dest "conf/custom/openvpn"
|
||||
ynh_restore_file "/etc/sysctl.d/openvpn.conf"
|
||||
ynh_restore_file "/etc/openvpn"
|
||||
ynh_restore_file "/etc/fail2ban/jail.d/openvpn.conf"
|
||||
ynh_restore_file "/etc/fail2ban/filter.d/openvpn.conf"
|
||||
|
||||
# Samba
|
||||
app="custom_samba" # Cette variable est importante pour le helper suivant
|
||||
ynh_install_app_dependencies "samba"
|
||||
|
||||
ynh_restore_dest "conf/custom/samba"
|
||||
ynh_restore_file "/etc/samba"
|
||||
ynh_restore_file "/var/lib/samba"
|
||||
ynh_restore_file "/etc/yunohost/hooks.d/post_user_create/99-samba"
|
||||
ynh_restore_file "/etc/yunohost/hooks.d/post_user_delete/99-samba"
|
||||
ynh_restore_file --src_path="/etc/yunohost/hooks.d/post_user_update/99-samba" --not_mandatory
|
||||
ynh_restore_file "/etc/cron.daily/clean-trash"
|
||||
chown -R openvpn:openvpn /etc/openvpn
|
||||
|
||||
# MISC
|
||||
ynh_restore_dest "conf/custom/misc"
|
||||
ynh_restore_file "/etc/sysctl.d/noipv6.conf"
|
||||
ynh_restore_file "/usr/local/bin/"
|
||||
ynh_restore_file "/etc/yunohost/hooks.d/backup/99-conf_custom"
|
||||
ynh_restore_file "/etc/yunohost/hooks.d/restore/99-conf_custom"
|
||||
```
|
||||
|
||||
## Exclure des fichiers
|
||||
Il n'existe pas de mécanisme pour exclure d'une sauvegarde au format YunoHost des fichiers spécifiques, en dehors des 2 options présentées ci-dessous:
|
||||
|
||||
### Éviter de sauvegarder certains dossiers du `/home`
|
||||
Si besoin, vous pouvez spécifier que certains dossiers `home` d'utilisateurs ou utilisatrices ne soient pas sauvegardés par la commande `yunohost backup`, en créant un fichier vide nommé `.nobackup` à l'intérieur.
|
||||
|
||||
### Ne pas sauvegarder les grosses quantités de données
|
||||
|
||||
Certaines apps comme Nextcloud sont potentiellement rattachées à des quantités importantes de données. Il est possible de ne pas les sauvegarder par défaut. Dans ce cas, on dit que l'app "sauvegarde uniquement le core" (de l'app).
|
||||
Lors d'une mise à jour, les apps contenant une grande quantité de données effectuent généralement une sauvegarde sans ces données.
|
||||
|
||||
Pour désactiver temporairement la sauvegarde des données volumineuses, pour les applications qui implémentent cette fonctionnalité, vous pouvez définir la variable `BACKUP_CORE_ONLY`. Pour ce faire, la variable doit être définie avant la commande de backup :
|
||||
```bash
|
||||
BACKUP_CORE_ONLY=1 yunohost backup create --apps nextcloud
|
||||
```
|
||||
|
||||
Faites montre de prudence : il vous faudra alors sauvegarder vous-même les données des utilisateurs et utilisatrices de Nextcloud.
|
||||
|
||||
Si vous souhaitez que ce comportement soit permanent:
|
||||
```bash
|
||||
yunohost app setting nextcloud do_not_backup_data -v 1
|
||||
```
|
||||
|
||||
|
|
@ -0,0 +1,133 @@
|
|||
---
|
||||
title: Include or exclude files
|
||||
template: docs
|
||||
taxonomy:
|
||||
category: docs
|
||||
routes:
|
||||
default: '/backup/include_exclude_files'
|
||||
page-toc:
|
||||
active: true
|
||||
depth: 3
|
||||
---
|
||||
|
||||
## Include files
|
||||
|
||||
YunoHost usually already knows what needs to be backed up. However, if you have made manual changes, such as installing an app outside of the YunoHost application system, you may want to extend YunoHost's mechanism to specify other files to be backed up.
|
||||
|
||||
By default, if configurations tracked by YunoHost are changed, they will be backed up. On the other hand, a database or an app added by hand, changes on some configurations not tracked, will not be backed up.
|
||||
|
||||
You can create a backup hook and a restore hook to add data to backup. Here is an example:
|
||||
|
||||
|
||||
/etc/yunohost/hooks.d/backup/99-conf_custom
|
||||
```bash
|
||||
#!/bin/bash
|
||||
|
||||
# Source YNH helpers
|
||||
source /usr/share/yunohost/helpers
|
||||
|
||||
ynh_backup_dest (){
|
||||
YNH_CWD="${YNH_BACKUP_DIR%/}/$1"
|
||||
mkdir -p $YNH_CWD
|
||||
cd "$YNH_CWD"
|
||||
}
|
||||
|
||||
# Exit hook on subcommand error or unset variable
|
||||
ynh_abort_if_errors
|
||||
|
||||
# Openvpn
|
||||
ynh_backup_dest "conf/custom/openvpn"
|
||||
ynh_backup "/etc/sysctl.d/openvpn.conf"
|
||||
ynh_backup "/etc/openvpn"
|
||||
ynh_backup "/etc/fail2ban/jail.d/openvpn.conf"
|
||||
ynh_backup "/etc/fail2ban/filter.d/openvpn.conf"
|
||||
|
||||
# Samba
|
||||
ynh_backup_dest "conf/custom/samba"
|
||||
ynh_backup "/etc/samba"
|
||||
ynh_backup "/var/lib/samba"
|
||||
ynh_backup "/etc/yunohost/hooks.d/post_user_create/99-samba"
|
||||
ynh_backup "/etc/yunohost/hooks.d/post_user_delete/99-samba"
|
||||
ynh_backup --src_path="/etc/yunohost/hooks.d/post_user_update/99-samba" --not_mandatory
|
||||
ynh_backup "/etc/cron.daily/clean-trash"
|
||||
|
||||
# MISC
|
||||
ynh_backup_dest "conf/custom/misc"
|
||||
ynh_backup "/etc/sysctl.d/noipv6.conf"
|
||||
ynh_backup "/usr/local/bin/"
|
||||
ynh_backup "/etc/yunohost/hooks.d/backup/99-conf_custom"
|
||||
ynh_backup "/etc/yunohost/hooks.d/restore/99-conf_custom"
|
||||
```
|
||||
|
||||
/etc/yunohost/hooks.d/restore/99-conf_custom
|
||||
```bash
|
||||
#!/bin/bash
|
||||
|
||||
# Source YNH helpers
|
||||
source /usr/share/yunohost/helpers
|
||||
|
||||
ynh_restore_dest (){
|
||||
YNH_CWD="${YNH_BACKUP_DIR%/}/$1"
|
||||
cd "$YNH_CWD"
|
||||
}
|
||||
|
||||
# Exit hook on subcommand error or unset variable
|
||||
ynh_abort_if_errors
|
||||
|
||||
# Openvpn
|
||||
app="custom_openvpn" # This variable is important for the following helper
|
||||
ynh_install_app_dependencies "openvpn openvpn-auth-ldap samba"
|
||||
|
||||
ynh_restore_dest "conf/custom/openvpn"
|
||||
ynh_restore_file "/etc/sysctl.d/openvpn.conf"
|
||||
ynh_restore_file "/etc/openvpn"
|
||||
ynh_restore_file "/etc/fail2ban/jail.d/openvpn.conf"
|
||||
ynh_restore_file "/etc/fail2ban/filter.d/openvpn.conf"
|
||||
|
||||
# Samba
|
||||
app="custom_samba" # This variable is important for the following helper
|
||||
ynh_install_app_dependencies "samba"
|
||||
|
||||
ynh_restore_dest "conf/custom/samba"
|
||||
ynh_restore_file "/etc/samba"
|
||||
ynh_restore_file "/var/lib/samba"
|
||||
ynh_restore_file "/etc/yunohost/hooks.d/post_user_create/99-samba"
|
||||
ynh_restore_file "/etc/yunohost/hooks.d/post_user_delete/99-samba"
|
||||
ynh_restore_file --src_path="/etc/yunohost/hooks.d/post_user_update/99-samba" --not_mandatory
|
||||
ynh_restore_file "/etc/cron.daily/clean-trash"
|
||||
chown -R openvpn:openvpn /etc/openvpn
|
||||
|
||||
# MISC
|
||||
ynh_restore_dest "conf/custom/misc"
|
||||
ynh_restore_file "/etc/sysctl.d/noipv6.conf"
|
||||
ynh_restore_file "/usr/local/bin/"
|
||||
ynh_restore_file "/etc/yunohost/hooks.d/backup/99-conf_custom"
|
||||
ynh_restore_file "/etc/yunohost/hooks.d/restore/99-conf_custom"
|
||||
```
|
||||
|
||||
|
||||
|
||||
## Exclude files
|
||||
There is no mechanism to exclude specific files from a YunoHost backup, other than the 2 options presented below:
|
||||
|
||||
### Avoid backing up certain `/home` folders
|
||||
If needed, you can specify that certain user `home` folders not be backed up by the `yunohost backup` command, by creating an empty file named `.nobackup` inside.
|
||||
|
||||
### Do not backup large amounts of data
|
||||
|
||||
Some apps like Nextcloud are potentially attached to large amounts of data. It is possible to not backup them by default. In this case, the app is said to "backup only the core" (of the app).
|
||||
During an update, apps containing a large amount of data usually make a backup without these data.
|
||||
|
||||
|
||||
To temporarily disable backup of large data, for applications that implement this feature, you can set the `BACKUP_CORE_ONLY` variable. To do this, the variable must be set before the backup command:
|
||||
```bash
|
||||
BACKUP_CORE_ONLY=1 yunohost backup create --apps nextcloud
|
||||
```
|
||||
|
||||
Be careful: you will have to backup Nextcloud users' data yourself.
|
||||
|
||||
If you want this behavior to be permanent:
|
||||
```bash
|
||||
yunohost app setting nextcloud do_not_backup_data -v 1
|
||||
```
|
||||
|
||||
|
|
@ -0,0 +1,57 @@
|
|||
---
|
||||
title: Méthodes personnalisées
|
||||
template: docs
|
||||
taxonomy:
|
||||
category: docs
|
||||
routes:
|
||||
default: '/backup/custom_backup_methods'
|
||||
page-toc:
|
||||
active: true
|
||||
depth: 3
|
||||
---
|
||||
|
||||
Il est possible de créer votre propre méthode de sauvegarde et de la lier au système de collecte de fichiers à sauvegarder de YunoHost. Ceci peut être utile si vous souhaitez utiliser votre propre logiciel de sauvegarde ou mener des opérations de montages démontages de disques par exemple.
|
||||
|
||||
Cette opération se fait à l'aide d'un hook et vous permettra de lancer une sauvegarde de cette façon:
|
||||
```
|
||||
yunohost backup create --method custom
|
||||
```
|
||||
|
||||
Ci-dessous, un exemple simpliste qui peut permettre de mettre en place un backup rotationnel avec différents disques que l'on change toutes les semaines:
|
||||
|
||||
/etc/yunohost/hooks.d/backup_method/05-custom
|
||||
```bash
|
||||
#!/bin/bash
|
||||
set -euo pipefail
|
||||
|
||||
work_dir="$2"
|
||||
name="$3"
|
||||
repo="$4"
|
||||
size="$5"
|
||||
description="$6"
|
||||
|
||||
case "$1" in
|
||||
need_mount)
|
||||
# Set false if your method can itself put files in good place in your archive
|
||||
true
|
||||
;;
|
||||
backup)
|
||||
mount /dev/sda1 /mnt/hdd
|
||||
if [[ "$(df /mnt/hdd | tail -n1 | cut -d" " -f1)" != "/dev/sda1" ]]
|
||||
then
|
||||
exit 1
|
||||
fi
|
||||
pushd "$work_dir"
|
||||
current_date=$(date +"%Y-%m-%d_%H:%M")
|
||||
cp -a "${work_dir}" "/mnt/hdd/${current_date}_$name"
|
||||
popd
|
||||
umount /mnt/hdd
|
||||
;;
|
||||
*)
|
||||
echo "hook called with unknown argument \`$1'" >&2
|
||||
exit 1
|
||||
;;
|
||||
esac
|
||||
|
||||
exit 0
|
||||
```
|
||||
|
|
@ -0,0 +1,58 @@
|
|||
---
|
||||
title: Custom backup methods
|
||||
template: docs
|
||||
taxonomy:
|
||||
category: docs
|
||||
routes:
|
||||
default: '/backup/custom_backup_methods'
|
||||
page-toc:
|
||||
active: true
|
||||
depth: 3
|
||||
---
|
||||
|
||||
|
||||
It is possible to create your own backup method and link it to YunoHost's backup file collection system. This can be useful if you want to use your own backup software or conduct disk mount/dismount operations for example.
|
||||
|
||||
This operation is done with a hook and will allow you to launch a backup this way:
|
||||
```
|
||||
yunohost backup create --method custom
|
||||
```
|
||||
|
||||
Below is a simplistic example that can be used to set up a rotational backup with different disks that are changed every week:
|
||||
|
||||
/etc/yunohost/hooks.d/backup_method/05-custom
|
||||
```bash
|
||||
#!/bin/bash
|
||||
set -euo pipefail
|
||||
|
||||
work_dir="$2"
|
||||
name="$3"
|
||||
repo="$4"
|
||||
size="$5"
|
||||
description="$6"
|
||||
|
||||
case "$1" in
|
||||
need_mount)
|
||||
# Set false if your method can itself put files in good place in your archive
|
||||
true
|
||||
;;
|
||||
backup)
|
||||
mount /dev/sda1 /mnt/hdd
|
||||
if [[ "$(df /mnt/hdd | tail -n1 | cut -d" " -f1)" != "/dev/sda1" ]]
|
||||
then
|
||||
exit 1
|
||||
fi
|
||||
pushd "$work_dir"
|
||||
current_date=$(date +"%Y-%m-%d_%H:%M")
|
||||
cp -a "${work_dir}" "/mnt/hdd/${current_date}_$name"
|
||||
popd
|
||||
umount /mnt/hdd
|
||||
;;
|
||||
*)
|
||||
echo "hook called with unknown argument \`$1'" >&2
|
||||
exit 1
|
||||
;;
|
||||
esac
|
||||
|
||||
exit 0
|
||||
```
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
---
|
||||
title: Migrer ou fusionner des serveurs
|
||||
template: docs
|
||||
taxonomy:
|
||||
category: docs
|
||||
routes:
|
||||
default: '/backup/migrate_or_merge_servers'
|
||||
page-toc:
|
||||
active: true
|
||||
depth: 3
|
||||
---
|
||||
|
||||
## Migrer un serveur
|
||||
|
||||
Si le système d'archive de YunoHost est assez pratique pour migrer un serveur, on peut aussi [migrer de serveur à serveur avec rsync](https://www.man42.net/blog/2017/07/how-to-migrate-a-debian-server/).
|
||||
|
||||
## Fusionner 2 serveurs YunoHost
|
||||
Si vous fusionnez 2 serveurs ensemble, vous devrez recréer les utilisateurs et utilisatrices, ainsi que les domaines et les permissions du premier serveur sur le serveur de destination. Puis vous pourrez restaurer app par app.
|
||||
|
||||
!! Il existe tout de même une limite concernant les apps qui ont le même ID. Il ne sera pas possible de les restaurer facilement. Attention également à ne pas supprimer l'app éponyme du serveur de destination :/
|
||||
|
|
@ -0,0 +1,21 @@
|
|||
---
|
||||
title: Migrate or merge servers
|
||||
template: docs
|
||||
taxonomy:
|
||||
category: docs
|
||||
routes:
|
||||
default: '/backup/migrate_or_merge_servers'
|
||||
page-toc:
|
||||
active: true
|
||||
depth: 3
|
||||
---
|
||||
|
||||
|
||||
## Migrate a server
|
||||
|
||||
If YunoHost's archive system is convenient enough to migrate a server, you can also [migrate from server to server with rsync](https://www.man42.net/blog/2017/07/how-to-migrate-a-debian-server/).
|
||||
|
||||
## Merge 2 YunoHost servers
|
||||
If you merge 2 servers together, you will need to recreate the users, domains and permissions of the first server on the destination server. Then you can restore app by app.
|
||||
|
||||
!! There is a limitation concerning apps that have the same ID. It will not be possible to restore them easily. Also be careful not to delete the eponymous app from the destination server :/
|
||||
Loading…
Reference in a new issue