Freebox Server (Ultra V9/ Pop V8/ Delta V7 / Revolution V6 / Mini 4K)

Si ce n'est pas déjà fait… il faut passer en SMB2
En SMB1, en dehors de l'aspect sécurité, on est aussi sur des niveaux de perfs catastrophiques… c'est du Samba antidéluvien.

Il faut priviléger la connexion cablée sur ce type d'opération, l'instabilité naturelle du Wifi n'aide pas et a tendance à multiplier les erreurs de transmission de "paquets"

J'utilise aussi la box pour effectuer ce type de sauvegarde, et je le fais depuis longtemps ça date de la Revolution. je le faisais avec Acronis, je le fais maintenant avec Reflect

Delta ou Revolution, je peux confirmer qu'on atteint en fait les limites de performance du serveur Freebox, sans doute pas assez costaud niveau processeur.

Il n'est pas rare en effet qu'une sauvegaede échoue en cours de route, et meme si ça amarche,
Il n'est pas rare qu'après une sauvegarde de ce type qui sollicte fortement la bande apssante en continue, le serveur de Delta soit dans un état instable, avec des comportements bizarres, il faut rebooter la Delta pour que tout rentre en ordre.

Bref… depuis les origines de la Freebox, lorsque le serveur Samba est sollicité intensivement en continue sur une longues durée… ça a une facheuse tendance à planter.

Je soupçonne des limites "hard"
Samba est à l'origine designé pour des serveurs d'entreprise autrement plus puissants.

Bonjour BSDInside,

merci pour ton retour, effectivement le partage SMB 2/3 est bien activé.
Le problème reste entier.

Je reste preneur d'une autre piste.

Cordialement.

Chez moi les backups fonctionnent 'pas trop mal' si :

- ordinateur cablé à la Delta ET PAS D'AUTRES APPAREILS fonctionnant simultanément sur le switch pendant la sauvegarde (les ports ethernets sont sur un Switch (un rack commun), ce ne sont pas des ports indépendants, ce qui ne permet pas de controler finement ces ports de façon individualisée, donc les autres appareils peuvent provoquer des pertes de paquets, Samba semblant exiger un accès exclusif aux ressources réseau.

- de préférence pas d'appareils fortement consommateur connectés en Wifi, meme si normalement Wifi et switch sont bien séparés. Un simple téléphone en veille qui se contente de synchroniser des emails en taches de fond ne posera pas problème, mais si on se sert du téléphone en Wifi pour faire du streaming ça peut poser souci

- sauvegardes fragmentées : jamais de sauvegarde d'un seul tenant, problèmes quasi garantis, il faut définir une fragmentation des sauvegardes par blocs de 5GB par exemple
Entre chaque bloc, ça permet au serveur Samba de "souffler" un peu.

- quand le PC effectue une sauvegarde, il doit etre inactif. Si pendant la sauvegarde on surfe sur internet il y a 9 chances sur 10 de faire planter la sauvegarde. De meme je désactive les antivirus et parefeu commerciaux, et ne laisse fonctionner en tache de fond que la parefeu Windows que je réactive pour l'occasion. Les logiciels de sécurité avancés peuvent analyser les paquets en continue et interférer avec Samba en provoquant des erreurs de transmission

Dans tous les cas, meme après une sauvegarde réussie il est conseillé de rebooter la Delta, le serveur samba peut se trouver dans une situation "incertaine" soit fonctionner "en apparence" mais générer plus tard des bugs d'accès ou d'écritures très étranges

D'ailleurs les DEVs pourraient ajouter une option pour simplement relancer le serveur Samba sans avoir à relancer la box, je pense que ça suffirait

Bonjour mmakassikis,

la sauvegarde pèse 140 G0 environ.

ca faisait au moins 3 ans que ça fonctionnait comme ça et sans aucun soucis, je ne vois vraiment pas pourquoi du jour au lendemain le problème est survenu.

Cordialement.

il parle à un serveur SMB

Aucune modification d'Acronis (les màj sont payantes), il fonctionne avec une sauvegarde sur HDD USB.
A en perdre mon latin.
Merci pour ton aide.

Bonjour

Pour moi, ça ressemble à un souci sous-jacent dans la box.

Voici mon expérience avec SAMBA et la freebox delta:

Je pense que le canal IO du SnapDragon ARM64 de la delta n'est pas fait pour des HDD (un problème électrique?), avec 2 HDD "WD10JPVT Scorpio Blue" de 1 tera + celui vendu par Free avec la delta dans le pack delta originel du 4 décembre 2018 qui est encore moins bien que ceux cités (c'est un WD10JUCX sans correction d'erreur), le tout montés en RAID5 j'avais beaucoup de problèmes d'instabilités lors des lourds transferts avec Samba

J'entend par lourd transfert plus de 50 giga. J'avais un backupset de ~100 giga qui était copié sur la delta chaque nuit et au moins 2 matins par semaines, je retrouvais la box dans un état incertain

Depuis j'ai fait un RAID5 avec 4 disques SSD SAMSUNG 870 QVO 8T (les moins cher du marché pour cette voluméterie) achetés ici :
https://www.amazon.fr/Samsung-870-SATA-interne-MZ-77Q8T0BW/dp/B089RD13TX/ref=sr_1_10?m=A20IHUMHDHIEXS&marketplaceID=A13V1IB3VIYZZH&qid=1674551650&refinements=p_4%3ASamsung&s=merchant-items&sr=1-10

La grappe fait de quasiment 23 tiB effectifs et depuis je pose des teras régulièrement sur la freebox en SAMBA sans aucuns soucis autres que les perfs qui ne dépassent pas 3giga bit par secondes en écriture multithread sur le RAID5 de ~23t

Entre la box et le serveur en samba j'ai 3 gb/s en écriture et jusqu'à 5 ou 6 gb/s en lecture (en matraquant les threads)
Le serveur n'est pas en cause, il envoi et reçoit des trames RDMA à beaucoup beaucoup plus que 10gb/s sur le même réseau physique

Je sais que la box n'est connectée qu'à 10gb/s mais ce serait bien d'avoir au moins 8 à 9gb/s en SAMBA vers la box

Voici la ligne de mount :

//10.0.10.100/FBX24T /mnt/fbx/FBX-24T 		 cifs credentials=/etc/samba/.smbcredentials,rw,nounix,iocharset=utf8,uid=1013,gid=1013,file_mode=0660,dir_mode=0750,nofail,cache=none,x-systemd.automount,vers=3.0,rsize=32768,wsize=32768,mfsymlinks,user,_netdev 0 0

Notez les valeurs des buffers 'rsize=32768' et 'wsize=32768', de tous les tests que j'ai fais, ce sont les meilleures valeurs possibles dans cette configuration

Cependant, à part les soucis de performances, depuis le changement de type de stockage (SSD contre HDD), j'envoi très régulièrement des lourds transfert sans aucun soucis, le dernier date du 22/01/2023 et fait 811g qui ont étés écrit en 40 minutes sur la box (~3g/s)

Le paquet utilisé pour monter le share samba est 'cifs-utils 2:6.11-3.1+deb11u1'

Donc il faut peut-être chercher au niveau du hardware présent dans la box …

PS: j'ai également du changer la RAM pour une barette de 16g Corsaire CMSX16GX4M1A2666C18 . au début j'avais mis une CMSX16GX4M1A2400C16 mais le C16 n'a pas été accepté.

PS2: Pour de lourds transfert en SAMBA vers une grappe RAID de la box, pas sûre que les 2g de RAM initialement présent dans la box soient suffisant . Le daemon multi-device à une emprunte mémoire faible, certes mais il y a un facteur d'échelle à ne pas oublier quand on commence upgrader les composants (SSD, RAID, SFP+):
4GigaBytes de cache disk en RAM = 3 secondes de buffer sur un transfert à 10gb/s et 10s de buffer sur un transfert à 2,5gb/s ⇒ ce n'est pas bien gros pour laisser respirer le système entre 2 appels IOwrite.

Donc sur ma barette de 16G, j'en alloue entre 8G et 12G (au max) pour les VM et je laisse un minimum de 4G pour le chassis de la delta

Et en globalité avec cette conf c'est fiable et plutôt satisfaisant (au souci de performances près que 99% des personnes ne remarqueraient même pas)

Cordialement
nbanba

Je fais ce type de sauvegarde depuis la nuit des temps… depuis l'époque Revolution, donc bien antérieurement à la plupart des gens ici.
J'ai utilisé Acronis, un peu TB Backup, j'utilise actuellement Reflect

Le plantage SMB était déjà sous jacent sur la Revolution, la Delta n'a rien vraiment changé sur ce point

On arrive à faire des sauvegardes dans certaines conditions, j'ai donné les indications, il faut définir des sauvegardes fragmentées par petits blocs de préférence.
Sur des sauvegardes d'un seul tenant qui dépassent admettons les 50 GB… il y a très peu de chances de réusssite, il faut impérativement fragmenter par petits blocs
Le Wifi est à proscrire. Sur le Wifi, il y a des variations de débit trop importants, et le Wifi a sans doute plus de propension à perdre des paquets.
Pour une sauvegarde cablée de 20/30 GB d'un seul bloc ça peut passer en effet…. c'est au bonheur la chance

J'utilise les Freebox depuis la verision V4
Dans la plupart des cas définir une sauvegarde fragmentée par blocs de 5GB résoud le problème, c'est ce que je fais depuis des lustres.
Je fais parfois des backup de 120 GO au total…
…mais Arconis/Reflect balancent par blocs fragmentés de 5GB et ça passe si je ne bidouille pas le PC en meme temps, et si je désactive les antivirus et pare feu commerciaux.

Les pistes que je peux donner aux DEVS pour ce problème :

1) NETBIOS

MERCI AUX DEVS DE REGARDER LA LISTE DES BUGS

FS#37424

J'ai signalé il y a quelques temps qu'avec SMB2, NETBIOS ne fonctionne plus

J'ai encore eu confirmation récemment en ouvrant Windows que je n'avais pas ouvert depuis ce message.
Windows explorer détecte bien le NAS Freebox, mais pas l'explorateur de fichiers Multicommander que j'utilise depuis peut etre 10 ans maintenant.
Avant ça marchait nickel.
La conclusion est que multicommander s'appuie sur le protocole NETBIOS pour découvrir les partages réseau SMB, alors que Windows explorer parvient à utiliser un mécanisme alternatif,SSDP probablement
En revanche si je tape le chemin complet manuellement dans Multicommander, il trouve bien l'emplacement car il doit dans ce cas utiliser un cache généré par Windows explorer, c'est juste la phase de découverte des partages qui échoue et qui repose sur NETBIOS concernant Multicommander)

On ne peut pas exclure qu'Acronis a un moment relance une requete NETBIOS… qui échoue, ce qui couperait la connexion.
Mais ce c'est qu'une hypothèse
Ceci étant le problème existait bien avant, déjà à l'époque de la Révolution, donc le dysfonctionnement de NetBIOS n'est en aucun cas une explication, mais un facteur aggravant qui pourrait expliquer ici que la sauvegarde de l'auteur de ce fil, qui machait jusque-là se met à planter.

Encore une fois… amusez vous tous à faire une sauvegarde de 120 GO d'un seul tenant, il n'y a que 0.5% de chances de réussite
Ici l'auteur semble parler de sauvegardes de tailles bien plus modérées en taille… donc ouais sans bloc fragmenté ça peut passer.

2) Paquets fragmentés : hypothèse la plus sérieuse

Il est possible que ce problèmes ait un lien avec les paquets fragmentés ce qui permet de faire un lien récent avec un sujet ouvert concernant la PS2

FS#37615

L'utiliszteur se plaint que suite au passage à la fibre, sa PS2 lui renvoie un message bizarre "votre routeur n'est pas compatible avec les paquets fragmentés"

Je rappelle que dans le monde Windows, la fragmentation des paquets réseau N'EST PAS LA REGLE (à ne pas confondre avec la fragmentation des disques durs).
Windows ne fragmente que très peu les paquets réseau. Sur certains pare feu Windows les paquets fragmentés sont meme par défaut bloqués car considérés comme de possible dangers (paquets isolés falsifiés générés par un attaquant)
Néanmoins Windows reste compatible avec les paquets réseaux fragmentés.

En revanche sur les systèmes Linux, BSD, la règle est inverse.
Sans doute pour des question de rapidité, par défaut ces systèmes ont tendance à générer énormément de paquets réseau fragmentés.
Typiquement le systèmes de partage NFS est connu pour fragmenter comme un vrai porc.
C'est l'une des raisons d'ailleurs qui motivent certains admins à préférer Samba à NFS meme sur Linux, car encore une fois certains admins n'aiment pas forcément les paquets fragmentés, je vous renvoie à la raison ci-dessus, d'autant plus si on parle de réseaux hétérogènes melant Linux et Windows Server.

Bref, je suppute que :

- la PS2 pour des raisons de sécurité refuse les paquets fragmentés. Le message d"erreur renvoyé ne serait pas pertinent. Il serait à interpréter dans le sens :
"votre routeur doit défragmenter les paquets réseau avant de me les faire parvenir"

- Samba par nature ne doit pas aimer les paquets fragmentés, puisque l'on connait sa proximité de conception avec le partage Windows.
Or cette fragmentation pourrait fortement se manifester lors de stress réseau. Remontez à ce que j'ai indiqué auparavant.
Si on commence à bidouiller sur internet pendant que le PC fait son backup, il y a 9 chance sur 10 de faire péter la sauvegarde.
De meme que si un appareil réseau tire fortement sur la connexion, là aussi je soupçonne un stress réseau qui augmente les paquets fragmentés
A mon avis, Samba ne tolère les paquets fragmmentés que dans une certaine mesure, en tout cas il est nettement moins tolérant que NFS

A voir si éventuellement dans les milliards de paramètres de Samba, il n'y aurait pas quelques paramètres permettant de régler la tolérance aux paquets fragmentés.

Dans le monde BSD, la fameux pare feu Packet Filter, le dieu des pare feux, meme reconnu comme tel par de nombreux linuxiens, offre si je me rappelle bien trois modes :

- refus de la fragmentation. Le système BSD local ne génèrera pas de fragmentation, et refusera les paquets fragmentés entrant
- fragmentation : on va dire le mode normal des systèmes Linux/BSD/UNIX. Le parefeu va renvoyer les paquets au fil de l'eau, donc pas forcément dans le bon ordre, c'est le client final qui se démerde
- Reorder : c'est le mode que je choisis pour les systèmes BSD ayant une fonction de passerelle. Le système accepte les paquets fragmentés entrant mais les réordonnent avant de les faire suivre au client. A cette fin il faut définir un délai d'offset qui déterminera à partir de combien de secondes un paquet doit etre déclaré perdu afin de ne pas bloquer trop longtemps la connexion

Ainsi, Packet Filter n'enverra jamais le paquet C avant d'avoir reçu et envoyé les paquets A et B sauf délai d'offset dépassé

Je suppute que IPTABLE ait des options similaires, et JE PRECONISE l'option REORDER (si ce n'est pas déjà l'état actuel bien entendu) qui à mon avis pourrait résoudre pas mal de soucis en améliorant la compatibilité avec certains appareils.
Les gamers, une bonne partie de la clientèle Free, en général détestent les paquets fragmentés sur ce que j'ai pu entendre… ça crée pas mal d'ennuis, donc ça ne me surprendrait pas trop que la PS2 soit effectivement paramatrée pour refuser la fragmentation.

Ceci n'est qu'une piste.

3) SMB1 / SMB2
D'une façon paradoxale, il est possible que ce problème se soit aggravé avec SMB2
En effet, sous la Revolution avec les indications que j'ai données, mais backup fonctionnaient, et je n'avaient pratiquement jamais à redémarrer quoique ce soit
Acronis me simplifiat les choses car j'utilisais le mode de sauvegarde incrémentiel, c'était donc les "full backup" qui étaient vraiement critiques
Avec Reflect, vu que je n'utlise que la version gratuite, je ne fais que des "full backup" ou du "différentiel"

Avec la Delta, j'ai quand meme l'impression d'avoir plus d'emmerdes. Le partage Samba qui se met à déconner (fichier inaccessible, écriture interdite… et tout rentre dans l'ordre si on reboote le serveur) ça arrivait sous la Révolution, mais c'était assez rare.
Avec la Delta, si je fais un backup, meme si ce backup réussi, il y a 50% de chance pour que le serveur Samba se mettent à déconner après contre 2% de proba avec la Revolution

La différence bien sur c'est que sur la Révolution j'étais en SMB1
Il est possible que l'accélération des débits de SMB2 le rende encore plus sensible aux soucis de fragmentation.
Et encore que…. je ne suis passé au SMB2 que très récemment avec ma Delta.
Si SMB2 n'arrange rien, le SMB1 + Delta semble moins fiable que SMB 1 + Revolution

Doit on en conclure que la différence hardware ferait que la Delta génèrerait plus de paquets fragmentés que la Revolution ?

NIVEAU HARD : J'ai une barrette de 16 GO. 12 alloués à la VM, 4 à la Freebox, d'ailleurs on peut très bien imaginer que les VMs soient elles aussi un facteur augmentant la fragmentation des paquets, à ceci près que je ne suis pas certain que l'auteur de ce fil ait paramétré une VM

@nbanba

Je pense qu'on est en train de s'égarer.
j'ai un raid de 4 disques mécaniques WD Blue… copier un fichier de 120, 200 GO depuis ou vers samba, ne pose pas problème. Ca prend le temps qu'il faut mais ça ne pose pas problème, ça ne déstabilise pas le serveur.

La destabilisation du serveur intervient avec un système de sauvegarde en ligne de type VSS (Acronis, Reflect…) qui semblent utiliser une méthode particulière d'écriture.

Vous, je ne sais pas vraiment de quoi vous parlez… vous nous parlez d'un truc de 800 GO

Si la grappe Raid était en cause, mécaniquement ma machine virtuelle partirait en vrille, puisqu'elle se trouve elle meme sur cette grappe. Ce n'est pas le cas. La Freebox dans son emsemble fonctionne, il semblerait que ce soit Samba qui soit mis dans un été instable.

Les sauvegardes acronis du reste marchaient assez bien sur la Revolution et son malheureux petit disque dur, donc SVP arretez avec les délires de kékés : SSD MAX, mémoire max

La Delta a été conçue pour fonctionner avec moins de 2 GO. Que vous lui mettiez 4, 8, ou 16 GO, ça ne change rien, elle ne sait pas se servir de cet excédent, il semble que ce soit une restriction "by design"

Du reste, les NAS de marques QNAP qui peuvent gérer des RAID n'ont que rarement 16 GO de RAM, donc il faut arreter avec ce fantasme.

Après, la question est de savoir si Samba effectivement n'aurait pas besoin d'un peu plus de mémoire pour mieux s'épanouir…. pourquoi pas, mais dans ce cas les devs doivent lever certaines restrictions pour que la Box puisse effectivement utiliser un excédent de mémoire qui existerait au delà des 2 GO

Bonjour

Merci pour vos retours.

Oui la box fonctionne bien globalement et samba aussi lors des transfer "standards".

Désole, je n avais pas précisé mais de mon côté c est la réplication netbackup qui a écrit les 811gb effectifs sur la box.
C est pour ça que je comuniquais mon retour d expérience avec une autre techno.

Effectivement le mode d envoi des paquets par acronis semble être en cause.

Concernant la ram le noyau Linux à pour habitude de l utiliser comme buffer/cache notamment pour les accès disques et je ne dis pas de tout gonfler au maximum, mais de rester cohérent avec ce que l on fait, et quand on échange avec un système des centaines de giga ou des teras à plusieurs gigabits par secondes, nécessairement tous les composants de la chaîne doivent pouvoir suivre.
Et j avais des soucis de stabilité samba / delta avec des disques à plateaux dans la grappe raid, mais depuis changement de disques je n en ai plus et c'est le même serveur netbackup qui écrit dessus (la version nb a changée depuis).
D'où mon retour d expérience

PS: je n'ai jamais fractionné les backupsets, j aurai probablement dû…

Cordialement
nbanba