🗂️ Storage Systems — Chapitre 8 : NAS, Network Attached Storage

• Partage commun d'une PME : \\nas\commun.
• Export NFS pour datastores VMware ou Proxmox.
• NAS backup avec snapshots immutables contre ransomware.
• Home lab multimédia avec Plex/Jellyfin.
• Scale-out NAS enterprise pour millions de fichiers.

NFS en production

• NFSv3 reste fréquent pour datastores et Unix legacy.
• NFSv4 apporte état, locking intégré, ACL, Kerberos.
• Options critiques : sync/async, root_squash, no_root_squash, sec=krb5p.
• Très utilisé pour Linux, calcul scientifique, VM datastores et Kubernetes RWX.

# Client Linux
showmount -e nas01
mount -t nfs4 nas01:/exports/prod /mnt/prod
nfsstat -m

SMB/CIFS

SMB est central pour les environnements Windows et mixtes. Il gère authentification AD, ACL NTFS-like, opportunistic locks, durable handles, encryption, signing et parfois multichannel.

FTP/SFTP est utile pour dépôt, échanges partenaires, scripts de transfert ou workflows legacy. Ce n'est pas le meilleur choix pour un partage collaboratif monté en permanence.

NAS comme cible backup

• Dépôt Veeam, Borg, Restic, Rsync, Time Machine.
• Snapshots immutables ou verrouillés selon plateforme.
• Réplication vers second NAS ou cloud.
• Attention : un NAS accessible en écriture par les serveurs peut être chiffré par ransomware.

• Utiliser un NAS bas de gamme comme stockage unique d'une base transactionnelle critique.
• Exposer SMB directement sur Internet.
• Donner droits admin/domain admin à un service backup.
• Confondre snapshots locaux et sauvegarde externe.
• Laisser tous les utilisateurs en écriture sur racine des partages.

• Synology : DSM, facilité d'administration, snapshots, Active Backup selon modèles.
• QNAP : matériel souvent varié, options réseau/PCIe, fonctionnalités avancées.
• Asustor/TerraMaster : alternatives souvent compétitives en coût.

• Désactiver services inutiles.
• MFA pour comptes admin.
• Pas d'exposition directe SMB/administration sur Internet.
• Snapshots réguliers + réplication externe.
• Comptes par service, pas de compte admin pour backup.

• Débit réel par protocole, pas seulement capacité brute.
• Licences snapshots/réplication/anti-ransomware.
• Support AD et audit requis.
• Expansion capacity planning.
• Coût support 3/5 ans.

• Snapshots fréquents et verrouillés.
• Comptes backup non interactifs.
• Détection de taux de renommage/chiffrement anormal.
• Partages en moindre privilège.
• Réplication vers cible non modifiable par les clients.

• Encryption at rest : volume, pool, dataset ou SED.
• Encryption in transit : SMB encryption, NFS Kerberos privacy, SFTP/HTTPS.
• Gestion clés : KMS/HSM si besoin enterprise.
• Attention au reboot : clé nécessaire pour remonter volumes.

• VLAN stockage séparé.
• ACL firewall : seuls clients nécessaires peuvent atteindre NFS/SMB.
• Administration sur réseau management.
• Pas d'interface admin exposée Internet.
• MFA et bastion pour admin.

# Linux client examples
smbstatus
getfacl /mnt/share
nfsstat -m

# Checks conceptuels NAS
- top clients by I/O
- failed logins
- mass delete events
- snapshot delete events
- permission changes

Le namespace permet de présenter une arborescence logique stable même quand les volumes physiques ou nœuds changent. En scale-out, c'est crucial pour éviter de disperser les chemins utilisateurs.

• Séparer volumes par criticité et politique snapshot.
• Éviter un seul partage géant sans quotas.
• Prévoir conventions de nommage.
• Documenter owners métier par partage.

Les snapshots NAS protègent surtout contre erreur humaine, suppression, corruption logique récente et ransomware si verrouillés. Ils sont rapides car souvent basés COW ou redirect-on-write.

• Compression souvent utile pour documents, logs, VM templates.
• Déduplication utile mais coûteuse RAM/CPU selon plateforme.
• Mesurer avant d'activer globalement.
• Attention aux données déjà compressées : médias, archives zip, vidéos.

# ZFS style
zpool status
zpool scrub tank
zpool status -v tank

# Btrfs style
btrfs scrub start -Bd /volume1
btrfs scrub status /volume1

Les petits fichiers saturent souvent métadonnées, CPU protocole, latence réseau et opérations directory lookup bien avant le débit brut disque.

• Éviter répertoires avec millions d'entrées.
• Activer indexation seulement si utile.
• Mesurer ops/s metadata, pas seulement MB/s.

# Clients Linux
nfsstat -m
nfsiostat 1
iostat -x 1
smbstatus

# Réseau
iperf3 -c nas01
ethtool eth0
ss -tan | grep ':445\|:2049'

En NAS enterprise, le failover peut déplacer IP, services, volumes ou ownership entre contrôleurs. Les clients SMB/NFS réagissent différemment selon version, locking et timeout.

• Synchrone : faible RPO, exige latence basse.
• Asynchrone : plus simple pour distance, RPO non nul.
• Snapshot replication : efficace pour fichiers.
• Tester régulièrement promotion du site secondaire.

• Snapshots verrouillés.
• WORM/retention lock selon plateforme.
• Compte backup sans droit de suppression snapshot.
• Administration séparée des comptes de production.

SMB 3 peut servir certains scénarios Hyper-V avec fonctionnalités comme multichannel et continuous availability, si la plateforme NAS le supporte correctement.

• NAS saturé = toutes les VM impactées.
• Snapshots NAS non coordonnés avec guest peuvent être incohérents.
• Latence p99 dégrade fortement VM et VDI.
• Réseau partagé bureautique/stockage = mauvais design.

• Réseau 10/25G dédié selon charge.
• Tester restore VM complet.
• Mesurer latence datastore, pas seulement débit.
• Limiter snapshots trop longs.

# Concepts
StorageClass NFS/SMB
PersistentVolume
PersistentVolumeClaim
Pod mounts

# Points critiques
- uid/gid
- permissions
- reclaim policy
- backup volume
- network policy

• Mettre PostgreSQL critique sur NFS sans comprendre sync/locking/latence.
• Partager le même RWX entre applications non isolées.
• Ignorer uid/gid et ACL.
• Ne pas sauvegarder les PV.

• NAS pour données partagées non transactionnelles.
• DB via opérateur avec stockage bloc/local adapté.
• Quotas par namespace/projet.
• Snapshots coordonnés avec application.

• Ouverture/lecture fichier sensible.
• Suppression massive.
• Changement ACL.
• Création compte admin.
• Suppression snapshot.

• Volume > 80/90/95%.
• Snapshot reserve consommée.
• Réplication en retard.
• Échec backup.
• Pic rename/delete suspect.

• Besoin de dossiers partagés.
• Clients Windows/Linux/macOS.
• Snapshots et quotas par projet.
• Backup centralisé.
• Accès fichier plutôt que bloc.

• Latence ultra basse obligatoire.
• Base transactionnelle critique sans certification.
• Object storage massif API S3 préférable.
• Besoin block device natif partagé.

1. Identifier changement récent ACL/groupe AD.
2. Comparer avec snapshot ou export permissions.
3. Ne pas appliquer récursif global sans sauvegarde ACL.
4. Restaurer droits sur sous-arborescence test.
5. Valider avec utilisateur métier.

1. Isoler clients suspects.
2. Couper accès écriture si propagation active.
3. Identifier fenêtre d'infection.
4. Restaurer depuis snapshot sain verrouillé.
5. Révoquer comptes compromis.
6. Analyser logs rename/delete/write.

• AD/LDAP intégré.
• MFA admin.
• Pas d'exposition Internet SMB/admin.
• Snapshots immutables si possible.
• Audit activé sur partages sensibles.

• Backup externe ou réplication distante.
• Test restore périodique.
• Compte backup dédié moindre privilège.
• Copie isolée ransomware.

• Alertes capacité, disque, snapshot, réplication.
• Firmware planifié.
• Runbook incident documenté.
• Owners métiers des partages identifiés.

• Liste partages/exports et propriétaires.
• Modèle ACL et groupes AD.
• Politique snapshots/rétention.
• Plan réseau et règles firewall.
• Procédures restore et ransomware.