Contexte

Un client a besoin d'une solution de sauvegarde automatisée sur un disque externe (à emporter hors site chaque semaine). Je suggère généralement rsnapshot (ou peut-être déployer un rsyncscript personnalisé ), mais cette question est légèrement plus complexe.

Le système basé sur Arch Linux est sans tête et donc la solution doit être entièrement automatisée, ne nécessitant aucune intervention de l'utilisateur.

Un scénario idéal serait le suivant:

1. L'utilisateur branche un disque dur USB
2. Une sauvegarde incrémentielle complète est effectuée
3. Le disque dur est démonté
4. L'utilisateur est informé que le disque dur peut être débranché

Proposition

Ma solution proposée consiste en:

1. Une udevrègle monte automatiquement le lecteur

2. La sauvegarde démarre avec:

   1. La même udevrègle déclenche également un rsnapshotscript
   2. Un événement inotify create détecte le nouveau point de montage et déclenchersnapshot

3. Après les rsnapshotsorties, umountest exécuté sur le lecteur

4. Les moyens possibles de notifier le disque dur peuvent être supprimés:

   1. Le lecteur de CD s'ouvre
   2. Un son est diffusé via le haut-parleur du PC

Si une erreur s'est produite à un moment donné, envoyez un e-mail à l'utilisateur et démontez le lecteur.

Des questions

1. Ma proposition semble réalisable mais y a-t-il des défauts évidents? Comment puis-je le rendre robuste?
2. Pour des raisons de sécurité, comment puis-je m'assurer que le disque dur branché est celui de l'utilisateur? sshclés? Étiquette de lecteur?
3. Existe-t-il des solutions (Linux) qui englobent cela?

Votre solution semble cependant relativement adaptée:

• Assurez-vous que le rsnapshotscript ne présume pas connaître le périphérique de bloc. Adressez idéalement le système de fichiers par son UUID ou son étiquette pour éviter le carnage.
• Ajoutez des délais. De cette façon, si quelque chose se passe mal que nous ne connaissons pas, ou si quelque chose fait que le script ne se termine jamais, il peut être traité comme une erreur au lieu de continuer indéfiniment.
• Vous déclarez qu'à la fin "[i] si une erreur s'est produite à tout moment, envoyez un e-mail à l'utilisateur et démontez le lecteur" - que se passe-t-il s'il ne peut pas démonter le lecteur, ou si le démontage est là où il échoue? Que se passe-t-il si l'e-mail échoue? Assurez-vous de créer des pannes de sécurité dans votre système.
• Pour la sécurité de base, l'UUID devrait être correct (sauf si un attaquant pourrait avoir connaissance de votre UUID), cependant, si la sécurité est plus un problème, envisagez d'écrire des données dans la zone de code du MBR (octets 0-440), et faire vérifier le script avant de commencer la sauvegarde. Vous devez être averti que c'est plus de sécurité par l'obscurité que toute autre chose, mais dans cette situation, je ne vois pas de méthodes facilement disponibles qui soient supérieures. Toutefois, si vous souhaitez suivre le chemin complet, vous pouvez déterminer si le lecteur est autorisé en analysant un certificat chiffré stocké sur le disque. Quandudevdétecte le lecteur, le script déchiffre le certificat à l'aide de sa clé. Le certificat contient des paramètres relatifs au lecteur, tels que le numéro de série du lecteur, le numéro de modèle, la capacité, etc., puis compare les paramètres extraits du certificat chiffré avec les paramètres vus lors de l'analyse du lecteur. Si les paramètres correspondent, le lecteur est déterminé comme étant authentique, sinon le lecteur est rejeté et le script se termine.

Il existe des solutions Linux existantes qui relèvent de cette mission, cependant, pour vos besoins spécifiques, je pense que vous feriez mieux de créer une solution sur mesure au lieu de tripoter la source d'autres programmes pour les amener à faire ce que vous voulez.

Pour écrire des données aléatoires dans la zone de code du MBR, que vous pouvez ensuite vérifier, faites quelque chose comme dd if=/dev/urandom of=/dev/sdX bs=440 count=1.