Pourquoi le nombre de fichiers augmente-t-il le travail de sauvegarde et de snapshot même lorsqu'un NAS domestique dispose de capacité libre ?

Le nombre de fichiers augmente le travail de sauvegarde et d'instantané car chaque objet ajoute des opérations qui ne disparaissent pas lorsque le fichier est petit. Le NAS doit toujours énumérer un nom, lire les métadonnées, comparer l'état, enregistrer l'inclusion, mettre à jour les index, puis supprimer ou restaurer cet objet même lorsque le total des octets stockés laisse beaucoup de capacité libre.

La capacité libre indique si plus de blocs de données peuvent être alloués. Elle ne mesure pas combien d'enregistrements d'espace de noms, de transactions, de vérifications, de relations de version ou d'étapes de restauration un flux de travail de sauvegarde doit traiter.

Pourquoi chaque fichier ajoute-t-il un travail fixe de sauvegarde ?

Un travail de sauvegarde ne peut pas traiter un répertoire contenant un million de fichiers comme un seul objet. chaque objet ajoute des opérations fixes de sauvegarde incluant la découverte, la lecture des attributs, les vérifications de politique, les entrées de catalogue et la création de destination.

Pour un gros fichier, ce coût fixe d'installation est amorti sur plusieurs mégaoctets ou gigaoctets. Pour les petits fichiers, l'ouverture, la fermeture, les permissions, le journal et le protocole peuvent prendre plus de temps que le transfert de la charge utile.

Le goulot d'étranglement peut donc être les opérations par seconde plutôt que la bande passante. Un graphique réseau peut rester presque vide tandis que les disques, les services de métadonnées ou une base de données de sauvegarde traitent continuellement des enregistrements d'objets.

Pourquoi un arbre inchangé peut-il encore prendre beaucoup de temps à analyser ?

Les outils incrémentiels doivent déterminer ce qui a changé avant de pouvoir ignorer les données inchangées. les arbres inchangés nécessitent toujours une comparaison fichier par fichier, donc une sauvegarde avec presque rien à transférer peut quand même parcourir tout l'arbre sélectionné.

La comparaison utilise généralement la taille, la date de modification, le type de fichier, le chemin et l'état du catalogue précédent. Lire ces champs à travers des millions d'objets génère des E/S de métadonnées et des allers-retours réseau même lorsque le contenu des fichiers ne bouge pas.

Les journaux de modifications et les instantanés du système de fichiers peuvent réduire l'ensemble des candidats, mais seulement lorsque le système de sauvegarde fait confiance et conserve l'historique requis. Une plage de journal manquante ou un catalogue reconstruit peut forcer une analyse plus large.

Comment les sommes de contrôle et la comparaison incrémentielle multiplient-elles le coût ?

La comparaison des métadonnées est relativement peu coûteuse mais ne peut pas détecter tous les changements de contenu. le mode somme de contrôle lit chaque fichier sélectionné, et la vérification du contenu peut nécessiter la lecture de données qu'une comparaison d'horodatage aurait évitée.

Les sommes de contrôle ajoutent des lectures CPU et de stockage pour chaque objet sélectionné. Le coût est particulièrement visible lorsqu'un travail vérifie des archives immuables, déduplique des morceaux ou revérifie les données après une exécution interrompue.

Un réseau rapide ne supprime pas ce travail car la source doit toujours localiser et lire les fichiers. La sauvegarde peut être limitée par de petites lectures aléatoires, des verrous sur les métadonnées, le débit de hachage ou les mises à jour du catalogue de destination.

Pourquoi les snapshots et les versions conservées augmentent-ils le travail sur les métadonnées ?

Les snapshots peuvent préserver efficacement les blocs modifiés, mais un outil de sauvegarde ou de gestion doit toujours identifier les versions et les relations. les versions conservées multiplient les relations de métadonnées à mesure que les objets actuels, versions antérieures, chemins et enregistrements de politique s'accumulent.

Un navigateur de snapshots au niveau des fichiers peut lister plusieurs entrées historiques pour chaque chemin actif. L'élagage de la rétention doit décider quelles versions restent référencées avant que les métadonnées, enregistrements de répertoire ou blocs puissent être libérés.

La création de snapshots au niveau des blocs peut être rapide tandis que la réplication, le catalogage, la suppression et la sélection de restauration ultérieurs restent sensibles au nombre de fichiers. La vitesse du snapshot seule ne mesure pas le coût complet du cycle de vie.

Pourquoi les opérations de suppression et de restauration sont-elles aussi limitées par le nombre de fichiers ?

Supprimer ou restaurer de nombreux petits fichiers répète le travail sur l'espace de noms et les transactions. restaurer de nombreux petits fichiers répète le travail de configuration au lieu de diffuser une charge utile continue.

Une restauration doit recréer les répertoires, noms, permissions, horodatages, attributs étendus, liens et métadonnées d'application. La destination peut également journaliser chaque opération et mettre à jour les antivirus, indexeurs ou observateurs de synchronisation.

Supprimer un grand arbre peut être tout aussi lent car chaque nom et relation d'objet doit être supprimé en toute sécurité. Libérer un téraoctet dans un seul fichier peut être plus simple que de supprimer quelques gigaoctets répartis sur des millions d'objets.

Comment un NAS domestique doit-il réduire la surcharge au niveau des objets ?

le nombre de fichiers et la capacité en bytes sont des dimensions distinctes. La planification de la capacité doit donc suivre le nombre d’objets, la durée du scan de sauvegarde, la taille du catalogue, le nombre de versions et le taux de restauration.

Utilisez le suivi des changements incrémentaux lorsque fiable, excluez les caches générés, regroupez les petits objets immuables dans des archives lorsque la restauration individuelle n’est pas nécessaire, et conservez les catalogues de sauvegarde sur un stockage conçu pour les E/S aléatoires petites.

Testez le débit de restauration en fichiers par seconde ainsi qu’en Mo/s. La bonne conception préserve les exigences d’accès et de récupération tout en réduisant la manipulation répétée des objets ; tout regrouper dans des archives peut compliquer les mises à jour individuelles et les restaurations partielles.

FAQ

Une sauvegarde peut-elle être lente alors qu’elle transfère presque aucune donnée ?

Oui. Ils peuvent passer la majeure partie du temps à énumérer et comparer des millions d’objets inchangés.

Les snapshots éliminent-ils la surcharge liée au nombre de fichiers ?

Ils peuvent accélérer la capture à un instant donné, mais la navigation dans les versions, la réplication des changements, l’élagage de la rétention et la restauration des fichiers traitent toujours les métadonnées.

Faut-il toujours archiver les petits fichiers ensemble ?

Non. Les archives réduisent la surcharge des objets mais complexifient les modifications individuelles, les permissions, la déduplication, la recherche et la restauration partielle.

Quelle métrique compte en dehors des Mo/s ?

Suivez les fichiers scannés par seconde, les objets modifiés, la latence des métadonnées, la croissance du catalogue, le nombre de snapshots, le taux de suppression et les objets restaurés par seconde.

Conclusion finale

Le nombre de fichiers augmente le travail de sauvegarde et de snapshot car chaque objet génère des opérations fixes de découverte, comparaison, catalogage, versionnage, suppression et restauration. L’espace libre protège l’allocation future de bytes mais ne supprime pas le travail au niveau des objets. Mesurez les fichiers par seconde et le comportement de restauration en parallèle avec la capacité et la bande passante.