Solution 1 :
Si vous effectuez une sauvegarde naïve (copie unique, écrasement de toutes les données), il n'y a aucun moyen d'obtenir ce que vous voulez - un attaquant peut toujours "sauvegarder" une pile de fichiers vides (ou un ensemble de fichiers vides), ce qui entraînera toutes vos données vont au revoir. Donc, je suppose ici que vous effectuez des sauvegardes d'archivage appropriées et que vous surveillez suffisamment bien vos sauvegardes pour que toute tentative d'éradication de la sauvegarde en envoyant un jeu de sauvegarde vide soit détectée avant que tout dommage permanent ne soit causé.
Si votre rsync-over-(probablement)-SSH utilise une commande forcée pour exécuter rsync sur la destination, alors vous êtes à peu près aussi sûr que possible de la suppression. Étant donné que vous ne souhaitez exécuter qu'un rsync spécifique commande, vous pouvez coder en dur tous les arguments, puis la seule chose qu'il peut faire est d'écrire de nouvelles données. L'archivage est assez simple en sauvegardant à chaque fois dans une nouvelle arborescence et en associant les fichiers inchangés à la sauvegarde précédente à l'aide de liens physiques, ce qui économise de l'espace et du temps de transfert.
L'autre solution consiste à utiliser des sauvegardes par extraction, où le serveur de sauvegarde lance et gère le rsync opération -- cela signifie que la machine cliente n'a même pas la capacité d'exécuter une commande rsync restreinte, ce qui signifie que l'attaquant n'a pas le pouvoir de supprimer des fichiers.
Tout cela suppose que votre serveur de sauvegarde est sécurisé. Si l'attaquant peut y accéder par un autre moyen, vous êtes désossé quoi que vous fassiez.
Solution 2 :
La chose la plus simple serait probablement d'aller dans l'autre sens avec les sauvegardes, c'est-à-dire. tirer du serveur de sauvegarde. C'est ainsi que j'exécute mes sauvegardes avec rdiff-backup.
Solution 3 :
C'est l'une des fonctionnalités que j'aime du service de sauvegarde Tarsnap. Cela me permet de créer des sous-clés avec des capacités de lecture, d'écriture et/ou de suppression.
Sur mes serveurs, je conserve généralement des sous-clés avec des capacités de lecture et d'écriture. Parfois, lorsque j'ai besoin/vouloir supprimer d'anciennes archives de sauvegarde, je le fais en utilisant les clés principales de mon ordinateur de bureau local.
Notez que Tarsnap est en soi un service de stockage. Vous ne pouvez pas utiliser le logiciel Tarsnap pour créer des sauvegardes sur vos propres serveurs de stockage.
Solution 4 :
Essayez d'utiliser une couche de système de fichiers en écriture seule qui masquera votre destination réelle.
J'ai trouvé un exemple ici, en utilisant FUSE.
Vous pouvez également utiliser un système de fichiers crypté dans lequel n'importe qui peut écrire, mais qui nécessite que votre certificat de clé soit modifié (cela semble être l'option la plus sûre, bien qu'elle nécessite probablement plus de planification lors de la mise en œuvre). enCrypted FileSystem) et TrueCrypt
Ainsi, alors que la première solution "masquera" votre système de fichiers, qui est en fait stocké ailleurs dans la machine et peut être modifié pour les utilisateurs du système avec des autorisations, dans la seconde solution, il ne peut être modifié qu'avec les clés appropriées.
Solution 5 :
ftp :par exemple, vsftp a une option pour désactiver les suppressions afin que vous ne puissiez que télécharger. Ensuite, de l'autre côté, vous créez un script qui supprime les sauvegardes de plus de x jours. J'utilise cette option, sur le serveur principal, les sauvegardes sont de simples sauvegardes utilisant tar + gz, elles sont téléchargées sur un serveur nas via sftp, puis le serveur nas supprime sauvegardes de plus de 7 jours.
rsync :le serveur rsync a une option pour désactiver les suppressions afin que cela puisse également fonctionner pour vous, mais vous devez utiliser le protocole rsync/server.refuse options =delete
Mais vous devrez alors supprimer manuellement les fichiers "supprimer" de temps en temps.