Re: [FRnOG] [TECH] Comparons nos NAS en tant que repositories pour Veeam
J’avoue la dedup sur HDD c’est touchy ;-) ! Je pense que c’est juste pour le PoC. Content d’avoir rendu service :-) My 2cents Frank Le ven. 1 mars 2024 à 09:11, Toussaint OTTAVI a écrit : > > Le 29/02/2024 à 20:13, Frank ALEXIS a écrit : > > > > > Un mec bien au point sur github sort des scripts hyper propres pour > > tout un tas de trucs sur syno et ça marche hyper bien :-) > > > > https://github.com/007revad > > Merci :-) Je ne connaissais pas. Je vais jeter un oeil... > > Ceci étant, si je bidouillais pas mal les Syno il y a quelques années, > j'y ai un peu renoncé pour des données de prod : > - A chaque mise à jour de DSM, les bidouilles sont supprimées, donc çà > pète des fonctionnalités, et il faut repasser derrière. > - J'installais systématiquement un optware, pour pouvoir faire tourner > un agent Nagios NRPE, et lancer mes scripts de surveillance des > sauvegardes. Un jour, j'ai eu un problème qui a nécessité que je > sollicite le support. Quand ils ont vu "optware", ils ont hurlé : > "Oulala, vous avez trafiqué votre NAS, le support n'est pas assuré !". > Alors que le problème n'avait rien à voir avec optware, et était présent > même sans optware. > > Enfin, çà n'a rien à voir avec Syno, mais çà touche à des > fonctionnalités non officiellement supportées : un jour, j'ai activé la > déduplication ReFS sur un disque de cluster Windows (dans une > configuration non supportée; mais rien ne me l'avait dit lorsque j'ai > activé l'option, et je n'avais pas lu la ligne laconique dans la doc > qui disait que ce n'était pas encore supporté dans ce cas de figure). Eh > bien, çà marchait très bien ! Sauf qu'une fois par semaine, pendant une > tâche planifiée de scrubbing, çà plantait. Le cluster perdait l'accès au > stockage partagé pendant quelques secondes, suffisantes pour crasher la > plupart des VMs :-D > > Donc, sur de la prod, j'évite de trop jouer avec des trucs "non > supportés" ;-) > > > Mais … y’a un petit script qui va bien pour activer la dedup sur tous > > les disques « non compatibles » hors syno > > M'ouais... Voici ce que dit le script en question dans son --help : >--hddEnable data deduplication for HDDs *(dangerous)* > :-D > > > y’a même de quoi créer et utiliser les caches nvme comme volume raid1 > > classique (vu le prix des 2To pcie 4x c’est une belle opportunité > > d’avoir un truc qui booste bien via du 10Gb lan) > > Cà, en revanche, çà m'inspire un peu plus :-) Merci pour le tuyau. > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Comparons nos NAS en tant que repositories pour Veeam
Le 29/02/2024 à 20:13, Frank ALEXIS a écrit : Un mec bien au point sur github sort des scripts hyper propres pour tout un tas de trucs sur syno et ça marche hyper bien :-) https://github.com/007revad Merci :-) Je ne connaissais pas. Je vais jeter un oeil... Ceci étant, si je bidouillais pas mal les Syno il y a quelques années, j'y ai un peu renoncé pour des données de prod : - A chaque mise à jour de DSM, les bidouilles sont supprimées, donc çà pète des fonctionnalités, et il faut repasser derrière. - J'installais systématiquement un optware, pour pouvoir faire tourner un agent Nagios NRPE, et lancer mes scripts de surveillance des sauvegardes. Un jour, j'ai eu un problème qui a nécessité que je sollicite le support. Quand ils ont vu "optware", ils ont hurlé : "Oulala, vous avez trafiqué votre NAS, le support n'est pas assuré !". Alors que le problème n'avait rien à voir avec optware, et était présent même sans optware. Enfin, çà n'a rien à voir avec Syno, mais çà touche à des fonctionnalités non officiellement supportées : un jour, j'ai activé la déduplication ReFS sur un disque de cluster Windows (dans une configuration non supportée; mais rien ne me l'avait dit lorsque j'ai activé l'option, et je n'avais pas lu la ligne laconique dans la doc qui disait que ce n'était pas encore supporté dans ce cas de figure). Eh bien, çà marchait très bien ! Sauf qu'une fois par semaine, pendant une tâche planifiée de scrubbing, çà plantait. Le cluster perdait l'accès au stockage partagé pendant quelques secondes, suffisantes pour crasher la plupart des VMs :-D Donc, sur de la prod, j'évite de trop jouer avec des trucs "non supportés" ;-) Mais … y’a un petit script qui va bien pour activer la dedup sur tous les disques « non compatibles » hors syno M'ouais... Voici ce que dit le script en question dans son --help : --hdd Enable data deduplication for HDDs *(dangerous)* :-D y’a même de quoi créer et utiliser les caches nvme comme volume raid1 classique (vu le prix des 2To pcie 4x c’est une belle opportunité d’avoir un truc qui booste bien via du 10Gb lan) Cà, en revanche, çà m'inspire un peu plus :-) Merci pour le tuyau. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Comparons nos NAS en tant que repositories pour Veeam
Hello folks, Sur syno la dedup existe bien MAIS il faut des disques syno (classique ou ssd) et du cache nvme syno. Mais … y’a un petit script qui va bien pour activer la dedup sur tous les disques « non compatibles » hors syno Petite info, les syno sont des Toshiba avec un firmrware « maison » that’s all On bidouille pas mal les bestioles et y’a même de quoi créer et utiliser les caches nvme comme volume raid1 classique (vu le prix des 2To pcie 4x c’est une belle opportunité d’avoir un truc qui booste bien via du 10Gb lan) Un mec bien au point sur github sort des scripts hyper propres pour tout un tas de trucs sur syno et ça marche hyper bien :-) https://github.com/007revad Frank Le jeu. 29 févr. 2024 à 15:29, Toussaint OTTAVI a écrit : > > Le 28/02/2024 à 12:39, elpablodelcasata via frnog a écrit : > > Je me pose une question infra. Utiliseriez vous un syno en tant que > repository pour du VEEAM ? > > En terme de fiabilité, rien à redire. En revanche, il n'y a aucune > déduplication et aucune optimisation de l'espace. Donc, çà bouffe une > place folle si on conserve plusieurs GFS, et qu'on fait en plus des > snapshots au niveau BTRFS (pour avoir des copies "inaccessibles" depuis > Veeam). C'est une véritable horreur ! Plus on rajoute des disques, plus > çà en consomme :-) > > Les sauvegardes de VM, c'est quelque chose qui se déduplique très bien. > En général, il y a beaucoup, beaucoup de données communes, et très peu > de données qui changent d'un jour à l'autre. Donc, pour un repo Veeam, > quelle que soit la technologie choisie, elle a tout intérêt à posséder > un mécanisme de déduplication supporté. Ainsi, à capacité de stockage > équivalente, on peut conserver beaucoup plus de versions. > > Ainsi, en terme d'optimisation de l'espace, j'ai obtenu d'excellents > résultats avec des filesystems supportant les RefLinks comme ReFS sous > Windows ou XFS sous Linux. Ce n'est pas vraiment de la déduplication au > sens où on l'entend habituellement (où c'est le filesystem qui fait le > job de façon transparente). Ici, c'est Veeam qui ne stocke qu'une seule > fois les blocs communs à plusieurs sauvegardes, en utilisant les > RefLinks sur les filesystems supportés : > > https://jorgedelacruz.uk/2020/03/19/veeam-whats-new-in-veeam-backup-replication-v10-xfs-reflink-and-fast-clone-repositories-in-veeam/ > > Un autre avantage est que la génération de "Synthetic Full" (pour les > non-inités, des sauvegardes "full" pour conservation générées à partir > de fichiers incrémentiels) est beaucoup plus rapide grâce au FastClone. > Veeam n'a pas besoin de copier physiquement les données, il copie juste > des "pointeurs". > > Enfin, un autre avantage d'utiliser un stockage XFS sous Linux, c'est la > possibilité de gérer l'immutabilité, autrement dit, des sauvegardes qui > ne peuvent pas être effacées avant l'expiration de la période de > rétention initialement configurée. > > Donc, la meilleure solution que j'aie trouvée pour des repo Veeam > (hormis l'appliance pro avec déduplication intégrée qui coûte un bras), > c'est le serveur "DIY" avec un Linux, et stockage XFS. Le gain d'espace > et la rapidité avec les RefLinks sont bluffants. Et l'immutabilité, > c'est pas mal aussi :-) > > Certes, c'est beaucoup moins "plug and play" qu'un petit Synology :-) Et > c'est plus cher, aussi. Donc, il m'arrive d'utiliser encore du Syno pour > des sauvegardes locales de premier niveau. > > L'idéal, ce serait la simplicité de mise en oeuvre d'un Synology, avec > possibilité de gérer de la déduplication depuis Veeam, et idéalement, > support de l'immutabilité. Mais je n'ai pas encore trouvé :-) > > PS : > - Il y a des variantes, par exemple mettre le Syno en iSCSI, monter le > LUN depuis Windows, et créer un repo ReFS dessus. Cà gèrerait la > déduplication, mais pas l'immutabilité. Il me semble avoir lu quelque > part que ce n'était pas trop supporté. Et vu que pour les sauvegardes, > on recherche quelque chose de super fiable, j'avoue que çà ne me tente > pas d'essayer :-) > - Les dernières versions de DSM semblent supporter la déduplication sur > BTRFS. Cela ne fonctionne que sur des SSD. Je ne sais pas si c'est > supporté nativement par Veeam. Mais à priori, pas besoin que çà le soit > : une petite sauvegarde Veeam dans un repo "fileshare" normal (non > dédupliqué), et des snapshots BTRFS, avec déduplication et conservation, > derrière (si tant est que çà soit possible). Certes, c'est bien moins > souple si on a besoin de restaurer depuis ces snapshots, mais çà devrait > être "secure" (les snapshots sont invisibles pour un malin qui gagnerait > un accès à la console Veeam), et çà ne devrait pas bouffer trop de > place. Je n'ai pas encore monté de Syno en full-SSD pour essayer, mais > c'est sur la ToDo... > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Comparons nos NAS en tant que repositories pour Veeam
Le 29/02/2024 à 15:43, Vinz Jumpertz via frnog a écrit : je peux repondre pour le iscsi refs Oui, çà fonctionne... C'est juste une question de confiance :-) Pour des choses aussi critiques et aussi "bas niveau" qu'un filesystem présenté à une application de sauvegarde (le truc dont on est susceptible d'avoir besoin en dernier recours, quand tout le reste aura pété), j'aime bien avoir des choses en mode KISS, dans la même boite (ex: un contrôleur RAID hardware et des disques connectés directement dessus), plutôt que de dépendre de deux machines différentes (un stockage iSCSI sur un NAS Synology, et un filesystem monté depuis une machine Windows), reliées entre elles par quelque chose de potentiellement non fiable (iSCSI). J'ai souvent fait des maquettes avec ce genre de config dans mon lab, notamment pour tester différents stockages pour Veeam. L'une d'entre elles était un hpe StoreOnce Virtual (solution commerciale) dans une VM, avec du stockage iSCSI sur un Synology. C'était vraiment pas dur à péter, même sans le faire exprès :-) Un simple reboot du NAS, le iSCSI tombait, le StoreOnce perdait son disque et crashait. En redémarrant le StoreOnce, il ne remontait pas tout seul son disque. Il fallait lancer une ligne de commande cryptique sur l'OS propriétaire pour faire une vérification / réparation du support. Je n'irai pas jusqu'à incriminer la fiabilité de l'application terminale (ici, StoreOnce), vu que je lui ai volontairement rajouté des obstacles non prévus entre elle et son stockage :-) Je me souviens également, lors de mes recherches, d'un article qui déconseillait de monter du ReFS à travers iSCSI sur un Syno. Malheureusement, je ne retrouve pas les références. Donc, j'ai abandonné le iSCSI sur Synology pour des tâches critiques comme la sauvegarde. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Comparons nos NAS en tant que repositories pour Veeam
Hello, je peux repondre pour le iscsi refs et le rackstation, on l'a en production sur du veeam 365 et ca fonctionne (comme du veeam), ca prend de l'espace mais on peut dupliquer entre synologies sans soucies. KR Vincent On 2/29/24 14:29, Toussaint OTTAVI wrote: Le 28/02/2024 à 12:39, elpablodelcasata via frnog a écrit : Je me pose une question infra. Utiliseriez vous un syno en tant que repository pour du VEEAM ? En terme de fiabilité, rien à redire. En revanche, il n'y a aucune déduplication et aucune optimisation de l'espace. Donc, çà bouffe une place folle si on conserve plusieurs GFS, et qu'on fait en plus des snapshots au niveau BTRFS (pour avoir des copies "inaccessibles" depuis Veeam). C'est une véritable horreur ! Plus on rajoute des disques, plus çà en consomme :-) Les sauvegardes de VM, c'est quelque chose qui se déduplique très bien. En général, il y a beaucoup, beaucoup de données communes, et très peu de données qui changent d'un jour à l'autre. Donc, pour un repo Veeam, quelle que soit la technologie choisie, elle a tout intérêt à posséder un mécanisme de déduplication supporté. Ainsi, à capacité de stockage équivalente, on peut conserver beaucoup plus de versions. Ainsi, en terme d'optimisation de l'espace, j'ai obtenu d'excellents résultats avec des filesystems supportant les RefLinks comme ReFS sous Windows ou XFS sous Linux. Ce n'est pas vraiment de la déduplication au sens où on l'entend habituellement (où c'est le filesystem qui fait le job de façon transparente). Ici, c'est Veeam qui ne stocke qu'une seule fois les blocs communs à plusieurs sauvegardes, en utilisant les RefLinks sur les filesystems supportés : https://jorgedelacruz.uk/2020/03/19/veeam-whats-new-in-veeam-backup-replication-v10-xfs-reflink-and-fast-clone-repositories-in-veeam/ Un autre avantage est que la génération de "Synthetic Full" (pour les non-inités, des sauvegardes "full" pour conservation générées à partir de fichiers incrémentiels) est beaucoup plus rapide grâce au FastClone. Veeam n'a pas besoin de copier physiquement les données, il copie juste des "pointeurs". Enfin, un autre avantage d'utiliser un stockage XFS sous Linux, c'est la possibilité de gérer l'immutabilité, autrement dit, des sauvegardes qui ne peuvent pas être effacées avant l'expiration de la période de rétention initialement configurée. Donc, la meilleure solution que j'aie trouvée pour des repo Veeam (hormis l'appliance pro avec déduplication intégrée qui coûte un bras), c'est le serveur "DIY" avec un Linux, et stockage XFS. Le gain d'espace et la rapidité avec les RefLinks sont bluffants. Et l'immutabilité, c'est pas mal aussi :-) Certes, c'est beaucoup moins "plug and play" qu'un petit Synology :-) Et c'est plus cher, aussi. Donc, il m'arrive d'utiliser encore du Syno pour des sauvegardes locales de premier niveau. L'idéal, ce serait la simplicité de mise en oeuvre d'un Synology, avec possibilité de gérer de la déduplication depuis Veeam, et idéalement, support de l'immutabilité. Mais je n'ai pas encore trouvé :-) PS : - Il y a des variantes, par exemple mettre le Syno en iSCSI, monter le LUN depuis Windows, et créer un repo ReFS dessus. Cà gèrerait la déduplication, mais pas l'immutabilité. Il me semble avoir lu quelque part que ce n'était pas trop supporté. Et vu que pour les sauvegardes, on recherche quelque chose de super fiable, j'avoue que çà ne me tente pas d'essayer :-) - Les dernières versions de DSM semblent supporter la déduplication sur BTRFS. Cela ne fonctionne que sur des SSD. Je ne sais pas si c'est supporté nativement par Veeam. Mais à priori, pas besoin que çà le soit : une petite sauvegarde Veeam dans un repo "fileshare" normal (non dédupliqué), et des snapshots BTRFS, avec déduplication et conservation, derrière (si tant est que çà soit possible). Certes, c'est bien moins souple si on a besoin de restaurer depuis ces snapshots, mais çà devrait être "secure" (les snapshots sont invisibles pour un malin qui gagnerait un accès à la console Veeam), et çà ne devrait pas bouffer trop de place. Je n'ai pas encore monté de Syno en full-SSD pour essayer, mais c'est sur la ToDo... --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Comparons nos NAS en tant que repositories pour Veeam
Le 28/02/2024 à 12:39, elpablodelcasata via frnog a écrit : Je me pose une question infra. Utiliseriez vous un syno en tant que repository pour du VEEAM ? En terme de fiabilité, rien à redire. En revanche, il n'y a aucune déduplication et aucune optimisation de l'espace. Donc, çà bouffe une place folle si on conserve plusieurs GFS, et qu'on fait en plus des snapshots au niveau BTRFS (pour avoir des copies "inaccessibles" depuis Veeam). C'est une véritable horreur ! Plus on rajoute des disques, plus çà en consomme :-) Les sauvegardes de VM, c'est quelque chose qui se déduplique très bien. En général, il y a beaucoup, beaucoup de données communes, et très peu de données qui changent d'un jour à l'autre. Donc, pour un repo Veeam, quelle que soit la technologie choisie, elle a tout intérêt à posséder un mécanisme de déduplication supporté. Ainsi, à capacité de stockage équivalente, on peut conserver beaucoup plus de versions. Ainsi, en terme d'optimisation de l'espace, j'ai obtenu d'excellents résultats avec des filesystems supportant les RefLinks comme ReFS sous Windows ou XFS sous Linux. Ce n'est pas vraiment de la déduplication au sens où on l'entend habituellement (où c'est le filesystem qui fait le job de façon transparente). Ici, c'est Veeam qui ne stocke qu'une seule fois les blocs communs à plusieurs sauvegardes, en utilisant les RefLinks sur les filesystems supportés : https://jorgedelacruz.uk/2020/03/19/veeam-whats-new-in-veeam-backup-replication-v10-xfs-reflink-and-fast-clone-repositories-in-veeam/ Un autre avantage est que la génération de "Synthetic Full" (pour les non-inités, des sauvegardes "full" pour conservation générées à partir de fichiers incrémentiels) est beaucoup plus rapide grâce au FastClone. Veeam n'a pas besoin de copier physiquement les données, il copie juste des "pointeurs". Enfin, un autre avantage d'utiliser un stockage XFS sous Linux, c'est la possibilité de gérer l'immutabilité, autrement dit, des sauvegardes qui ne peuvent pas être effacées avant l'expiration de la période de rétention initialement configurée. Donc, la meilleure solution que j'aie trouvée pour des repo Veeam (hormis l'appliance pro avec déduplication intégrée qui coûte un bras), c'est le serveur "DIY" avec un Linux, et stockage XFS. Le gain d'espace et la rapidité avec les RefLinks sont bluffants. Et l'immutabilité, c'est pas mal aussi :-) Certes, c'est beaucoup moins "plug and play" qu'un petit Synology :-) Et c'est plus cher, aussi. Donc, il m'arrive d'utiliser encore du Syno pour des sauvegardes locales de premier niveau. L'idéal, ce serait la simplicité de mise en oeuvre d'un Synology, avec possibilité de gérer de la déduplication depuis Veeam, et idéalement, support de l'immutabilité. Mais je n'ai pas encore trouvé :-) PS : - Il y a des variantes, par exemple mettre le Syno en iSCSI, monter le LUN depuis Windows, et créer un repo ReFS dessus. Cà gèrerait la déduplication, mais pas l'immutabilité. Il me semble avoir lu quelque part que ce n'était pas trop supporté. Et vu que pour les sauvegardes, on recherche quelque chose de super fiable, j'avoue que çà ne me tente pas d'essayer :-) - Les dernières versions de DSM semblent supporter la déduplication sur BTRFS. Cela ne fonctionne que sur des SSD. Je ne sais pas si c'est supporté nativement par Veeam. Mais à priori, pas besoin que çà le soit : une petite sauvegarde Veeam dans un repo "fileshare" normal (non dédupliqué), et des snapshots BTRFS, avec déduplication et conservation, derrière (si tant est que çà soit possible). Certes, c'est bien moins souple si on a besoin de restaurer depuis ces snapshots, mais çà devrait être "secure" (les snapshots sont invisibles pour un malin qui gagnerait un accès à la console Veeam), et çà ne devrait pas bouffer trop de place. Je n'ai pas encore monté de Syno en full-SSD pour essayer, mais c'est sur la ToDo... --- Liste de diffusion du FRnOG http://www.frnog.org/
