ckyl a écrit 3877 commentaires

Je confirme ça correspond au premier screening rapide faire par un recruteur. Tu sais parfaitement que tu as en face de toi un recruteur et non un techos. Tu sais aussi parfaitement que l'objectif de l'appel est de filtrer les plus mauvais avant d'accorder les deux entretient téléphoniques d'une heure avec des ingés qui eux mêmes te servent à décrocher une journée d'entretien sur site.

Il est certainement tombé sur un mauvais recruteur et de mauvaises questions. Mais d'un autre côté on peut aussi se dire qu'en s'adaptant au public et a l'exercice il n'aurait eu aucun problème. Ça peut d'ailleurs être utile d'être aussi capable de faire ça.

On peut reprocher beaucoup de choses au processus de Google mais là bof.

Je t'ai décris la version de base du début du siècle.

Depuis c'est une course sans fin à l'armement et, les mobiles et tablettes étant passés par la, l'objectif est de pouvoir suivre de plus en plus finement un utilisateur en cross device et de pouvoir séparer les utilisateurs d'un device.

Quand tu paies une fortunes plein de gens intelligents pour bosser sur le problème ça te donne des choses comme ça https://m.facebook.com/business/a/performance-marketing-strategies.

Je ne serais pas étonné que les gros ne soient pas gêné tant que ça par la segregation des cookies. A priori, il y a des signaux assez évident dans la données pour recoller ou redécouper le tout. Plein des gens rapporte actuellement qu'amazon est capable de faire du retargeting sur FB alors qu'ils utilisent des navigateurs differents, des comptes différents et des mails différents.

Twitter se fiche totalement de ton cookie de session linuxfr. Ce qui les intéresse c'est de pouvoir associer un id à eux avec des contenus visités.

Si tu n'es pas identifié chez eux, ils te collent un cookie guest_id sur .twitter.com à la première requête que tu leur envois en third-party et qui te colleras aux basques tout le temps. Si tu es identifié chez eux, ils te colleront un _twitter_sess. Dans les deux cas, à chaque fois qu'une page affiche l'un de leurs boutons (qui ne sont pas que des images), ils récupèrent d'où ça vient et l'associe à leur id. Voilà maintenant tu peux faire plein d'analytics, afficher une pub personnalisée lorsqu'un publisher t'indique qu'il a un espace à afficher pour cet id, ou pleins d'autres trucs.

Ton navigateur n'enverra pas ce cookie s'il va chercher une image sur twitter.

Non mais de toute façon ce n'est pas celui là qu'ils voulaient. Le jeu étant de trouver comment créer l'identifiant, de le faire survivre le plus longtemps possible ou de savoir les rapprocher.

Si tu reviens au commentaire racine, segmenter son cookie jar pourrait permettre de rendre les rapprochement d'id un peu plus difficiles. Twitter te suis avec ta _twitter_sess dans le container où tu l'utilises mais chaque autre container aura un id différent. À voir l'efficacité par rapport à d'autres approches.

on parle d'une entreprise qui utilisera l'argent d'investisseurs des précommandes.

Défragmenter des fichiers sur un SSD est inutile

OK. Donc si on va jusqu'au bout du raisonnement, tu veux dire que si aucun bloc de ton (FS|fichier) n'est séquentiel ça ne pose aucun problème ?

Faisons un petit test sur un "vieux" SanDisk Ultra II (SDSSDHII480G) avec LVM + luks + ext4:

$ cat seqread.fio 
[seqread]
rw=read
size=4g
directory=/xxx/fio

$ fio seqread.fio 
seqread: (g=0): rw=read, bs=4096B-4096B,4096B-4096B,4096B-4096B, ioengine=psync, iodepth=1
fio-2.18
Starting 1 process
seqread: Laying out IO file(s) (1 file(s) / 4096MiB)
Jobs: 1 (f=1): [R(1)][100.0%][r=235MiB/s,w=0KiB/s][r=60.1k,w=0 IOPS][eta 00m:00s]
seqread: (groupid=0, jobs=1): err= 0: pid=7370: Tue Aug 15 12:58:14 2017
   read: IOPS=59.7k, BW=233MiB/s (244MB/s)(4096MiB/17586msec)
    clat (usec): min=0, max=8186, avg=16.28, stdev=123.09
     lat (usec): min=0, max=8186, avg=16.34, stdev=123.09
    clat percentiles (usec):
     |  1.00th=[    0],  5.00th=[    0], 10.00th=[    0], 20.00th=[    1],
     | 30.00th=[    1], 40.00th=[    1], 50.00th=[    1], 60.00th=[    1],
     | 70.00th=[    1], 80.00th=[    1], 90.00th=[    1], 95.00th=[    1],
     | 99.00th=[  956], 99.50th=[  988], 99.90th=[ 1020], 99.95th=[ 1064],
     | 99.99th=[ 1544]
    lat (usec) : 2=96.33%, 4=1.13%, 10=0.66%, 20=0.25%, 50=0.06%
    lat (usec) : 100=0.01%, 250=0.01%, 500=0.01%, 750=0.01%, 1000=1.32%
    lat (msec) : 2=0.24%, 4=0.01%, 10=0.01%
  cpu          : usr=4.05%, sys=9.50%, ctx=16556, majf=0, minf=9
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwt: total=1048576,0,0, short=0,0,0, dropped=0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
   READ: bw=233MiB/s (244MB/s), 233MiB/s-233MiB/s (244MB/s-244MB/s), io=4096MiB (4295MB), run=17586-17586msec

Disk stats (read/write):
    dm-1: ios=16233/21, merge=0/0, ticks=32472/42, in_queue=32525, util=99.52%, aggrios=16433/24, aggrmerge=0/0, aggrticks=32844/42, aggrin_queue=32890, aggrutil=99.43%
    dm-0: ios=16433/24, merge=0/0, ticks=32844/42, in_queue=32890, util=99.43%, aggrios=16431/9, aggrmerge=2/15, aggrticks=24757/23, aggrin_queue=24767, aggrutil=99.43%


$ cat randread.fio 
[randread]
rw=randread
size=4g
directory=/xxx/fio

$ fio randread.fio
randread: (g=0): rw=randread, bs=4096B-4096B,4096B-4096B,4096B-4096B, ioengine=psync, iodepth=1
fio-2.18
Starting 1 process
randread: Laying out IO file(s) (1 file(s) / 4096MiB)
Jobs: 1 (f=1): [r(1)][100.0%][r=17.5MiB/s,w=0KiB/s][r=4462,w=0 IOPS][eta 00m:00s]
randread: (groupid=0, jobs=1): err= 0: pid=7443: Tue Aug 15 13:02:44 2017
   read: IOPS=4460, BW=17.5MiB/s (18.3MB/s)(4096MiB/235079msec)
    clat (usec): min=106, max=401746, avg=221.49, stdev=467.85
     lat (usec): min=106, max=401747, avg=221.70, stdev=467.85
    clat percentiles (usec):
     |  1.00th=[  181],  5.00th=[  185], 10.00th=[  189], 20.00th=[  201],
     | 30.00th=[  209], 40.00th=[  211], 50.00th=[  213], 60.00th=[  217],
     | 70.00th=[  221], 80.00th=[  231], 90.00th=[  247], 95.00th=[  262],
     | 99.00th=[  298], 99.50th=[  362], 99.90th=[ 1160], 99.95th=[ 2064],
     | 99.99th=[ 7136]
    lat (usec) : 250=91.39%, 500=8.33%, 750=0.11%, 1000=0.04%
    lat (msec) : 2=0.07%, 4=0.02%, 10=0.03%, 20=0.01%, 50=0.01%
    lat (msec) : 250=0.01%, 500=0.01%
  cpu          : usr=1.63%, sys=30.37%, ctx=1049367, majf=0, minf=8
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwt: total=1048576,0,0, short=0,0,0, dropped=0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
   READ: bw=17.5MiB/s (18.3MB/s), 17.5MiB/s-17.5MiB/s (18.3MB/s-18.3MB/s), io=4096MiB (4295MB), run=235079-235079msec

Disk stats (read/write):
    dm-1: ios=1052300/5593, merge=0/0, ticks=223175/61682, in_queue=285049, util=93.76%, aggrios=1052598/5708, aggrmerge=0/0, aggrticks=221445/61682, aggrin_queue=283274, aggrutil=92.99%
    dm-0: ios=1052598/5708, merge=0/0, ticks=221445/61682, in_queue=283274, util=92.99%, aggrios=1052562/2206, aggrmerge=36/3534, aggrticks=190612/44612, aggrin_queue=234676, aggrutil=79.82%
  sdb: ios=1052562/2206, merge=36/3534, ticks=190612/44612, in_queue=234676, util=79.82%

Lecture séquentielle: 244MB/s 60K IOPS
Lecture aléatoire: 18MB/s 4K IOPS

En fait la vraie question est comment un FS donné fragmente dans une utilisation courante / donnée ?

Sur un FS classique tel que ext4, la fragmentation est, grosso modo, liée à l'augmentation de taille des fichiers. Si le bloc suivant n'est pas libre quand tu veux faire grossir un fichier, il faut en trouver un autre autre part. Sauf cas pathologique ça fragmente assez rarement, et on peut sûrement arriver à ton raccourci (ie. l'impact est suffisamment faible pour qu'on le néglige).

Sur un FS basé sur du COW je serais beaucoup moins sur. Je ne connais rien à btrfs, mais je peux imaginer de nombreux cas d'écriture ou le COW mène à une très forte fragmentation. On retombe sur des lectures purement aléatoires… 10x plus lentes. Et c'est peut être aussi pour ça que btrsfs à un outil de defrag et une defrag online !

https://btrfs.wiki.kernel.org/index.php/Gotchas#Fragmentation

Tu me fais un test comparatif de perf ssd + btrfs avec et sans fragmentation ?

à part pour réduire artificiellement sa durée de vie.

Tu me fais un calcul au dos de l'enveloppe ou une étude réelle ? Les SSD ne sont pas en sucre.

Je pense qu'il y a un gros mythe sur les SSD venant de la lenteur absolue dans seek HDD. Une lecture aléatoire sur un SSD reste un ou deux ordres de grandeur plus lente qu'une lecture séquentielle (Si tes blocs sont suffisamment gros, genre quelques MB, entre les seeks alors ça peut se masquer pour arriver à 25..50% de perte).

Pas de réponse à ta question sur btrfs. Peut être que ça fragmente suffisamment peu pour qu'on puisse l'ignorer mais autrement une lecture séquentielle est toujours préférable (ça vaut aussi pour la RAM et à peu près tout).

Ma question n'est pas entièrement rhétorique.

Depuis le début du thread des gens semblent dire que ce fournisseur de service était "spécial" d'un point de vu libre et vie privée. Ici un utilisateur dit qu'il va chercher un nouveau service "libre". J'aimerai comprendre ce que ce service avait de spécial et le rapport avec le libre:

• Des fournisseurs basés sur une pile logicielle libre il y en a des milliers (à vue de nez déjà n'importe quel web host qui n'a pas une pile Exchange)
• Des fournisseurs qui ne se financent pas t'affichant de la pub ou en revendant ton profile il y en a des milliers (à vue de nez n'importe quel fournisseur qui n'est pas l'un des gros + un compte gratuit)

Comme ça, j'ai l’impression qu'un gus à réussi à vendre^Wwmarketer un truc qu'en fait tout le monde fait sauf gmail / yahoo / Microsoft. Du coup je m'interroge et encore plus qu'en on dit chercher un service libre ensuite….

un service libre payant

C'est quoi un service libre ?

Si tu crois le premier bonimenteur venu qui surf sur une vague ou te promet ce que tu veux entendre tu vas finir par être déçu…

Apparemment beaucoup ici pensent que le service mail est important / critique. Vu le type de population ici, c'est un peu affolant de voir qu'une partie de ces mêmes gens se retrouve dans une situation comme celle-la:

• pas de backup
• pas d'analyse risque
• plan de sortie en cas de problème (je re-route mon domaine vers n'importe quel hebegeur)
• confier ses mails à apparemment je ne sais qui
• certains ne semblent même pas pouvoir survivre une journée avec accès webmail.

Bha non même pas c'est déprécié en Java 9 et ça va mourir aussi: http://openjdk.java.net/jeps/289

Perso j'attends avec impatience les nostalgiques qui vont finit par pondre un émulateur Flash libre pour faire tourner leurs jeux…

Au cas où tu n'es pas ironique, j'ai déjà vu ça pour du Wordpress. Il semble que ce soit le seul moyen sûrement atteignable en temps fini pour changer l'URL de base d'une installation Wordpress.

Question bête: c'est de l'incompétence pure des gens derrière WP ou faire des trucs aussi mal conçus permet de vendre du support - consulting ou je ne sais quoi ?

C'est un premier jet et je compte su le collectif, ici-même, pour m'aider à l'améliorer. Ton commentaire septique et son score ("pertinence") m'interpellent… :/

Ma question vise à te forcer à remettre en question ton approche actuelle. Je ne dis pas qu'elle est mauvaise, mais quand on rencontre un problème difficile il est toujours intéressant de vérifier si on est sur le bon chemin.

D'après ta liste d'objectifs, mon sentiment est que tu ne cherches pas une visualisation mais plusieurs. En cherchant à tout représenter sur un unique document, tu complexifies ton problème sans que j'y vois de plus-value pour ton audience.

Je peux imaginer deux approches:

Tu cherches à faire une page A4 que quelqu'un voudra absolument garder sous la main pour longtemps par ce que c'est un outil très utile. Alors tu as raison de chercher à représenter le maximum d'information sur un minimum d'espace. Mais pour concevoir un truc utile, il identifier les cas d'usages. Je connais bien les concepts d'Unicode et je ne vois pas comment ce document pourrait me servir. D'un autre côté, le fait que tu cherches à y caser le maximum d'information risque d'en faire un mauvais support d'introduction aux concepts ou un mauvais aide mémoire.

Tu cherches le meilleur moyen d'introduire visuellement les concepts, de les lier et de donner une idée de l'étendu des blocs et du nombre de caractères. Pour cette seconde partie, une représentation exhaustive du BMP sur de l'A4 peut donner le sentiment de "vertige" que tu sembles chercher. Ça sera parfaitement illisible mais tu feras passer ce message. Tu pourrais aussi t'amuser avec des infographie comme ca en partant de ce que les gens connaissent (ie. ASCII, français, blocs latin-X etc.) ou simplement utiliser 4 ou 5 anecdotes. Par contre pour introduire les concepts de code points, de blocs, de plan mais aussi de glyphes, de normalisation, d'équivalence, de collation etc. et tu utilises d'autres illustrations qui seront de bon aide mémoires.

Voilà, mon point de vue extérieur.

en expliquant juste les différences entre des outils plus anciens et les piwik / GA.

En fait Piwik a deux modes de fonctionnements:

• log analytics qui est similaire à ce que ferait awstats ou webalizer en bouffant les logs des serveurs web
• tracking API qui elle est similaire à GA.

On peut donc éviter la "requête HTTP supplémentaire", avec d'autres compromis bien entendu. Piwik étant un service, il reste forcément plus compliqué à déployer et maintenir qu'un script qui génère de l'HTML. Voilà maintenant chacun peu faire son choix !

Et pour te donner raison, on peut le dire gentiment ;)

Je prépare un cours sur Unicode. Je souhaitais pouvoir présenter une vue d'ensemble. J'ai ainsi commencé la réalisation d’un tableau reprenant les différents blocs de caractères…

Quelle est le but de ta vue d'ensemble ?

• pour ceux qui cherchent quelque chose en particulier, que ce soit un bloc ou un caractère, Unicode table fait parfaitement le job. En revanche ton image n'aura absolument aucun intérêt.
• pour expliquer Unicode, quel est l'intérêt de lister 100+ blocs avec 4 caractères d'exemple pour chacun ? Au bout de 4 blocs dont je n'ai jamais entendu parler j'ai compris le principe ! Les concepts importants sont eux noyés dans un inventaire à la Prévert.

Quitte à sortir panda autant afficher directement la distribution qui te permettra une observation complète plutôt que de se limiter à quelques vues arbitraires et limités. Des exemple avec Seaborn: https://seaborn.pydata.org/tutorial/distributions.html.

Au "pire" tu sors un histogramme.

Visualiser ses données c'est bien (cf. Anscombe's quartet)

La CNIL n'a aucun moyen d'action contre les GAFAM, à part le public shaming.

Je ne sais pas si elle a des moyens contre les GAFAM. Par contre pour avoir travaillé pour des entreprises intéressées par en savoir au maximum sur tout le monde, son avis me semble en général suivi. Après lobbying et avocats interposés bien sur. J'ai déjà vu des projets / produits s'arrêter suite à intervention de la CNIL, ce que je trouve positif.

Sûrement que certains ont la main assez longue pour lui faire un gros bras d'honneur, mais à choisir je trouve ça plutôt bien que quelqu'un essaie de limiter les dégâts. On peut toujours critiquer et se focaliser sur certains points, mais est-ce que ca serait mieux sans ?

Et vu la description du Journal, ça m'a l'air justifié non ? Le poste de Manageur a l'air vachement plus chiant que celui de Tech.

Je ne suis pas convaincu de la pertinence de ton critère. Il y a BEAUCOUP de boulot chiants et mal payés. Le seul lien que je vois étant celui de l'offre et de la demande qui en résulte. Mon cynisme hors limite me dirait que presque n'importe qui pouvant être mauvais manager et les mauvais managers n'ayant pas la possibilité de faire beaucoup d'autres choses, le prix ne devrait pas monter tant que ça (un bon manager par contre c'est rare et ca vaut de l'or)

Pas con, j'y penserais. T'as d'autres bon conseils du genre ? ;)

Non les commerciaux Amazon savent parfaitement que S3 est un object store et que HDFS est un file system (non POSIX et avec de nombreuses limitations).

Les deux n'offrent pas les mêmes garanties et n'ont donc pas la même utilité. Un object store étant beaucoup plus simple il est beaucoup plus facile de le scaler. La phrase Si tu bosses sur aws, 5 To sur s3 c'est peanuts. Pas besoin d'un cluster hdfs. est donc très étrange, je serais intéressé par une explication de texte.

Ça va te prendre 2h, couter environ 12 centimes, et tu pourras mettre ça sur ton CV.

Si c'est le critère pour mettre quelque chose sur ton CV tu peux t'attendre:

1. soit à te faire recevoir comme tu le mérites en entretient
2. soit à tomber dans une boite / projet constituée d'incompétents

Vu l'état du marché, tu as de grandes chances d'arriver à 2. auquel tu apporteras ta contribution !

Tu confonds Hadoop et Hive.

J'ai essayé de trouver d'où tu étais parti pour faire cette réponse et je n'ai pas pu trouver :)

Hive est un moteur de requêtage MapReduce en mode disque.

Non.

"The Apache Hive™ data warehouse software facilitates reading, writing, and managing large datasets residing in distributed storage and queried using SQL syntax."

Si on vulgarise beaucoup Hive c'est:

• un metastore qui gère les db & tables
• un compilateur qui transforme une requête SQL en un plan d'exécution
  
• un moteur d'exécution qui va transformer le plan d'exécution en une serie d'opération
• un driver qui est l'orchestrateur de tout ca

Historiquement le moteur d'exécution par défaut est MapReduce, c'est a dire que le moteur d'exécution transforme le plan d'exécution en une série de jobs MR. Un MR Hadoop "bête et méchant" a pour lui deux inconvénients d'un point de vue perf:

1. Le paradigme MR tire sa robustesse des checkpoints entre chaque phase. Par défaut Hadoop fait ça sur disque et quand les phases sont légères et nombreuses les IO deviennent le facteur nettement dominant.
2. La soumission d'un job Hadoop MR est très lente (~10s), c'est "juste" un problème d'implémentation.

Ça explique très certainement ton raccourci grossier, qui oubli aussi que ce que tu perds d'un côté tu le gagnes de l'autre (ex: espace d’adressage partagé et survivant entre traitements = Possibilités d'optimisations VS difficulté de gestion des ressources et instrumentation VS coûts ressources).

Mais MR n'est qu'un moteur d'exécution comme un autre. Tu peux brancher le moteur d'exécution que tu veux, il existe aussi des moteurs au dessus de Tez et de Spark. Au cours d'une requête tu peux parfaitement t'affranchir d'aller toucher le disque si tu veux, à l'exception de la lecture des données d'entrées et de l'écriture des résultats.

Si tu veux aussi éviter ces IO, comme tu le ferais avec des executors Spark peristant avec une RDD caché sur lequel tu fais de nombreuses requêtes SQL, tu peux aller voir LLAP. Rien de magique, tu ajoutes des démons qui survivent entre les requêtes et qui permettent de garder les données quelques part dans un espace d’adressage. Ça te permet supprimer des IO contre un coût de ressource plus important. Intéressant dans certains cas et pas dans d'autres.

Les concepts sont toujours les mêmes et on les réimplémente à tous les niveaux de la stack.

Spark en mode mémoire

C'est un raccourci tellement grossier qu'il n'est absolument d'aucune utilité.

Donc oui, Spark est plus rapide que Hive.

Soupir.

Le monde est malheureusement compliqué; tant sur le fait que de telles généralités sont toujours fausses que sur le fait que la latence d'une requête n'est qu'un ility parmi d'autres.

Rappel: Si ce n'est pas votre cœur de métier n'y allez pas ça va sûrement mal se passer.

Des centaines d'entreprises utilisent au quotidien Hadoop/spark depuis plusieurs années (Facebook,linkedin, Arkéia crédit Mutuel, EDF,Mappy, etc etc.

Oui les boîtes qui ont les moyens et le besoin de jeter des dizaines de mecs compétents sur le problème s'en sortent. Ce n'est pas lié à la techno utilisée qui ferait des miracles c'est du aux compétences mises en œuvre. Si tu n'as pas en interne des mecs qui auraient pu écrire l'outil que tu utilises, qui peuvent patcher le merdier perpetuel qu'est l'écosystème Hadoop (et redéployer demain en prod), de designer, déployer et diagnostiquer des systèmes distribués compliqués et tout ce qui va avec. C'est une mauvaise idée d'y aller. Et ça correspond à 99.9{1,10}% des gens.

Et je bosse aussi dans l’écosystème ..comme quoi on a tous des expériences différentes.

Fais un tour sur les mailing list, stack overflow, les confs. Les mecs qui savent vaguement de quoi ils parlent sont l'exception. Le reste n'est que du "tombe en marche".

Aujourd'hui quand on parle d'Hadoop, et donc très souvent d'une distribution (Cloudera, Hortonworks) , on ne sépare plus Spark qui est intégré de base.

Hadoop et Spark c'est bien la meilleure façon de transformer un truc qui aurait du être simple et robuste en un projet qui coûte 10 à 100x plus cher qu'il n'aurait du, qui est toujours en vrac et que personne ne sait troubleshooter.

Tout le monde en fait ou dit en faire. Personne ne maîtrise quoi que ce soit ni n'a la moindre idée de ce qu'il fait vraiment. Les perfs des solutions sont généralement à mourir de rire et les coût ops démentiels.

Ce sont des stacks compliquées qui demandent une grosse expertise dans beaucoup de domaines. Si ce n'est pas votre cœur de métier n'y allez pas ça va sûrement mal se passer. Enfin ce n'est que mon avis non hype driven development de quelqu'un bosse dans l'ecosystème depuis qu'Hadoop a été promu top-level chez Apache…

Ensuite dire qu'avoir une « image locale » [1] n'apporte aucune économie, est un "surcoût" pur et n'a absolument aucun impact dans le contexte du risque, c'est aussi très réducteur.

Ca me semble parfaitement exact. Pour tous les risques non couverts par ton "cache" tu dois garder EXACTEMENT la même stratégie tu ne peux faire aucune économie. Comme ton "cache local" ne gère qu'un petit sous ensemble de cas (peut-être très fréquents) en pratique c'est bien un surcout (pour possiblement une plus grande souplesse dans les cas les moins graves).

Maintenant tu fais l'analyse de risque que tu veux, ce sont tes données et je pense que tout le monde se fiche à la fois de risque que tu prends avec tes données et de savoir ce que toi tu penses de leur stratégie. En fait tu attends quoi de ce post ?

• Que quelqu'un te dise que t'as stratégie en bonne ? Alors elle l'est (ie. ce sont tes données)
• Que quelqu'un te dise que tu as découvert un truc fou ? Alors c'est aussi disruptif qu'un "rsync --link-dest" local, soit quelques décennies.

Tu ne ferais pas beaucoup de bruit pour dire un truc aussi simple que:

1. Pour être résistant à la perte / corruption d'un disque il faut une sauvegarde sur un autre support, dans une autre machine. Pour être résistant à la perte d'un site il faut une sauvegarde dans un autre site. Avec toutes les subtilités habituelles bien entendu.
2. Avoir à disposition une "sauvegarde" incrémentale sur le disque lui même permettrait d'optimiser l'UX dans certains cas, ie. PEBCAK ou corruption userspace.
3. À tolérance de risque égale, la "sauvegarde" locale n'a absolument aucun impact sur le premier point. Elle ne permet aucune économie et est un "surcoût" pur. Ça explique le dialogue de sourd entre ta vision et ceux qui te disent que ce n'est pas une sauvegarde -> ton truc c'est un "cache de sauvegarde" et c'est aussi nouveau que de faire un rsync --link-dest de son homedir dans son homedir pour avoir une timemachine.

Le reste n'est qu'analyse de risque.