Psychofox a écrit 10949 commentaires

J'aurais plutôt utilisé une de ces colles qui s'active aux rayons UV. C'est plus facile d'application, notemment si le bol est transparent. J'ai réparé le bac à légume de mon frigo avec ça.

Tous les trucs que vous mentionnez semble des cas hyper particuliers qui auraient du faire l'object d'un bug report plutôt que de contourner le problème.

J'ai fais tourner fedora 34 et maintenant la 35 sur 4 hardware différents sans rencontrer un seul problème de son. Au contraire avec la version 34 et pipewire j'ai pu bénéficier d'amélioration de la qualité des casque bluetooth quand on utilise le micro avec le support de mSBC qui était désactivé par défaut sur les versions précédentes. Je peux maintenant discuter en visio conférence sans utiliser de dongle usb spécial et sans avoir avoir l'impression d'être Nicolas Hulot dans un hélicoptère. Donc je dirais que globalement ça n'a fait que s'améliorer.

J'ai vu quelqu'un commander une pizza tartiflette dans un restaurant près d'Annecy. J'ai vu ça comme un signe de la fin imminente de la civilisation.

Qu'est-ce que c'est que cette hérésie qui veut mélanger raclette et charcuterie???

De toute façon quelque soit le nombre de personnes, ça ne se compte pas en grammes mais en nombre de demi-meules.

La monnaie normale peut aussi être échangée. Et elle l'est relativement facilement, et la plupart du temps sans commission pour les particuliers.

Du coup c'est quoi l'intérêt ? Évasion fiscale ? Blanchiment d'argent ? Vie privée ?

Différentes options:

• stockage copie papier et sdcard dans un coffre à la banque
• stockage copie papier et sdcard dans une enveloppe dans un lieu relativement sûr (un tiroir scellé chez son employeur par exemple) ou chez quelqu'un de confiance.
• stockage de la clé en ligne chez quelqu'un de confiance.
• stockage en ligne sur un autre cloud (par exemple un service de gestion de password)
• stockage sur un vps (je dirais que c'est probablement la solution la plus dangereuse en terme de secu mais bon si elle n'est pas couplée à un autre secret, comme les clés d'api pour stocker les backups ou le compte d'accès au stockage distant c'est moins grave)

Toute combinaisons de ces propositions.

Dans tous les cas la clé de chiffrement est forcément présente sur l'ordi protégé ainsi que les clés API pour copier les données, sauf si on passe par une serveur de backup local. Il faut donc dans ce cas s'assurer de l'immutabilité des données distantes en utilisant des clés d'API qui n'ont pas de droits administratifs. Idéalement si on ne passe pas par une serveur de backup local, il vaut mieux avoir des clés de chiffrement et d'API différentes pour chaque pc protégés et que celles-ci n'aient accès qu'à des espaces séparés (buckets s3 différents, etc) et on ne copie les clés d'e chiffrement et d'API d'une machine à l'autre que sur un besoin ponctuel pour restaurer les données sur un autre ordi.

Il ne faut pas long pour se rendre compte qu'il est fou à lier.

Je crois que c'est le gars qui trolle via le site debian.community (qui n'a rien à voir réellement avec debian, à part vouloir leur nuir).

ah ben du coup merci de me faire découvrir dqlite ! Il est peut-être plus robuste je vais voir ça.

Le pire c'est que j'ai du utiliser dqlite sans m'en souvenir dans le passé…via des cluster k3s.

…on en revient à n'accepter des appels que depuis nos contacts sur nos téléphones personnels.

Je n'ai personnellement jamais compris l'intérêt de la classe APIPA.

Je ne crois pas que la fonctionnalité existe mais si j'avais besoin je ferais ça depuis un vps avec minio ou rclone.

C'est un choix à faire en fonction de l'investissement.

Dans le cas de Wasabi, j'imagine que si j'ai une destruction locale totale je ferais une synchro du bucket vers un bucket dans un autre datacenter avant de rapatrier toutes les données. C'est relativement vite fait.

Personnellement je pense que le point le plus important avant d'avoir n copies c'est de vérifier régulièrement l'intégrité des données sur l'unique sauvegarde hors-site, chose que j'avoue n'avoir pas encore automatisé. Parce que bon synchroniser sur 3 sites différents des fichiers corrompus, ça a peu d'intérêt.

Ben l'idée c'est justement que tu n'utilises pas impress ou powerpoint mais ton éditeur de texte/code favori.

Et il y a plein de frameworks conçus pour aider ceux qui ne parlent pas couramment le html:

https://gist.github.com/johnloy/27dd124ad40e210e91c70dd1c24ac8c8

Je pars du principe que je peux tout perdre du jour au lendemain. Domicile qui brûle, tremblement de terre, tsunami, que sais-je :)

Si j'ai une copie dans un autre pays c'est pour pallier à ce genre de merde.

Alors certe au début je n'aurais surtout besoin que des papiers administratifs et pas de ma collection de photos et souvenirs de ces 20 dernières années qui peuvent attendre un peu plus. Mais je dois aussi penser qu'une fois que j'ai tout perdu, ma copie unique est celle externalisée, donc j'ai tout intérêt à récupérer toutes les données et en avoir une copie locale. On sait jamais qu'un coup de loi de murphy fait qu'ils aient eux-même des problèmes ou qu'un problème de facturation fait qu'ils te dégomment tes données.

Je ne comprends d'ailleurs pas cet engouement récent pour medium. Ça apporte quoi réellement ce truc à part centraliser du bordel sur une plateforme ?

Ça ne change pas que si ça prend 3 semaines à copier, c'est bien plus chiant que de se faire livrer des disques en 2-3 jours ouvrables. Et accessoirement si tu es dans un cas de disaster recovery avec perte totale, ton environnement local tu l'as pas et dois le reconstruire d'abord en achetant du matériel. Ça ralentit d'autant plus la démarche (et faut avoir penser à garder ses secrets, comme les clés de chiffrements, accessibles ailleurs que sur le backup our l'environnement à reconstruire.

Je crois que crashplan et backblaze ont un service d'envoi de disques, moyennant une modique somme, mais la dernière fois que j'avais vérifié c'était valable uniquement aux USA.

Je suis le seul à trouver à peu près inutilisable l'appli nextcloud sur android?

Alors oui elle synchronize mes photos et vidéos mais plus ou moins quand ça lui chante et l'appli se fige bien souvent quand on veut la consulter.

Ce qui compte c'est la bande passante. Pour récupérer les données tu renvoies Thomas ou ses futurs collègues.

Je ne dis pas que ça n'existe pas (quand j'en avais 20 il y avait un ancien coureur pro italien qui faisait encore ses 80km par jour à 92ans en vallée de chevreuse) mais ils n'ont pour la plupart pas commencé à 60ans!

J'utilise restic (et duplicati sur le windows de ma copine) sur du stockage objet wasabi.

Le tout est chiffré.

Il y a quelques années j'avais utilisé crashplan quand ils avaient une offre particulier similaire à backblaze. Les backups/restore entre appareils locaux étaient très efficace mais un jour j'ai testé restaurer 1TB depuis leurs serveurs, les temps de download étaient à des années lumières de leurs temps d'upload si bien que ça aurait pris plusieurs semaines de copie continues. Inutilisable en cas de désastre donc

Bref testez vos temps de restauration, ça peut être important si un jour vous souffrez d'un incendie ou grosse perte de données.

Le pdf c'est merdique pour autre chose qu'un truc qui a vocation d'être imprimé. Vous connaissez beaucoup de présentations qui finissent imprimées?

On a inventé un truc pratique qui permet d'avoir du contenu lisible sur des appareils de tout type de taille d'écran, qui permet de jouer différents types de contenu multimédia, sur lequel on peut même jouer l'audio voire la vidéo de présentation. Ça s'appelle HTML5 (+css). C'est bien plus pratique qu'un pdf ou une vidéo sur youtube et ça se partage facilement.

Et je ne suis pas un excité du javascript, mais c'est bien un cas d'usage ou un peu de javascript peut aussi aider sans le rendre obligatoire.

Il me semble que tu bottes en touche. Si tu as besoin d'écrire un script spécifique pour que backuppc trouve les données à ingérer, c'est que t'as besoin de faire de même pour recopier les données au bon endroit quand tu restaure…Ton script ne rend pas backuppc omniscient.

Un backup, une fois fait, tu peux (et même doit) le tester. Ton snap, non, à moins de le remonter. Mais si tu le remontes, c'est que tu as un souci, et si tu as un souci lorsque tu le remontes, il est trop tard pour faire une sauvegarde.

Qu'est-ce que tu entends par "le remonter"

Pour tester une sauvegarde, on restore les données, quelque soit la manière de faire une sauvegarde. Et si la BD est stoppée, si c'est fiable.

Et un admin compétent ne coupera jamais une BD 5s le temps de faire le backup alors qu'il existe nativement la possibilité de le faire sans.

Tout dépend de l'utilisation. Pour une BD avec n accès concurrents à toute heure de la journée et pas de lien vers des données sur des fichiers "traditionnels" oui je suis d'accord.

Pour une BD utilisée par une seule application, avec une foultitude de lien vers des fichiers attachés, stopper l'application et et faire un snapshot du volume où sont stocké les fichier est la meilleure manière d'avoir une cohérence entre BD et fichiers attaché. Si on fait ça quite à stopper l'appli on peut aussi décider de stopper la BD et la sauvegarder de la même façon si par exemple ça fait économiser le prix d'une licence pour un connecteur de base de donnée du logiciel de backup ou accélère le temps de restauration des fichiers.

Cela permet de fournir une autre manière d'avoir des backups automatisés pour les SGBD, où sauvegarder directement les fichiers est une TRES mauvaise idée.

Ça dépend de la granularité de récupération que tu veux avoir.

Si tu veux pouvoir restaurer une db/une table ou quelques lignes effectivement c'est nul.

Si tu veux juste du disaster recovery pour pallier à des gros crashes, c'est plus rapide de couper 5 secondes, faire un snap et relancer et faire un backup du snap.

Tout dépend en fait si c'est une db partagée par des applis/clients multiples ou si c'est juste une db embarquée avec une appli métier.