Le serveur de sauvegarde est un serveur physique hébergé chez moi. Il est configuré avec 4 disques durs de 2 To en Raid10, qui accueillent une partition /home. Les partitions systèmes sont sur un petit SSD sata.

Réseau

Dans les notes de mise à jour vers Trixe, il est indiqué que isc_dhcp, un client et serveur DHCP, est déprécié. Il est aussi mis que ifupdown, le paquet historique pour la gestion des interfaces est vieillissant, et qu’il vaut mieux utiliser des gestionnaires de réseau plus récent. Je change donc la gestion du réseau de Debian vers systemd-network.

# Configuration par DHCP
sudo nano /etc/systemd/network/dhcp.network
-------------------------------------------                                                                         
[Match]
Name=en*

[Network]
DHCP=yes

On peut ensuite démarrer la gestion du réseau par systemd, puis vérifier les interfaces :

sudo systemctl start systemd-networkd
sudo networkctl list
# Pour recharger la config si on la modifie
sudo networkctl reload
# Tester le réseau
sudo ping petitmote.fr

Si tout va bien :

sudo apt purge ifupdown isc_dhcp
sudo rm -R /etc/network
sudo systemctl enable systemd-network

Monitoring

Le serveur de sauvegarde est un serveur physique. J’ai donc accès à des informations utiles sur les périphériques physiques. Pour pouvoir monitorer, à la main, certaines informations, j’ai accès à quelques paquets.

sudo apt install lm_sensors
# Permet de détecter s’il faut activer des drivers en plus pour afficher certaines informations
sudo sensors-detect
# Liste les températures détectées
sensors

Cette command permet notamment d’accéder à la température CPU, et peut-être à la température GPU (mais je n’en ai pas sur ce serveur).

Pour les températures des disques durs, ce n’est pas permis par lm_sensors. Du coup, il faut aller taper dans les données SMART :

sudo apt install smartmontools
# Affiche toutes les informations SMART
sudo smartctl -a /dev/sdx
# Affiche seulement la température
sudo smartctl -a /dev/sdx | grep Temperature

smartmontools vient également avec smartd, un démon qui scan les données SMART toutes les 30 minutes et peut faire un mail de notification. Il faut lister les disques à scanner dans le fichier de configuration :

sudo nano /etc/smartd.conf
--------------------------
DEFAULT -a -I 190 -I 194 -W 2,40,45 -n standby,10,q -m root -M test -M daily
/dev/sda -s S/../.././12
/dev/sdb -s S/../.././13
/dev/sdc -s S/../.././14
/dev/sdd -s S/../.././15
/dev/sde -s S/../.././16

Ma configuration actuelle correspond à ça. Je décale les selftests d’une heure pour qu’ils ne tombent pas tous en même temps. Je check tout, je ne lance pas les vérifs si les disques sont en standby, comme ça peut vouloir dire qu’ils ne tournent pas (avec une limite à 10 tests manqués, soit 5h). J’envoie un mail à l’utilisateur root (qui redirige vers une vraie adresse mail). J’envoie un mail de test au démarrage, et s’il y a une erreur, je recevrai une alerte quotidienne jusqu’à ce que ce soit réglé.

Pour appliquer ça :

sudo service smartd reload

Accès utilisateur

Créer le compte d’accès

Pour créer le compte utilisateur :

sudo adduser username

Le mot de passe est généré dans mon keepass. Il ne servira pas à grand chose, vu que l’accès ne sera autorisé que par clé SSH.

Je crée l’accès SSH :

sudo -u username mkdir /home/username/.ssh
sudo -u username nano /home/username/.ssh/authorized_keys
# Je copie-colle la clé publique, puis je donne les bons droits
sudo chmod 700 /home/username/.ssh
sudo chmod 600 /home/username/.ssh/authorized_keys

Restreindre l’accès SSH

Il est possible de restreindre l’accès SSH, notamment à certaines IP ou commandes. Cela peut permettre de verrouiller les sauvegardes à de la nouvelle sauvegarde uniquement et éviter les suppressions de sauvegardes.

Pour cela, dans le authorized_keys, il est possible d’écrire les lignes dans le format (exemple avec borg, et une limite de stockage sur le dépôt de borg) :

restrict,from="ipv4...xxx,ipv6:::",command="borg serve --append-only --restrict-to-repository /chemin/du/depot/borg --storage-quota 200G" <clé SSH>

Cela permet également de confiner les utilisateurs SSH à leur seul utilisateur, en plus de la configuration au niveau du pare-feu.

Quotas

Configuration système

Pour activer les quotas, la partition doit être montée avec l’option qui va bien :

sudo nano /etc/fstab
--------------------
# /home was on /dev/md0 during installation
UUID=8757aad9-xxxx-xxxx-xxxx-cf97cde20f10 /home           ext4    defaults,usrquota,grpquota        0       2

Les options usrquota et grpquota permettent de définir des quotas pour les utilisateurs ou pour les groupes. Après édition du fstab, comme demandé dans le fichier, on le recharge pour systemd :

sudo systemctl daemon-reload

Puis on redémarre.

On installe l’outil nécessaire :

sudo apt install quota

Pour les quotas, ils peuvent être gérés directement par ext4, mais ce n’est pas activé par défaut. Le mieux est de l’activer à l’installation du système. Sinon, on peut le faire après, mais il faut démonter la partition. La doc de Redhat est meilleure que celle de Debian. Pour ne pas occuper /home, je me connecte directement sur / :

ssh user@192.168.1.XX -p XXXX -t "cd / ; bash --login"
sudo umount /home
sudo tune2fs -O quota /dev/md0
sudo reboot

Puis :

sudo quotaon -ugv /home

Les quotas devraient maintenant être activés. Il faut les paramétrer par utilisateur.

Quota utilisateur

Les quotas se font par nombre de blocs ou d’inodes. Pour savoir la taille d’un bloc :

$ sudo blockdev --getbsz /dev/md0
4096

La valeur est en b, soit 4kb ici. Si mon bloc fait 4096b, et que je veux donner 100GB, il me faut logiquement 100x1024x1024x1024x8/4096 = 209 715 200 blocs. À noter qu’il vaut mieux donner un peu large, parce qu’un bloc même partiellement rempli va être considéré comme entièrement occupé, donc l’espace réelle disponible sera un peu inférieur, surtout en cas de nombreux fichiers de petites tailles.

La commande pour assigner un quota à un utilisateur ouvre un éditeur :

sudo edquota username
---------------------
Quotas disque pour user username (uid XXXX) :
 Système de fichiers           blocs       souple     stricte   inodes    souple   stricte
  /dev/md0                        40  209715200   314572800       10         0         0

Exemple, avec mon utilisateur de sauvegarde de mon PC fixe. 200 Go en limite souple, 250 Go en limite hard.

La limite souple (ou soft) avertit quand l’utilisateur dépasse son quota. La limite stricte (ou hard) bloque totalement l’écriture de nouveaux blocs tant qu’on n’est pas repassé sous la limite. Par défaut, la limite souple devient stricte à la fin d’une période de sursis. Cette période de sursis est configurable avec :

sudo edquota -t
---------------
Sursis avant l'application des limites souples pour users :
Unités de temps peuvent être : days (jours), hours (heures), minutes, ou seconds
  Système de fichiers  période de sursis bloc  période de sursis inode
  /dev/md0                      14days                  14days

Pour vérifier que le quota fonctionne :

$ sudo quota -v username
Disk quotas for user username (uid XXXX): 
Système fichiers   blocs   quota  limite  sursisfichiers   quota  limite  sursis
       /dev/md0      40  1600000000 2000000000              10       0       0   

Pour qu’un avertissement puisse être envoyé, il faut penser à ajouter une adresse mail à l’user :

sudo nano /etc/aliases

Applications

Certaines applications de sauvegarde fonctionnent mieux avec un logiciel présent sur le serveur. Je fais la liste des paquets installés ici :

sudo apt install borgbackup