Comment sauvegarder un serveur Linode en cours d'exécution?
Nous voulons faire une sauvegarde de tout sur notre serveur Debian, qui fonctionne à distance à l'autre bout du monde (hébergé par Linode), sans l'arrêter.
Ce système exécute Shell, le courrier électronique, XMPP/prosody et le Web, avec quelques configurations nginx simples.
Nous voulons sauvegarder des fichiers liés à ces choses juste pour être sûr. Par exemple, les fichiers que les utilisateurs ont stockés dans leurs répertoires personnels.
Nous n'avons pas besoin de copier exactement la configuration existante dans chaque fichier/etc; au lieu de cela, la raison pour laquelle nous faisons même la sauvegarde en premier lieu est pour que nous puissions tout déplacer vers une nouvelle configuration (une version plus récente de Debian toujours sur Linode).
Je vois que Linode propose un service de sauvegarde. Mais à long terme, nous avons également besoin de nos propres sauvegardes, ici, au cas où elles tomberaient en panne ou si quelque chose d'autre se produisait.
La raison pour laquelle cette question existe est que lorsque j'ai essayé de faire des sauvegardes dans le passé, j'ai continué à faire l'une de ces deux erreurs:
- Je suis allé "OK, je vais juste copier
/et tout ce qui se trouve en dessous ", puis s'est retrouvé coincé dans une boucle infinie étrange à cause du lecteur sur lequel je copiais était monté sous/media/backup et se copiait récursivement [obv ce problème spécifique non applicable ici puisque nous sommes va sauvegarder sur rsync ou similaire] ou il est coincé en essayant de copier des trucs "vivants" dans/proc ou/var ou autre, comme essayer de suivre les journaux en constante évolution, ou - Je suis allé "OK, je vais juste prendre le strict minimum de ce dont nous avons besoin ... hmm, les répertoires personnels de chacun et nos répertoires de serveur Web (tous sous
/var) et récupérons une copie de/etcet tous les anciens e-mails sous/var/vmail ", puis j'ai invariablement foiré les autorisations de fichiers ou les horodatages (je vais m'assurer de ne pas sauvegarder les fichiers Unix sur un lecteur FAT cette fois) ou j'ai oublié quelque chose (" oh, shoot, j'avais quelques scripts personnalisés dans/usr/local/bin que je n'ai jamais stockés ailleurs, j'ai oublié de les obtenir, je suppose qu'ils sont partis maintenant ").
Donc, obv copier tout le lecteur directement a conduit à des pièges et la copie sélective de répertoires a conduit à des pièges. Je veux savoir comment le faire correctement.
La question de panne du serveur Qu'est-ce qui est nécessaire pour un système de sauvegarde complet? couvre la philosophie et les bonnes pratiques, mais je recherche ces détails plus spécifiques sur:
- Quels répertoires dois-je copier et lesquels dois-je exclure (étant donné que c'est un système qui fonctionne actuellement et qui sert un wiki, un chat XMPP, un courrier électronique - avec de nouveaux messages qui arrivent pendant que le travail de copie est en cours d'exécution)
- Quels attributs de fichier tels que les horodatages et le propriétaire et le groupe dois-je présenter et comment dois-je procéder? ← Je pense que je peux répondre à cette moitié de la question moi-même avec quelque chose comme… euh…
rsync -HXazJe pense que c'est une bonne option pour nous? Le-zobv pas vraiment lié à la question qui est "qu'est-ce que je préserve"
Un grand nombre des conseils de sauvegarde que je vois, comme l'utilisation de dd, semblent présupposer que le lecteur n'est pas monté et n'est pas utilisé. Mais ne suis-je pas censé exclure les répertoires "vivants" comme/proc et certains des sous-répertoires sous/var (cependant, certaines choses sous/var je sais que nous devons définitivement faire garder) et/monter? À quoi d'autre dois-je penser dans cette situation? Ensuite, je suppose que je peux simplement le snarf avec rsync et en utilisant un tas de --exclude drapeaux.
Ou existe-t-il de meilleures idées, en particulier celles qui conviennent aux logiciels libres?
Donc, vous voulez sauvegarder tout votre lecteur sans toutes ces erreurs désagréables et filtrer également tous les dossiers/proc et autres dossiers temporaires?
Une option consiste à monter le dossier racine sur un autre dossier du système de fichiers, comme ceci:
$ cd /mnt
$ mkdir drive
$ mount --bind / drive
Cela vous donnera tous les fichiers présents sur votre disque qui ne sont pas considérés comme temporaires (comme les dossiers/proc ou/sys).
Maintenant que vous avez une vue claire de votre dossier racine, vous pouvez simplement le copier sur votre lecteur de sauvegarde en utilisant le standard cp ou rsync. Quelque chose dans le sens de:
cp -R /mnt/drive /mnt/backupdrive
Cela résout les deux problèmes mentionnés:
- Vous n'entrez pas dans la récursivité, car le disque de sauvegarde n'est pas monté dans le lecteur (point de vue)
- vous ne manquez aucun fichier important, car vous les prenez tous
Voir aussi: man mount (8)
Sous Linux, tout est un fichier. C'est possible via rsync, mais il y a des choses à savoir, qui sont (au mieux) difficiles à contourner.
Vous devez d'abord penser à la réplication, en particulier pour les bases de données. C'est également une bonne idée de configurer un proxy/équilibreur de charge devant votre serveur principal, afin que vous puissiez facilement basculer entre vos serveurs principal et miroir pendant la transition.
Au niveau matériel, la meilleure situation sera d'avoir un serveur de type miroir d'un autre côté, avec le même nombre de ports Ethernet, la même disposition de disque dur, etc. Tout ce qui diffère implique la nécessité de modifier la configuration du système.
c'est-à-dire que si vous avez deux ports eth, vous voulez vous assurer que la configuration réseau, le pare-feu et ainsi de suite correspondent au nom de l'interface sur les deux serveurs, et dans le cas où il diffère, vous devez soit changer la configuration après rsync, soit changer le nom du périphérique sur le second serveur (de destination).
Idem avec la disposition des partitions. Vous devez créer les mêmes partitions que sur votre serveur principal, mais si vous les créez à partir de zéro, vous vous retrouverez avec des UUID différents, vous devrez donc modifier fstab, grub, mdadm (si le soft-raid est impliqué), etc. .
Mais il y a aussi beaucoup de choses qui peuvent mal tourner, comme les bases de données, qui peuvent être incohérentes si elles n'ont pas été arrêtées auparavant (avant de faire rsync).
La meilleure stratégie sera de préparer d'abord le matériel et le système de fichiers (partitions) - pour correspondre à la configuration du serveur principal. Montez ensuite les partitions vides via un système intermédiaire (comme un live CD avec ssh-server installé temporairement). Vous créez vide/proc,/dev,/sys puis rsync le reste, comme ceci:
rsync -avz -H --delete /etc /bin (...and so on) destserver:/mnt/yourrootfs/
Ensuite, vous devez installer grub sur l'appareil et travailler sur la configuration, pour le rendre amorçable, changer la configuration du réseau, fstab et d'autres choses mentionnées précédemment.
Vous pouvez également essayer d'installer un nouveau système (avec la même version que celle que vous utilisez sur votre serveur principal), puis l'éteindre, le monter via un autre système temporaire (comme un live cd), puis remplacer autre chose que/proc,/sys,/dev et/boot avec rsync.
Mais ce n'est qu'une idée générale. Les choses peuvent se compliquer en fonction de ce que vous avez réellement sur ce serveur, de votre configuration, de votre réseau et de votre configuration matérielle. Et à la fin de la journée, cela pourrait être vraiment difficile ou impossible de le faire sans temps d'arrêt notable.
Ce que vous voulez réellement, c'est des restaurations. Quoi que vous fassiez, vous devez le restaurer régulièrement.
Linode a un service de sauvegarde. Les instantanés peuvent être pris selon un calendrier prédéfini limité ou avec une API.
Un avantage des sauvegardes basées sur des instantanés est qu'elles offrent un moment précis, car les données ne changent pas pendant la copie. Les instantanés peuvent également être facilement restaurés sur un hôte différent, un nouveau Linode dans ce cas.
Exécutez votre système sur ZFS. Ensuite, vous pouvez prendre un instantané atomique instantané en utilisant quelque chose qui ressemble à:
# zfs snap -r tank@name-of-backup
où tank est le nom de votre pool ZFS. Cet instantané est garanti comme un instantané instantané dans le temps du système de fichiers et de tous ses systèmes de fichiers enfants.
Une fois que vous avez créé l'instantané, vous pouvez le transférer vers un autre hôte à l'aide de zfs send et ssh.
J'utilise BackupPC pour mon petit serveur privé virtuel, cela fonctionne assez bien. BackupPC peut utiliser rsync sous le capot et prend en charge les sauvegardes complètes et incrémentielles. Jetez-y un œil et voyez si cela répondrait à vos besoins.
Je pense que cela dépend de quoi et où vous exécutez le serveur avec la commande linux interne, ce n'est pas possible, vous devez imiter/diriger des données complètes et des bibliothèques. Si vous exécutez sur vmware et bien configuré, il fournit une migration en direct. Sinon, vous devez utiliser des outils tiers. J'espère que cela vous aidera. Quelques références supplémentaires Comment puis-je faire une sauvegarde d'un serveur en direct?
Rsync est une bonne commande pour synchroniser les données entre les serveurs.
Il existe 2 solutions disponibles, où vous n'avez plus besoin de compter sur les bits manquants ainsi que sur un élément de votre liste en raison d'une liste de contrôle incomplète ou peut-être simplement parce que quelque chose de chaud est négligé.
Premièrement, si vous déplacez cela sur une plate-forme avec un peu plus de contrôle sur la plate-forme matérielle sous-jacente, vous pouvez prendre des instantanés de disque de tous les fichiers pendant que le serveur est en cours d'exécution. Par exemple, sur AWS, vous pouvez créer un instantané d'un disque EBS et même ne payer que pour les différences lorsque vous effectuez un autre instantané plus tard.
Deuxièmement, je recommande de scripter la configuration de votre serveur complet avec un système de gestion de configuration, tel qu'Ansible. Cette volonté
documenter tout ce que vous avez configuré dans le contrôle de code source
vous permet de tester recréer le serveur à partir de la sauvegarde ou du bare metal pour vous assurer que vos scripts sont à jour
vous permet de réexécuter le script sur un système d'exploitation plus récent, généralement avec des modifications assez mineures.