Webcontrat - Sauvegardes : Différence entre versions
(→1 VDP) |
(→4 Replicat Baie Equalogic (Disaster Recovery)) |
||
| (25 révisions intermédiaires par 2 utilisateurs non affichées) | |||
| Ligne 1 : | Ligne 1 : | ||
= Recapitulatif = | = Recapitulatif = | ||
| + | |||
| + | |||
| + | == veeam == | ||
| + | |||
| + | <pre style="background:LightYellow;font-family:Helvetica,arial;font-size:12px;"> | ||
| + | 22 sept 2017 | ||
| + | Salut à tous, | ||
| + | Pour continuer les nouveautés, voici les infos sur la nouvelle solution de sauvegarde Veeam Backup and Replication | ||
| + | Vous pouvez vous connecter au serveur avec vos ID campus directement en RDP ou installer la console sur votre PC (iso dispo dans : S:\SSI\logiciels\win32\VEEAM, n’installer que les consoles ) sur ces adresses : | ||
| + | Campus : 10.1.7.211 | ||
| + | DR13 : 10.13.102.112 193.49.133.5 | ||
| + | |||
| + | Pour lancer le client, il faut utiliser « Veeam Backup & Replication Console » sur le bureau | ||
| + | Ensuite, naviguer dans les vues, la plus importante actuellement est la vue « BACKUP & REPLICATION » -> Backup | ||
| + | Cela donne accès à toutes les sauvegardes. | ||
| + | |||
| + | Pour restaurer , faire un clic droit sur la VM puis : | ||
| + | · Instant recovery : Ultra rapide, le système présente le disque de sauvegarde de Veeam au vcenter ; la VM est démarrée directement depuis ce disque. | ||
| + | Ce job est prioritaire sur tous les autres. Une fois la VM restaurée, il faut valider (voir jobs) -> cela migrera la VM en live sur les datastores de prod. | ||
| + | · Restore entire VM : Les datas sont d’abord copiées de la sauvegarde vers un datastore puis seulement démarré. Le job a besoin d’un slot sur l’infra de backup, | ||
| + | ce n’est pas aussi prioritaire que instant recovery et c’est plus lent avant d’avoir une VM opérationnelle. | ||
| + | · Restore virtual disk : on va pouvoir choisir un disque particulier (par exemple système uniquement). | ||
| + | · Restore VM Files : uniquement les fichiers de configuration de la VM | ||
| + | · Restore Guest files : Permet de restaurer directement des fichier dans la VM, ou des objets AD pour les serveurs AD. Actuellement uniquement dispo sur les serveurs Windows, | ||
| + | je bosse pour mettre en route sur linux. | ||
| + | |||
| + | Le reste n’est pas encore configuré (Replication, surebackup, etc …) | ||
| + | |||
| + | Julien | ||
| + | |||
| + | ----------------------------------- | ||
| + | Instant recovery : | ||
| + | |||
| + | Aprés la restauration dynamique de la VM, il faut finaliser le processus de restauration : "instant recovery waiting for user to start migration". | ||
| + | To migrate the recovered VM to production: | ||
| + | Open the Home view. | ||
| + | In the inventory pane, select the Instant Recovery node. | ||
| + | In the working area, right-click the VM and select Migrate to production. | ||
| + | If you have disabled the Delete source VM files upon successful migration option in the Quick Migration settings, you must unpublish the VM manually. After you unpublish the VM, the Instant Recovery session will end and the recovered VM will be unmounted from the vPower NFS server. The migrated VM will remain on the production environment. | ||
| + | Open the Home view. | ||
| + | In the inventory pane, select the Instant Recovery node. | ||
| + | In the working area, right-click the VM and select Stop publishing. | ||
| + | Olivier | ||
| + | |||
| + | </pre> | ||
{| class="wikitable sortable" border="1" cellpadding="4" style="background:LightCyan;font-family:Helvetica,arial;font-size:11px;width:60%;" | {| class="wikitable sortable" border="1" cellpadding="4" style="background:LightCyan;font-family:Helvetica,arial;font-size:11px;width:60%;" | ||
| Ligne 8 : | Ligne 53 : | ||
| '''MACHINES''' | | '''MACHINES''' | ||
|- | |- | ||
| − | | | + | | VEEAM || LOCAL sur serveur dédié || Restauration VM complète || <2h || Tous les soirs 20h || 14 jours / 6 semaines / 3 mois / 2 ans |
|- | |- | ||
| − | | | + | | Sauvegardes Symplivity || LOCAL || Restauration VM complète || <12h || Tous les soirs à 20h00 toutes les 2h pour les serveurs de DB || 30 jours |
|- | |- | ||
| − | | | + | | Veeam Replication || DISTANT (ADV) || Plan de Reprise d'Activité si RDM HS (Attention, service minimum, toutes les vm ne sont pas copiées) || >24h || tous les soirs || 1 jour |
| − | |||
| − | | | ||
|- | |- | ||
| + | |||
| '''APPLICATIFS''' | | '''APPLICATIFS''' | ||
|- | |- | ||
| − | | Time Navigator || DISTANT sur serveur dédié (Bat A) || Restauration fichiers du filer ou bases de données. Les fichiers sont envoyé sur le filer soit par montage, soit par scripts de sauvegardes || <30min suivant volumétrie || Tous les soirs 20h ou toutes les 4 heures pour les DB || | + | | Time Navigator || DISTANT sur serveur dédié (Bat A) || Restauration fichiers du filer ou bases de données. Les fichiers sont envoyé sur le filer soit par montage, soit par scripts de sauvegardes || <30min suivant volumétrie || Tous les soirs 20h ou toutes les 4 heures pour les DB || Fichiers : 3 mois; DB : 4 mois |
|- | |- | ||
| Scripts || LOCAL sur Filer || Restauration fichiers || <30min suivant volumétrie || Tous les soirs 20h || 1 jour, la rétention est faite sur le filer + TiNa | | Scripts || LOCAL sur Filer || Restauration fichiers || <30min suivant volumétrie || Tous les soirs 20h || 1 jour, la rétention est faite sur le filer + TiNa | ||
| Ligne 26 : | Ligne 70 : | ||
= VM's = | = VM's = | ||
| + | Schéma des flux de sauvegarde | ||
| − | |||
| − | |||
| − | + | == 1 Sauvegarde integrée symplivity == | |
| − | + | Cf doc exploit dans le dossier SSI/webcontrat/symplivity | |
| − | + | == 2 Veeam Backup== | |
| − | |||
| − | |||
| − | + | Se connecter au serveur via RDP (193.49.133.5) | |
| − | |||
| + | Lancer la console Veeam backup and replication | ||
| − | |||
| + | Se connecter avec login/mot de passe windows DR13 | ||
| − | |||
| − | + | * Pour restaurer une machine : | |
| + | ** aller sur Backup / Disk | ||
| + | ** Choisir une VM | ||
| + | ** Clic droit puis "Instant VM Recovery" | ||
| − | + | Cela va monter directement le disque de sauvegarde sur un ESX et lancer la machine. C'est très rapide MAIS cela ne suffit pas ! | |
| + | Une fois la machine publiée, elle apparaît en haut du menu Home dans "Instant Recovery". Il faut cliquer dessus puis : | ||
| + | * bouton droit / Migrate to production | ||
| − | + | Cela va déclencher une action vmotion entre le disque de sauvegarde et le datastore de production. Cel peut etre long si la VM est grosse, il faut bouger toutes les données dans ce cas. | |
| − | + | Une fois terminé, le lob apparaît dans les logs des dernieres 24h | |
| − | + | == 3 Veeam Replication (PRA) == | |
| − | + | Les machines nécessaires a un redémarrage de l'activité sont dupliquées toutes les 24H sur le site ADV. Cela permet de redémarrer ces machines sur le site distant. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | Ex suivi de la réplication : tout est OK, nu des serveurs est en train de se répliquer, RAS | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | [[Fichier:Veeam_replicat.png]] | |
| − | |||
| − | + | Procédure : | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| + | Pour redémarrer une machine sur ADV : | ||
| − | + | Retour à la normale: | |
| − | |||
| − | |||
| − | |||
= Fichiers = | = Fichiers = | ||
| Ligne 125 : | Ligne 131 : | ||
= Databases = | = Databases = | ||
| − | ==TiNa== | + | ==TiNa GRIFFON2 == |
Les bases de données sont sauvegardées toutes les 2 heures sur TiNa2 : | Les bases de données sont sauvegardées toutes les 2 heures sur TiNa2 : | ||
| Ligne 133 : | Ligne 139 : | ||
http://193.49.133.15:25088 | http://193.49.133.15:25088 | ||
| + | |||
| + | Admin / K7 | ||
===Accès via ssh / X11 :=== | ===Accès via ssh / X11 :=== | ||
| Ligne 149 : | Ligne 157 : | ||
Choisir les bases de données a restaurer en se connectant avec root (mdp root mysql dans Keypassx) | Choisir les bases de données a restaurer en se connectant avec root (mdp root mysql dans Keypassx) | ||
| + | |||
| + | |||
| + | [[Fichier:TiNA.png]] | ||
==Mysqldump== | ==Mysqldump== | ||
| Ligne 154 : | Ligne 165 : | ||
Un dump mysql de toutes les base est fait tous les matin. | Un dump mysql de toutes les base est fait tous les matin. | ||
Elle sont dispo sur le filer dans le répertoire /export/SAVE/mariadb | Elle sont dispo sur le filer dans le répertoire /export/SAVE/mariadb | ||
| + | |||
| + | |||
| + | Effectué par automysqlbackup avec les temps de retention suivants : | ||
| + | |||
| + | # Which day do you want weekly backups? (1 to 7 where 1 is Monday) | ||
| + | # Set to 0 to disable weekly backups. | ||
| + | CONFIG_do_weekly="5" | ||
| + | |||
| + | # Set rotation of daily backups. VALUE*24hours | ||
| + | # If you want to keep only today's backups, you could choose 1, i.e. everything older than 24hours will be removed. | ||
| + | CONFIG_rotation_daily=30 | ||
| + | |||
| + | # Set rotation for weekly backups. VALUE*24hours | ||
| + | CONFIG_rotation_weekly=365 | ||
| + | |||
| + | # Set rotation for monthly backups. VALUE*24hours | ||
| + | CONFIG_rotation_monthly=1000 | ||
= LDAP = | = LDAP = | ||
Version actuelle datée du 6 octobre 2020 à 10:50
Sommaire
Recapitulatif[modifier]
veeam[modifier]
22 sept 2017
Salut à tous,
Pour continuer les nouveautés, voici les infos sur la nouvelle solution de sauvegarde Veeam Backup and Replication
Vous pouvez vous connecter au serveur avec vos ID campus directement en RDP ou installer la console sur votre PC (iso dispo dans : S:\SSI\logiciels\win32\VEEAM, n’installer que les consoles ) sur ces adresses :
Campus : 10.1.7.211
DR13 : 10.13.102.112 193.49.133.5
Pour lancer le client, il faut utiliser « Veeam Backup & Replication Console » sur le bureau
Ensuite, naviguer dans les vues, la plus importante actuellement est la vue « BACKUP & REPLICATION » -> Backup
Cela donne accès à toutes les sauvegardes.
Pour restaurer , faire un clic droit sur la VM puis :
· Instant recovery : Ultra rapide, le système présente le disque de sauvegarde de Veeam au vcenter ; la VM est démarrée directement depuis ce disque.
Ce job est prioritaire sur tous les autres. Une fois la VM restaurée, il faut valider (voir jobs) -> cela migrera la VM en live sur les datastores de prod.
· Restore entire VM : Les datas sont d’abord copiées de la sauvegarde vers un datastore puis seulement démarré. Le job a besoin d’un slot sur l’infra de backup,
ce n’est pas aussi prioritaire que instant recovery et c’est plus lent avant d’avoir une VM opérationnelle.
· Restore virtual disk : on va pouvoir choisir un disque particulier (par exemple système uniquement).
· Restore VM Files : uniquement les fichiers de configuration de la VM
· Restore Guest files : Permet de restaurer directement des fichier dans la VM, ou des objets AD pour les serveurs AD. Actuellement uniquement dispo sur les serveurs Windows,
je bosse pour mettre en route sur linux.
Le reste n’est pas encore configuré (Replication, surebackup, etc …)
Julien
-----------------------------------
Instant recovery :
Aprés la restauration dynamique de la VM, il faut finaliser le processus de restauration : "instant recovery waiting for user to start migration".
To migrate the recovered VM to production:
Open the Home view.
In the inventory pane, select the Instant Recovery node.
In the working area, right-click the VM and select Migrate to production.
If you have disabled the Delete source VM files upon successful migration option in the Quick Migration settings, you must unpublish the VM manually. After you unpublish the VM, the Instant Recovery session will end and the recovered VM will be unmounted from the vPower NFS server. The migrated VM will remain on the production environment.
Open the Home view.
In the inventory pane, select the Instant Recovery node.
In the working area, right-click the VM and select Stop publishing.
Olivier
| Nom | Emplacement | Utilisation | temps de rétablissement | Programmation | temps de rétention |
|---|---|---|---|---|---|
| MACHINES | |||||
| VEEAM | LOCAL sur serveur dédié | Restauration VM complète | <2h | Tous les soirs 20h | 14 jours / 6 semaines / 3 mois / 2 ans |
| Sauvegardes Symplivity | LOCAL | Restauration VM complète | <12h | Tous les soirs à 20h00 toutes les 2h pour les serveurs de DB | 30 jours |
| Veeam Replication | DISTANT (ADV) | Plan de Reprise d'Activité si RDM HS (Attention, service minimum, toutes les vm ne sont pas copiées) | >24h | tous les soirs | 1 jour |
| APPLICATIFS | |||||
| Time Navigator | DISTANT sur serveur dédié (Bat A) | Restauration fichiers du filer ou bases de données. Les fichiers sont envoyé sur le filer soit par montage, soit par scripts de sauvegardes | <30min suivant volumétrie | Tous les soirs 20h ou toutes les 4 heures pour les DB | Fichiers : 3 mois; DB : 4 mois |
| Scripts | LOCAL sur Filer | Restauration fichiers | <30min suivant volumétrie | Tous les soirs 20h | 1 jour, la rétention est faite sur le filer + TiNa |
VM's[modifier]
Schéma des flux de sauvegarde
1 Sauvegarde integrée symplivity[modifier]
Cf doc exploit dans le dossier SSI/webcontrat/symplivity
2 Veeam Backup[modifier]
Se connecter au serveur via RDP (193.49.133.5)
Lancer la console Veeam backup and replication
Se connecter avec login/mot de passe windows DR13
- Pour restaurer une machine :
- aller sur Backup / Disk
- Choisir une VM
- Clic droit puis "Instant VM Recovery"
Cela va monter directement le disque de sauvegarde sur un ESX et lancer la machine. C'est très rapide MAIS cela ne suffit pas !
Une fois la machine publiée, elle apparaît en haut du menu Home dans "Instant Recovery". Il faut cliquer dessus puis :
- bouton droit / Migrate to production
Cela va déclencher une action vmotion entre le disque de sauvegarde et le datastore de production. Cel peut etre long si la VM est grosse, il faut bouger toutes les données dans ce cas.
Une fois terminé, le lob apparaît dans les logs des dernieres 24h
3 Veeam Replication (PRA)[modifier]
Les machines nécessaires a un redémarrage de l'activité sont dupliquées toutes les 24H sur le site ADV. Cela permet de redémarrer ces machines sur le site distant.
Ex suivi de la réplication : tout est OK, nu des serveurs est en train de se répliquer, RAS
Procédure :
Pour redémarrer une machine sur ADV :
Retour à la normale:
Fichiers[modifier]
- Dispos sur TiNa (voir plus bas)
- L'ensemble des fichiers sauvegardés est dispo sur 10.30.0.200 dans /export
Databases[modifier]
TiNa GRIFFON2[modifier]
Les bases de données sont sauvegardées toutes les 2 heures sur TiNa2 :
Accès via page web :[modifier]
http://193.49.133.15:25088
Admin / K7
Accès via ssh / X11 :[modifier]
ssh -X root@193.49.133.15 (A préférer)
Initialiser l’environnement :
source /usr/Atempo/TimeNavigator/tina/.tina.sh
Lancer la console :
tina_adm&
Se connecter :
admin/k7...
Choisir les bases de données a restaurer en se connectant avec root (mdp root mysql dans Keypassx)
Mysqldump[modifier]
Un dump mysql de toutes les base est fait tous les matin. Elle sont dispo sur le filer dans le répertoire /export/SAVE/mariadb
Effectué par automysqlbackup avec les temps de retention suivants :
# Which day do you want weekly backups? (1 to 7 where 1 is Monday) # Set to 0 to disable weekly backups. CONFIG_do_weekly="5" # Set rotation of daily backups. VALUE*24hours # If you want to keep only today's backups, you could choose 1, i.e. everything older than 24hours will be removed. CONFIG_rotation_daily=30 # Set rotation for weekly backups. VALUE*24hours CONFIG_rotation_weekly=365 # Set rotation for monthly backups. VALUE*24hours CONFIG_rotation_monthly=1000
LDAP[modifier]
Un script tourne sur chaque serveur ldap et sauvegarde soit dans /home/sauvegarde soit dans /home/save.
att_loc.ldif -> attributs locaux a utiliser pour une restauration ldap_save -> fichier entier, inutilisable sous sa forme pour resto sur nos annuaire (mais permet de remonter un annuaire complet pour tests ou verifs)
Procédure de restauration :
Redemarrer sur une base vide :
/etc/init.d/slapd stop mv /var/lib/ldap-people /var/lib/ldap-people.save mkdir /var/lib/ldap-people chown -R openldap:openldap /var/lib/ldap-people /etc/init.d/slapd start
Reinjecter les attributs locaux :
ldapadd -W -D "cn=admin,ou=People,dc=cnrs,dc=fr" -h localhost -x -f /tmp/att_loc.ldif -c
Verifier en faisant une recherche locale :
ldapsearch -x -b "ou=People,dc=cnrs,dc=fr" "(ACMO=*)" -h localhost
