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+

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 +

Merci pour la confirmation ;)

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 ?

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.

Citation:

---

Envoyé par Trady

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:

---

1 2 3

BACKUP DATABASE MaBase TO DISK = 'Localpath\MaBase.bak' MIRROR TO DISK = 'Distantpath\MaBase.bak'

---

...

A +

Citation:

---

Envoyé par SQLpro

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?

Hello,

Citation:

---

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?

---

Il fait un backup sur 2 streams parallèles. La durée du backup dans ce cas est bien sûr directement dépendante du chemin de sauvegarde le plus long.

++

Salut,

Avec ce MIRROR, sur un des serveurs j'ai cette erreur:

Citation:

---

L'unité miroir "D:\BACKUP\Backup_sent\xxxx.bak" et l'unité miroir "\\xx.xx.xx.xx\db_backup\xxxx.bak" comportent des spécifications d'unités différentes.
Msg 3013, Level 16, State 1, Line 1
BACKUP DATABASE s'est terminé anormalement.

---

Le backup fonctionne sinon sans le MIRROR, vers le distant également.

Peut-être pas le même formatage des disques?

J'ai trouvé ceci sur ce problème https://support.microsoft.com/es-ar/...in-alwayson-ag

A lire la documentation on a :

[I]Enables SQL Server optimization when disks of different sector sizes are used for primary and secondary replica log files, in SQL Server Always On and Log Shipping environments.
This trace flag is only required to be enabled on SQL Server instances with transaction log file residing on disk with sector size of 512 bytes. It is not required to be enabled on disk with 4k sector sizes.

Etes vous dans une topolgie AlwaysOn ou de Log Shipping ?

La taille de secteur se trouve en exécutant à l'invite de commandes en administrateur : fsutil fsinfo ntfsinfo c:

@++ ;)

Salut,

AlwaysOn n'est pas utilisé.
Voici ce que donne fstutil :

Server A
Bytes Per Sector: 512
Bytes Per Physical Sector: 4096

Server B (backup mirroir)
Bytes Per Sector: 512
Bytes Per Physical Sector: 512

Sur un 3e serveur le backup mirroir fonctionne bien, voici pour ce 3e serveur :
Bytes Per Sector: 512
Bytes Per Physical Sector: 512

A+