Comment configurer un serveur pour votre petite entreprise

Un partage de fichiers de bureau et une application publique de réservation exigent des machines, des budgets et des plans de reprise différents. Pour savoir comment construire un serveur, commencez par les tâches qu’il doit maintenir en fonctionnement. Partir de zéro consiste à choisir et assembler des composants compatibles, puis à installer un système d’exploitation et à configurer un service utilisable.

Pour les documents locaux, une tour silencieuse peut être un achat judicieux. Pour une application accessible sur Internet, la location peut éviter les travaux liés au matériel et aux locaux. Dans les deux cas, quelqu’un doit être responsable des accès, des mises à jour et de la reprise.

Avant de manipuler le matériel, préparez les manuels des composants, un plan de travail dégagé et une protection antistatique recommandée par le fabricant. Pour la configuration, prévoyez un réseau filaire, une clé USB d’installation, un clavier et un écran locaux, un compte administrateur individuel et un second ordinateur pour les tests. Copiez les données existantes ailleurs avant de modifier l’organisation des disques.

Définir le besoin de l’entreprise avant de choisir le matériel

Un dossier partagé contenant des factures demande de la capacité et un accès fiable aux fichiers ; une application publique ajoute la connectivité externe et la maintenance applicative. Décrivez le besoin avant de concevoir le matériel autour d’une promotion sur un processeur ou de la RAM.

Utilisez une courte fiche de besoins :

• Nommez le service et les applications qui l’utiliseront. Listez les activités simultanées, comme l’ouverture de documents pendant une sauvegarde.
• Mesurez les données actuelles, leur croissance prévue et les versions conservées. Distinguez le stockage utilisable nécessaire de la somme des capacités inscrites sur les disques.
• Précisez si l’accès sera réservé au bureau ou public. Incluez les scanners, imprimantes et autres appareils locaux qui doivent y accéder.
• Fixez la perte de données acceptable, appelée objectif de point de reprise (RPO), et le délai acceptable de rétablissement du service, appelé objectif de temps de reprise (RTO).
• Désignez un administrateur et son remplaçant. Consignez le budget d’achat et le budget récurrent de fonctionnement.

Le nombre d’employés ne suffit pas à déterminer la capacité. Un jeu de fichiers représentatif et des tâches simultanées constituent un meilleur test de réception.

Comparer l’assemblage, l’achat et la location

Une tour près du commutateur du bureau permet les transferts locaux même en cas de panne Internet, tant que le réseau local et l’alimentation restent disponibles. Un serveur loué déplace le matériel ailleurs et rend l’accès du bureau dépendant de la connexion WAN. Les responsabilités se répartissent ainsi.

Choisissez l’assemblage si la souplesse des composants est utile et si quelqu’un peut diagnostiquer toute la machine. Préférez un modèle préassemblé avec assistance si le processus de réparation d’un fournisseur justifie le surcoût. Pour du reconditionné, vérifiez avant l’achat le suivi du micrologiciel, l’usure des disques, les tiroirs et câbles inclus, le bruit, la consommation et la garantie écrite.

En location, le choix VPS ou matériel dédié concerne les ressources et l’isolation. Une application modeste peut tenir sur un VPS ; des besoins soutenus ou la maîtrise du matériel peuvent justifier un serveur dédié. Les cœurs physiques et les vCPU de VPS ne sont pas des promesses de capacité interchangeables.

Envisager un VPS avant de construire votre serveur

Acheter du matériel engage de l’argent avant de connaître le comportement de la charge. L’assembler vous-même ajoute des vérifications de compatibilité et du montage. Un modèle préassemblé supprime cette étape, mais exige toujours de l’espace, de l’électricité, du refroidissement et un plan en cas de panne matérielle. Pour un site, une application ou un environnement de test qui n’a pas besoin de rester au bureau, la location permet de démarrer plus vite et de découvrir vos besoins réels.

Nos offres Linux VPS proposent de la RAM DDR5, du stockage NVMe rapide et une connectivité via des liaisons montantes d’hôte de 40 Gbps. Pour les charges exigeant une capacité vCPU dédiée, nos offres High Performance réservent cette capacité à votre serveur virtuel. Vous utilisez une infrastructure performante sans acheter le matériel ni héberger un service public sur la connexion Internet du bureau.

Vous gardez aussi la maîtrise des logiciels. Nos VPS sont non infogérés, avec un accès root complet par SSH. Vous choisissez le système, installez les applications et configurez les services. Mises à jour, sécurité et sauvegardes restent votre responsabilité, ce qui vous donne une expérience concrète de l’administration qu’exigerait votre propre serveur.

La facturation horaire permet de commencer avec peu de ressources. Avec les offres PAYG, vous pouvez redimensionner depuis le tableau de bord selon vos besoins, tandis que la surveillance gratuite des ressources vous aide à suivre l’utilisation. Notre garantie satisfait ou remboursé de 14 jours donne aux nouveaux clients deux semaines pour évaluer le service et demander un remboursement selon ses conditions s’il ne convient pas.

La location laisse aussi la possibilité de devenir propriétaire. Si vous construisez ensuite un serveur Linux physique, vous pourrez réinstaller vos logiciels, transférer fichiers et exports de bases de données, adapter la configuration et tout tester avant la bascule. L’expérience acquise sur le VPS vous accompagnera.

Adapter la configuration à la charge

Fichiers de bureau et documents partagés

Supposons environ 2 To de documents ordinaires, accessibles localement par Ethernet filaire. Envisagez une tour silencieuse avec un processeur moderne de 4 à 6 cœurs, 32 Go de RAM compatible, un SSD de démarrage de 500 Go et deux HDD de 4 To en miroir de données RAID1 logiciel Linux. Le miroir fournit environ la capacité brute d’un disque de 4 To avant surcoût du système de fichiers et espace réservé. Le SSD de démarrage reste un point de défaillance unique.

Utilisez du Gigabit Ethernet entre serveur, commutateur et clients, avec un onduleur compatible. Prévoyez un disque amovible de sauvegarde séparé de 8 To et une copie hors site protégée indépendamment. Versions et croissance des fichiers peuvent dépasser ce disque ; mesurez le volume modifié et la taille des sauvegardes conservées. Cette conception ne promet aucun débit pour le montage vidéo.

Une enveloppe indicative de 1 200 à 1 800 USD couvre matériel, onduleur et sauvegarde locale, hors taxes, main-d’œuvre, licences et frais hors site. L’installation ci-dessous met en œuvre ce scénario de fichiers de bureau.

Site public ou application légère

Supposons une petite base de données et peu de médias, avec initialement moins de 20 Go de données actives. Évaluez une location générique de 2 à 4 vCPU, 4 à 8 Go de RAM et 80 à 160 Go de SSD, en réservant de l’espace pour l’OS, les journaux et la croissance. Ces ressources exigent des tests de charge propres à l’application ; elles ne garantissent aucun nombre de visiteurs.

Une alternative physique pourrait avoir un processeur moderne de 4 à 6 cœurs, 16 Go de RAM et un SSD de 500 Go, dont la capacité disponible sera réduite par le formatage et l’OS. Elle n’a aucune redondance de disque. Incluez connexion filaire, onduleur et destination de sauvegarde indépendante dans une enveloppe matérielle hypothétique de 800 à 1 400 USD, avec les mêmes exclusions.

L’hébergement public depuis le bureau exige aussi un débit montant, un adressage et des conditions fournisseur adaptés. Prévoyez les correctifs, la disponibilité électrique et la maintenance applicative. C’est une décision de déploiement distincte ; le partage de fichiers ci-dessous n’installe aucune pile Web publique.

Services internes séparés et environnements de test

Supposons plusieurs services isolés totalisant moins de 400 Go de données actives. Un hôte indicatif dispose d’un processeur moderne de 8 cœurs, de 64 Go de RAM compatible et de SSD de 1 To en miroir, avec un périphérique de démarrage séparé si nécessaire. Cela fournit environ 1 To brut avant surcoûts ; chaque disque invité consomme ce pool partagé.

Allouez 8 + 8 + 16 Go de RAM aux invités, puis 8 Go à l’hôte et au stockage : 40 Go affectés et 24 Go disponibles. Ce calcul suit les exigences de Proxmox, mais ne démontre ni les performances CPU ni une densité d’invités prise en charge. Vérifiez VT/AMD-V, pilotes et licences des invités ; IOMMU devient utile pour l’attribution directe de périphériques. N’utilisez pas ZFS sur du RAID matériel.

Utilisez réseau filaire, onduleur et sauvegardes indépendantes des invités. Une enveloppe hypothétique de 1 800 à 3 000 USD inclut matériel, onduleur et sauvegarde locale, hors taxes, licences, main-d’œuvre et frais hors site. La virtualisation des serveurs sépare les environnements invités ; un hôte physique reste un point de défaillance unique.

Choisir des composants de serveur compatibles

Un processeur peut entrer dans son socket tout en exigeant une autre version du BIOS pour démarrer. Établissez une fiche de compatibilité autour du modèle exact de carte mère, puis vérifiez chaque composant connecté dans son manuel. Ces vérifications concernent les configurations précédentes ; aucune n’est un panier d’achat validé.

CPU

Choisissez la puissance de calcul selon l’application. Une tâche limitée par un thread occupé profite différemment du matériel qu’un logiciel répartissant le travail entre les cœurs. Le service de fichiers dépend aussi des disques et du réseau ; un CPU coûteux peut laisser le goulot d’étranglement intact.

Faites correspondre socket et chipset, trouvez le processeur exact dans la liste de compatibilité de la carte et notez le BIOS requis. La procédure ASUS de compatibilité CPU et mémoire indique où trouver ces listes. Demandez au vendeur si le BIOS fourni démarre votre CPU. Vérifiez aussi si l’installation exige des graphiques intégrés ou un affichage de gestion de la carte.

RAM

La capacité doit couvrir l’OS et les applications simultanées, avec une marge de croissance. Vérifiez génération DDR, capacité maximale, nombre de logements et ordre de peuplement du manuel. Acheter tout l’ensemble initial dans la liste de mémoire qualifiée réduit les combinaisons à résoudre vous-même.

UDIMM désigne une mémoire sans tampon ; RDIMM une mémoire à registres. Ces catégories diffèrent, et la présence d’ECC ne suffit pas à établir la compatibilité. La FAQ Supermicro sur la compatibilité de la mémoire à registres refuse explicitement les DIMM à registres pour la famille X11SCA citée. Si nécessaire, confirmez ECC sur le CPU, la carte et les modules. Gardez une possibilité d’extension sans remplacer tous les modules.

Le stockage

Séparez le périphérique système des données métier si cela clarifie réparation et reprise. Les SSD conviennent aux charges sensibles à la latence ; les HDD offrent de la place pour les documents ordinaires. Dans les deux cas, vérifiez usage prévu, garantie, endurance et disponibilité des remplacements avant de choisir seulement selon la capacité.

RAID1 conserve les données en miroir sur les deux disques. Il tolère la panne d’un membre, mais suppression, rançongiciel et perte du site exigent une sauvegarde indépendante. Vérifiez la capacité après formatage et réservez de l’espace de croissance. Faites correspondre interfaces SATA ou NVMe, dimensions, baies et câbles. Vérifiez si un logement M.2 désactive des ports SATA nécessaires aux disques de données.

Carte mère

Après avoir consigné compatibilité CPU/BIOS et liste mémoire QVL, vérifiez la prise en charge Linux des contrôleurs réseau et stockage intégrés, surtout sur les plateformes récentes.

Comptez les connecteurs SATA, sockets M.2, logements PCIe et prises de ventilateurs nécessaires. Consultez le tableau de partage des lignes : un SSD ou une carte peut réduire la connectivité d’un autre logement. Faites correspondre format et trous de fixation de la carte au boîtier. La gestion à distance aide sans écran proche, mais exige aussi un accès protégé et l’entretien du micrologiciel.

Interface réseau

Une carte réseau plus rapide n’accélère pas un commutateur, une connexion cliente ou un stockage plus lent. Vérifiez tout le chemin avant de payer une mise à niveau. Retenez le lien Gigabit du scénario de fichiers comme choix de planification, puis testez des copies simultanées avec des fichiers représentatifs.

Confirmez que l’interface dispose de pilotes pour votre version Linux. Une carte additionnelle exige un logement PCIe approprié, de l’espace et une connexion compatible. Incluez ports du commutateur et câblage dans la vérification d’achat : ils participent à la même décision de débit que la carte réseau du serveur.

Alimentation

Choisissez un bloc adapté au châssis et fournissant les connecteurs nécessaires à la carte mère, au CPU et aux disques. Incluez demande au démarrage et extension prévue dans l’estimation. Gardez une marge adaptée selon les fabricants ; une puissance élevée sur l’étiquette ne suffit pas.

Vérifiez les connexions d’alimentation principale et CPU, les prises des disques et la portée des câbles. Avec un bloc modulaire, utilisez uniquement les câbles fournis ou explicitement approuvés pour ce modèle exact. Vérifiez les remplacements si le boîtier utilise une alimentation propriétaire.

Refroidissement

Adaptez le refroidisseur au socket, aux limites de puissance du CPU et à l’espace du boîtier. Des modules mémoire hauts peuvent aussi gêner. Confirmez la présence du kit de fixation et suivez ses instructions pour la pâte thermique et l’ordre de serrage.

Prévoyez un passage d’air dégagé à travers disques et châssis. Ajouter des ventilateurs ne corrige ni un flux bloqué ni un placard piégeant l’air chaud. Vérifiez limites des prises et réglages de commande du manuel. Après montage, contrôlez les températures en charge représentative et ajustez avant mise en service.

Boîtier

Une tour silencieuse se place plus facilement au bureau qu’un matériel destiné à une salle dédiée. Vérifiez taille de carte mère, hauteur du refroidisseur, baies et longueur des cartes. Comptez les baies pour le démarrage, les disques de données initiaux et un remplacement ou une extension réaliste.

Vérifiez si tiroirs, vis et câbles sont inclus. Laissez l’espace nécessaire pour remplacer un disque sans démonter la machine. Gardez le boîtier accessible pour nettoyage et entretien, avec aérations dégagées et protection contre les chocs et débranchements accidentels.

Onduleur

Un onduleur laisse au serveur le temps de s’arrêter proprement lors d’une coupure. Choisissez-le selon charge prévue, autonomie fabricant et communication d’arrêt compatible Linux. Puissance en watts et autonomie répondent à des questions différentes.

Incluez le commutateur si la connexion locale doit rester disponible pendant une panne. Prévoyez le remplacement des batteries et testez l’arrêt propre selon le fabricant. Ne supposez pas qu’un onduleur maintiendra le bureau pendant une longue coupure. Aucune de ces charges n’exige de GPU sauf besoin applicatif spécifique.

Avant de commander, consignez les preuves à côté des pièces prévues :

Assembler et vérifier le matériel

Une entretoise mal placée peut toucher le dos de la carte et l’endommager. Suivez les manuels propres aux modèles, alimentation débranchée ; l’ordre ci-dessous est général et ne remplace pas leurs schémas.

1. Inventoriez pièces et outils. Confirmez la compatibilité CPU/BIOS avant d’ouvrir le socket. Conservez emballages et numéros de série pour les garanties.
2. Préparez le boîtier. Installez seulement les entretoises correspondant aux trous et retirez les autres. Les instructions ASUS de montage de carte mère expliquent le danger des entretoises supplémentaires. Installez une plaque E/S séparée si nécessaire.
3. Installez le CPU selon ses repères, sans forcer. Suivez la procédure du verrou. Les instructions d’installation du CPU du fabricant exigent d’abord de débrancher le cordon secteur. Montez le refroidisseur avec la pâte et la méthode prescrites ; branchez son ventilateur.
4. Installez la RAM dans les premiers logements indiqués jusqu’au verrouillage correct. Montez les périphériques M.2 avant que leur accès devienne difficile.
5. Fixez carte mère et alimentation. Montez les disques système et de données, puis raccordez données et alimentation. Ajoutez la carte réseau nécessaire.
6. Branchez alimentation carte mère/CPU, ventilateurs et panneau avant selon le manuel. Éloignez les câbles des ventilateurs. Vérifiez vis libres, câbles non soutenus et connecteurs partiellement engagés avant la mise sous tension.

Au premier démarrage, laissez finir le POST. Ouvrez UEFI et vérifiez CPU détecté, mémoire totale, chaque disque, ventilateurs et températures. Corrigez absences ou températures anormales avant d’installer les logiciels. Si une mise à jour du micrologiciel est nécessaire, suivez exactement le fabricant avec une alimentation stable.

Exécutez les diagnostics matériels disponibles du fabricant et un test mémoire adapté. Après installation, copiez un jeu de documents représentatif et essayez le travail simultané normal. Consignez erreurs, températures et durées comme preuves de réception. Un benchmark à vide ne prouve pas que le travail du bureau fonctionnera.

Installer Ubuntu et mettre le partage de fichiers en service

La configuration de fichiers exposera sur le LAN un partage authentifié nommé business. Utilisez Ubuntu Server 24.04 LTS amd64 sur du matériel compatible ; ses notes de version indiquent une maintenance jusqu’en mai 2029. Gardez une console locale pendant les modifications réseau.

Installer l’OS et monter le stockage de données

Téléchargez l’image actuelle de serveur 24.04 depuis Ubuntu et suivez la procédure Canonical de vérification d’image signée avant de créer la clé USB. Elle vérifie signature de somme de contrôle et somme de l’image ; ne copiez pas le hash d’un autre téléchargement.

Gardez le disque de sauvegarde indépendant débranché. Démarrez l’installateur et identifiez les disques internes par modèle, série et capacité. Dans le stockage personnalisé, placez partition EFI et système racine sur le SSD de démarrage. Créez un RAID1 logiciel MD avec les deux HDD de données vides, formatez-le en ext4 et montez-le sur /srv/business. Les instructions Canonical de configuration du stockage couvrent création et montage des périphériques MD.

Vérifiez le plan final avant de confirmer l’effacement. Le SSD doit contenir l’OS, le miroir /srv/business, et aucun disque de sauvegarde ne doit apparaître. Créez un administrateur individuel pendant l’installation. Après redémarrage, inspectez l’organisation :

lsblk -o NAME,SIZE,MODEL,SERIAL,FSTYPE,MOUNTPOINTS
findmnt --mountpoint /srv/business
cat /proc/mdstat

Confirmez que /srv/business est un système ext4 monté sur le périphérique MD prévu et que les deux membres du miroir sont présents et sains. Attendez la fin de la synchronisation initiale avant réception. Arrêtez-vous si le montage manque : créer des dossiers y placerait les fichiers métier sur le disque système.

Restreindre l’administration et l’accès réseau

Réservez l’adresse du serveur dans DHCP sur le routeur. Les exemples utilisent le serveur 192.168.10.10, le sous-réseau 192.168.10.0/24 et le poste administrateur 192.168.10.20. Remplacez-les par vos valeurs. Vérifiez paramètres LAN et adresse/masque client ; /24 décrit cet exemple, pas tous les bureaux. L’accès local ne demande ni IP publique ni DNS acheté.

Appliquez les mises à jour et installez les paquets :

sudo apt update
sudo apt upgrade
sudo apt install samba smbclient restic ufw

Pour administrer à distance, installez openssh-server, configurez une clé SSH administrateur et vérifiez-la dans une deuxième session. Gardez la première ouverte. Les instructions Canonical OpenSSH couvrent clés et vérifications. Exécutez sudo sshd -t après toute modification SSH et gardez l’accès par mot de passe jusqu’à ce que la clé fonctionne.

Pour SSH, remplacez adresse et port réel dans la première règle d’autorisation avant d’activer UFW. En administration uniquement locale, omettez cette règle. Les instructions Canonical du pare-feu couvrent l’accès limité à des sources :

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow proto tcp from 192.168.10.20 to any port 22
sudo ufw allow proto tcp from 192.168.10.0/24 to any port 445
sudo ufw enable
sudo ufw status verbose

Retestez la connexion administrateur. Le port 445 transporte l’accès SMB ; ne le redirigez pas sur le routeur Internet. Isolez le Wi-Fi invité sur un réseau sans accès au service du bureau. Une autorisation de sous-réseau ne distingue pas employés et invités sur ce même sous-réseau.

Créer un partage de fichiers authentifié

Donnez à chaque employé une identité Linux et des identifiants Samba distincts. Les instructions Ubuntu de contrôle d’accès Samba exigent que le compte Linux existe avant l’inscription. Pour un nouveau compte réservé aux fichiers nommé alex, exécutez :

sudo addgroup officefiles
sudo adduser --disabled-password --shell /usr/sbin/nologin alex
sudo adduser alex officefiles
sudo smbpasswd -a alex
sudo mkdir -p /srv/business/team
sudo chown root:officefiles /srv/business/team
sudo chmod 2770 /srv/business/team
sudo cp -a /etc/samba/smb.conf /etc/samba/smb.conf.before-business
sudoedit /etc/samba/smb.conf

Saisissez le mot de passe Samba d’Alex à l’invite. Le mot de passe Linux désactivé et le shell nologin séparent ce compte des accès administrateur ; ne l’ajoutez pas à sudo. Répétez compte, groupe et inscription Samba pour chaque employé, en créant officefiles une seule fois.

Le mode 2770 autorise propriétaire et groupe, refuse les autres et définit setgid afin que les nouveaux éléments héritent du groupe du dossier. Les règles Samba et les permissions Linux doivent toutes deux autoriser l’opération. Conservez la configuration globale et ajoutez ce seul partage :

[business]

    path = /srv/business/team

    browseable = yes

    guest ok = no

    read only = no

    valid users = @officefiles

    force group = officefiles

    create mask = 0660

    force create mode = 0660

    directory mask = 2770

    force directory mode = 2770

L’entrée @officefiles limite l’accès au groupe ; force group maintient les opérations dans ce groupe. Les masques limitent les permissions des nouveaux fichiers et dossiers, comme l’explique la référence Ubuntu de configuration Samba. Vérifiez puis démarrez le service :

sudo testparm -s
sudo systemctl restart smbd
sudo systemctl status smbd --no-pager

Corrigez les erreurs avant de redémarrer. Le contrôle de syntaxe prouve que Samba peut charger la configuration ; le test client suivant prouve l’utilisabilité du service.

Vérifier depuis un client

Sur un second PC Windows du LAN autorisé, ouvrez \\192.168.10.10\business dans l’Explorateur. Connectez-vous avec alex et son mot de passe Samba. Créez acceptance.txt, écrivez une phrase, fermez et rouvrez. Inscrivez un autre employé et vérifiez qu’il peut modifier ce fichier de test.

Depuis un client Linux avec smbclient installé, connectez-vous ainsi :

smbclient //192.168.10.10/business -U alex

Saisissez le mot de passe à l’invite. Essayez des identifiants incorrects et un accès invité non authentifié : aucun ne doit lire ou créer de fichiers. Sous Windows, déconnectez le partage existant et effacez les identifiants en cache avant le test refusé, sinon la session valide peut rester utilisée.

En cas d’expiration, vérifiez adresse, chemin LAN, règle source/port UFW et état de smbd. Si l’authentification ou l’écriture échoue, contrôlez l’inscription Samba, id alex et ls -ld /srv/business/team. Confirmez groupe et propriétaire du dossier. Gardez l’accès invité désactivé et n’accordez pas l’écriture à tous pour dépanner.

Budgéter propriété et location

Supposons un serveur de 1 500 $, un onduleur de 200 $ et une sauvegarde locale de 300 $. Ces hypothèses distinctes ne détaillent pas l’enveloppe précédente. Modélisez une consommation moyenne à la prise de 100 W et une électricité à 0,15 $/kWh :

100 / 1000 × 24 × 365 × 3 × 0.15 = $394.20

Ni consommation ni tarif ne sont mesurés. Affectez aux deux options autogérées 2 heures mensuelles d’administration à 25 $/heure et 10 $/mois de sauvegarde hors site indépendante :

La location ne prévoit pas de périphérique local distinct de sauvegarde ; la sauvegarde hors site indépendante figure sur sa propre ligne dans les deux cas.

Sauvegarder, restaurer et transmettre le service

Récupérez acceptance.txt et la configuration Samba avant de mettre les fichiers métier en service. Utilisez un disque externe monté séparément, déjà formaté et assez libre, puis gardez une seconde copie hors site protégée indépendamment. Les commandes suivantes ne préparent ni n’effacent de disques.

Montez le disque sur /media/business-backup. Vérifiez avec findmnt et lsblk qu’il s’agit bien du disque externe, pas d’un dossier du stockage interne. Ouvrez un shell privilégié pour que restic lise partage et configuration :

sudo -i
findmnt --mountpoint /media/business-backup
lsblk -o NAME,SIZE,MODEL,SERIAL,FSTYPE,MOUNTPOINTS

Après confirmation du périphérique, initialisez puis sauvegardez. La chaîne && s’arrête dès qu’une étape échoue, y compris en l’absence du montage :

findmnt --mountpoint /media/business-backup &&
restic -r /media/business-backup/restic init &&
restic -r /media/business-backup/restic backup /srv/business /etc/samba &&
restic -r /media/business-backup/restic snapshots &&
restic -r /media/business-backup/restic check

N’initialisez un nouveau dépôt qu’une fois. Restic demande son mot de passe ; stockez-le séparément dans le coffre d’identifiants de l’entreprise. La procédure de démarrage rapide de Restic couvre ces opérations. Si le montage n’est pas confirmé, arrêtez-vous pour éviter de créer le dépôt sur le disque hôte.

Ne modifiez pas le document de test pendant l’exercice. Dans le même shell root, restaurez seulement ce fichier et la configuration Samba dans un nouveau répertoire vide /srv/restore-check. Prévoyez assez d’espace libre pour ces éléments sélectionnés :

mkdir /srv/restore-check &&
restic -r /media/business-backup/restic restore latest --target /srv/restore-check --include /srv/business/team/acceptance.txt --include /etc/samba &&
cmp /srv/business/team/acceptance.txt /srv/restore-check/srv/business/team/acceptance.txt &&
cat /srv/restore-check/srv/business/team/acceptance.txt &&
testparm -s /srv/restore-check/etc/samba/smb.conf

exit

Les instructions de restauration de Restic décrivent chemins cibles et écrasement. cmp ne doit signaler aucune différence, le texte récupéré doit être lisible et testparm doit accepter la configuration restaurée. Cela vérifie fichiers et configuration, pas une reprise complète après sinistre.

Planifiez des sauvegardes nocturnes après fermeture des fichiers, sept instantanés quotidiens et quatre hebdomadaires conservés, un contrôle hebdomadaire du dépôt et un exercice mensuel de restauration. Les sauvegardes nocturnes exposent environ une journée de modifications ; mesurez le temps de reprise pendant l’exercice. La procédure de rétention de Restic permet une simulation avec forget --keep-daily 7 --keep-weekly 4 --dry-run. Forgetting retire les références d’instantanés ; pruning supprime les données devenues inutiles. Examinez la simulation avant toute suppression. Les instantanés conservés ne prouvent pas l’exécution des tâches manquées.

Pour automatiser, protégez les identifiants dans un fichier de mot de passe accessible à root seul ou un coffre, vérifiez le montage dans la tâche et alertez un responsable en cas d’échec. La rotation exige de brancher le bon disque avant la tâche, puis de le débrancher et de maintenir indépendamment la copie hors site.

Consignez les identifiants numériques des comptes et des groupes ainsi que les procédures d’inscription des employés. Un hôte de remplacement exige de recréer les identités Linux/Samba, de préserver ou corriger les propriétaires, de restaurer fichiers et configuration, puis de refaire un test client. Sauvegarder seulement /etc/samba ne récupère pas les identifiants Samba stockés séparément.

Transmettez responsable et suppléant, créneau de mise à jour/redémarrage, procédure d’arrêt par onduleur et contrôles d’espace, santé du miroir, journaux et résultats de sauvegarde. Consignez la restauration réussie et sa durée avant d’accepter le service.