Il y a plusieurs années, j'avais les mêmes exigences que vous. La solution que j'ai choisie était d'utiliser ZFS via le pilote ZFS-FUSE sur mon serveur de stockage. Je pensais que mes photos personnelles, documents numérisés et autres fichiers similaires étaient des choses auxquelles je ne pouvais accéder qu'occasionnellement, donc cela peut prendre beaucoup de temps, disons un an ou plus, avant de remarquer qu'un fichier a été corrompu en raison de une erreur de lecteur ou similaire.
À ce moment-là, toutes les copies de sauvegarde que j'ai peuvent être cette version pourrie des fichiers.
ZFS présente un avantage sur RAID-5 en ce qu'il peut détecter et réparer les erreurs dans les données stockées sur les disques individuels, même si les lecteurs ne signalent pas d'erreur de lecture lors de la lecture des données. Il détectera, via des sommes de contrôle, que l'un des disques a retourné des informations corrompues et utilisera les données de redondance pour réparer ce disque.
En raison de la façon dont la somme de contrôle dans ZFS est conçue, je sentais que je pouvais compter sur elle pour stocker des données rarement utilisées pendant de longues périodes. Chaque semaine, je lance un "zpool scrub" qui passe en revue et relit toutes les données et vérifie les sommes de contrôle.
ZFS-FUSE a très bien fonctionné pour moi au cours des dernières années.
Dans un passé lointain, pour un client, j'ai implémenté un système de base de données qui stockait des informations de somme de contrôle sur tous les fichiers stockés dans un répertoire particulier. J'ai ensuite eu un autre script qui s'exécuterait périodiquement et vérifierait le fichier par rapport à la somme de contrôle stockée dans la base de données. Avec cela, nous avons pu détecter rapidement un fichier corrompu et restaurer à partir de sauvegardes. Nous implémentions essentiellement les mêmes types de contrôles que ZFS effectue en interne.