subject:"Re\: \[FRnOG\] \[TECH\] Comparons nos NAS"

Re: [FRnOG] [TECH] Comparons nos NAS en tant que repositories pour Veeam

2024-03-01 Par sujet Frank ALEXIS

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

2024-03-01 Par sujet Toussaint OTTAVI




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

2024-02-29 Par sujet Frank ALEXIS

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

2024-02-29 Par sujet Toussaint OTTAVI





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

2024-02-29 Par sujet Vinz Jumpertz via frnog

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.

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/

Re: [FRnOG] [TECH] Comparons nos NAS en tant que repositories pour Veeam

2024-02-29 Par sujet Toussaint OTTAVI

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 ?

https://jorgedelacruz.uk/2020/03/19/veeam-whats-new-in-veeam-backup-replication-v10-xfs-reflink-and-fast-clone-repositories-in-veeam/

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.

---
Liste de diffusion du FRnOG
http://www.frnog.org/

28 matches

Mail list logo