IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Administration SQL Server Discussion :

Stratégie de répartition datas logs et backup


Sujet :

Administration SQL Server

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre confirmé
    Homme Profil pro
    web entrepreneur
    Inscrit en
    Novembre 2012
    Messages
    117
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Ile Maurice

    Informations professionnelles :
    Activité : web entrepreneur
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Novembre 2012
    Messages : 117
    Par défaut Stratégie de répartition datas logs et backup
    Bonjour,

    J'ai un serveur "Z" comprenant un disque SSD C:\ en RAID 1 de 500GB et un disque SATA D:\ RAID 5.
    Spécifications détaillées du serveur : https://www.fasthosts.co.uk/sites/fa...Data_Sheet.pdf

    Ce serveur Z est en LAN avec un serveur X.

    Je pense restaurer une ancienne base de manière à remettre le .ldf sur C:\ et le .mdf sur D:\

    En mode FULL RECOVERY, je vais effectuer un BACKUP complet à 4h00 tous les matins, et des BACKUP LOG toutes les 30 mn.

    Je compte faire ces backups par le LAN sur un répertoire partagé du serveur X.

    Le serveur X sert de site de test, et éventuellement donc de restauration si problème avec Z.

    Merci de me faire part de vos remarques si ce type de stratégie vous semble adaptée aux serveurs à disposition.

    A+

  2. #2
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 999
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 999
    Billets dans le blog
    6
    Par défaut
    Oui, il est bien adapté.

    Le JT à besoin de disques les plus rapide possible => RAID 1 et SSD c'est OK
    Les données peuvent accepter des RAID 5 en disque physique, sauf si très fort volume de mises à jour.

    Quand aux sauvegardes sur un partage il faut juste veiller que les droits du compte systèmes de SQL Server puisse écrire.

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  3. #3
    Membre confirmé
    Homme Profil pro
    web entrepreneur
    Inscrit en
    Novembre 2012
    Messages
    117
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Ile Maurice

    Informations professionnelles :
    Activité : web entrepreneur
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Novembre 2012
    Messages : 117
    Par défaut
    Merci pour la confirmation

  4. #4
    Membre confirmé
    Homme Profil pro
    web entrepreneur
    Inscrit en
    Novembre 2012
    Messages
    117
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Ile Maurice

    Informations professionnelles :
    Activité : web entrepreneur
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Novembre 2012
    Messages : 117
    Par défaut
    Au niveau des possibles coupures momentanées du réseau, comment cela est géré par SQL SERVER en cours de backup svp ?

    N'est-il finalement pas plus sécurisant, de faire un BACKUP sur le serveur de production puis transférer les sauvegardes (ex: robocopy) après vers le serveur distant ?

  5. #5
    Membre Expert
    Homme Profil pro
    DBA SQL Server
    Inscrit en
    Octobre 2012
    Messages
    862
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : DBA SQL Server
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Octobre 2012
    Messages : 862
    Par défaut
    Personnellement, je fais un backup de 30 instances en Prod sur un serveur distant, tous avec les mêmes schedules car j'utilise le "Multi Server Administration" pour l'agent SQL et ça fonctionne très bien.

    Et les très très rare fois où je rencontre un problème, je le relance le lendemain.

  6. #6
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 999
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 999
    Billets dans le blog
    6
    Par défaut
    Citation Envoyé par Trady Voir le message
    Au niveau des possibles coupures momentanées du réseau, comment cela est géré par SQL SERVER en cours de backup svp ?

    N'est-il finalement pas plus sécurisant, de faire un BACKUP sur le serveur de production puis transférer les sauvegardes (ex: robocopy) après vers le serveur distant ?
    Vous pouvez faire d'une pierre deux coups avec l'option MIRROR TO.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    BACKUP DATABASE MaBase
    TO DISK = 'Localpath\MaBase.bak'
       MIRROR TO DISK = 'Distantpath\MaBase.bak'
    ...

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  7. #7
    Membre Expert
    Homme Profil pro
    DBA SQL Server
    Inscrit en
    Octobre 2012
    Messages
    862
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : DBA SQL Server
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Octobre 2012
    Messages : 862
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    Vous pouvez faire d'une pierre deux coups avec l'option MIRROR TO.
    Je ne connaissais pas, comment cela fonctionne?

    Il fait un backup puis l'autre? les 2 en même temps? Une fois qu'il en a fini un, il copie l'autre vers le share?

Discussions similaires

  1. data logging exceeded available memory
    Par mostdel dans le forum Simulink
    Réponses: 1
    Dernier message: 07/07/2017, 09h06
  2. Log Files backup
    Par atagleike dans le forum Informix
    Réponses: 1
    Dernier message: 04/09/2011, 21h18
  3. [SQL2008R2] - réduire log du backup avant restore
    Par Mouse dans le forum MS SQL Server
    Réponses: 2
    Dernier message: 29/03/2011, 14h45
  4. Réponses: 2
    Dernier message: 30/08/2005, 14h11
  5. [] [Stratégie] Comment créer un fichier log
    Par Skeezo dans le forum Installation, Déploiement et Sécurité
    Réponses: 4
    Dernier message: 16/09/2002, 18h30

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo