Serveur de stockage de sauvegarde avec ZFS

Je suis tout homme dans une petite entreprise. Je veux concevoir une nouvelle infrastructure comprenant un nouveau serveur et un serveur de sauvegarde séparé avec une politique de sauvegarde à l'échelle de l'entreprise.

La chose la plus importante dans l'entreprise est SQL Server et ses bases de données. Il existe 10 bases de données, mais seulement 2 d'entre elles sont vraiment importantes. Le premier 8 Go, principalement des données texte et des chiffres. Le second d'environ 300 Go avec 16 Go / mois de croissance contient des PDF et des GIF.

Pour enregistrer la politique de sauvegarde actuelle du stockage, il s'agit d'une sauvegarde complète par semaine et de 6 différentiels. Je pense que c'est environ 350 Go par semaine, 1,4 To par mois.

Après avoir lu des articles sur la corruption silencieuse des données, j'ai décidé d'essayer ZFS avec l'édition Nexenta Community.

Ma question: ZFS avec déduplication est-il bon pour stocker des fichiers de sauvegarde en termes de fiabilité ou dois-je penser à une sauvegarde sur bande ou autre chose?

EDIT: Je sais qu'en ce moment, nous ne pouvons pas prédire les performances, le taux de déduplication, etc., mais je veux savoir si c'est une bonne idée.

Certes, ZFS est suffisamment stable pour faire ce genre de chose, il existe de nombreuses très grandes plates-formes de production fiables et de grande envergure basées entièrement sur ZFS et Nexenta.

Cela dit, il est toujours préférable d'avoir des sauvegardes sur disque sur site telles que celle que vous proposez ET des sauvegardes sur disque amovible ou sur bande qui se déroulent hors site quotidiennement pour se protéger contre les incendies / tremblements de terre / Cthulhu, etc.

Donc ma réponse est oui, ça va, mais je choisirais les deux options si vous le pouvez.

(en supposant que vous faites référence à l'utilisation de la déduplication dans ZFS par rapport à votre logiciel de sauvegarde)

Je ne recommanderais pas d' utiliser la déduplication native ZFS pour votre système de sauvegarde, sauf si vous concevez votre système de stockage spécifiquement pour lui.

L'utilisation de la déduplication dans ZFS est extrêmement gourmande en RAM. Étant donné que la déduplication se produit en temps réel lorsque les données sont diffusées / écrites dans le pool de stockage, une table est conservée en mémoire qui assure le suivi des blocs de données. Ceci est la table DDT . Si votre serveur de stockage ZFS ne dispose pas de suffisamment de RAM pour accueillir cette table, les performances en souffriront énormément. Nexenta vous avertira lorsque la table dépassera un certain seuil, mais d'ici là, il est trop tard. Cela peut être augmenté par l'utilisation d'un périphérique L2ARC (cache de lecture), mais de nombreux adopteurs précoces de ZFS sont tombés dans ce piège.

Voir:

ZFS - la destruction de zvol ou d'un ensemble de données dédupliqués bloque le serveur. Comment récupérer?

ZFS - Impact de l'échec du périphérique de cache L2ARC (Nexenta)

Lorsque je dis que la mémoire RAM requise est élevée pour l'utilisation de la déduplication, j'estimerais les besoins en RAM et L2ARC pour l'ensemble de données que vous décrivez à 64 Go + RAM et 200 Go + L2ARC. Ce n'est pas un investissement mineur. La conservation de nombreux fichiers système Windows et documents image qui ne seront pas relus remplira ce DDT très rapidement. Le gain ne vaut peut-être pas le travail d'ingénierie qui doit aller de l'avant.

Une meilleure idée est d'utiliser la compression sur le zpool, en tirant éventuellement parti des capacités de gzip pour les types de données plus compressibles. La déduplication ne vaudra pas la peine car il y a un succès lorsque vous devez supprimer des données dédupliquées (doit faire référence au DDT).

De plus, comment allez-vous présenter le stockage à votre logiciel de sauvegarde? Quelle suite logicielle de sauvegarde utiliserez-vous? Dans les environnements Windows, je présente ZFS en tant que stockage en bloc pour Backup Exec via iSCSI. Je n'ai jamais trouvé les fonctionnalités ZFS CIFS suffisamment robustes et j'ai préféré les avantages d'un périphérique au format natif.

En outre, voici une excellente ressource ZFS pour des idées de conception. Choses à propos de ZFS que personne ne vous a dit

Un autre système d'exploitation est OpenIndiana qui est tout aussi bon et reçoit des mises à jour plus fréquentes parfois.

Une autre option consiste à configurer un deuxième serveur ZFS avec un pool de stockage plus petit (potentiellement) avec la compression activée. Vous pouvez utiliser ce deuxième appareil pour les sauvegardes statiques. Vous pouvez ainsi vous passer du cache de lecture et vous n'avez pas non plus besoin de quantités stupides de CPU / RAM pour le gérer.

Nous exécutons une configuration comme celle-ci où je travaille:

• Serveur de stockage principal OpenIndiana [ principal ] avec six disques de 2 To dans un pool RaidZ1 de trois ensembles de paires en miroir. Ceci, tout en réduisant votre espace de stockage disponible, constitue un pool de stockage rapide et redondant.
• Un serveur de stockage secondaire [ sauvegarde ] exécutant également OpenIndiana avec une configuration similaire de disques qui sert uniquement de périphérique de sauvegarde.
• main possède un script qui est exécuté à partir d'une tâche cron qui prend régulièrement des clichés / réservoir / [jeu de données] au cours de la journée
• Chaque soir, une autre tâche cron est exécutée qui pousse les instantanés de la journée sur le réseau à sauvegarder . Une fois la synchronisation initiale de tous vos instantanés effectuée (une procédure unique), la nature incrémentielle des instantanés signifie que les modifications sont transmises très rapidement à votre périphérique de sauvegarde.

J'ai un bref aperçu sur la façon de configurer l'envoi / la réception de ZFS ici: http://kyrill-poole.co.uk/blog/tech/zfs-send-and-receive/