repostor réduire votre CTP

Transcription

1 repostor réduire votre CTP En lisant ce document, vous obtiendrez nos réponses sur les éléments suivants: RSI (Retour sur Investissement) TCO (Coût Total de Possession) Gains d espace multiplié jusqu à 43 fois DMIA (Durée Maximale d Interruption Admissible) Restauration plus rapide OPR (La Perte de Données Maximale Admissible) Sauvegarde plus rapide Moins à sauvegarder Moins de perte de données Cette solution est certifiée par IBM

2 Retour sur Investissement (RSI) Avec notre solution, vous avez un gain jusqu à 43 fois de votre espace de stockage stockés (Go) TSM stockés (Go) TSM stockés (Go) avec déduplication Cette image illustre une sauvegarde complète sur disque (lignes rouges) et démontre l augmentation du stockage en gigaoctets d une base de données de 10 gigaoctets, avec une conservation de 30 jours Vous pouvez les effectuez chaque semaine, avec une possibilité d incrémentale entre, illustrée dans le graphique (lignes jaunes). Si vous activez la V6 de TSM, avec déduplication et compression, le volume sera considérablement réduit (lignes vertes). Nous n avons pas pris en compte le besoin d espace supplémentaire pour le dump de sauvegarde (l espace occupé par le système du fichier pour le dump) ; nous avons uniquement calculé la quantité d espace utilisée dans TSM.

3 Fenêtre de sauvegarde Sauvegarde asynchrone vs synchrone Il n y a aucune garantie que TSM protège les sauvegardes PostgreSQL avec une solution de sauvegarde sur disque (voir illustration ci-dessous) Sauvegarde asynchrone qui ne tient pas compte des différentes tâches programmées Sauvegarde PostgreSQL en cours Sauvegarde des fichiers TSM en cours Dans cet exemple, la sauvegarde PostgreSQL n est pas encore terminée alors que la sauvegarde des fichiers TSM est en cours. Quel est le statut de PostgreSQL? Scénario 1) Scénario 2) TSM aurait pu sauvegarder le fichier alors que la sauvegarde PostgreSQL était encore en cours: résultat une sauvegarde corrompue dans TSM. TSM aurait pu sauvegarder le fichier après la fin de la sauvegarde PostgreSQL: résultat une sauvegarde correcte dans TSM. Sauvegarde asynchrone en prenant soin des différentes tâches programmées Sauvegarde PostgreSQL en cours Sauvegarde des fichiers TSM en cours Dans cet exemple la sauvegarde PostgreSQL est correcte dans TSM, mais comme vous le voyez dans l'illustration, la fenêtre de sauvegarde est beaucoup plus importante. Avec notre solution la sauvegarde PostgreSQL sera envoyée directement à TSM, tel qu'illustré ci-dessous. Sauvegarde synchrone Sauvegarde PostgreSQL en cours vers TSM Dans cet exemple, la fenêtre de sauvegarde est beaucoup plus courte que tous les exemples ci-dessus. Nous garantissons que toutes les données seront sauvegardées dans TSM. Avec notre solution, la fenêtre de sauvegarde sera plus courte Le résultat sera une sauvegarde plus rapide depuis l'application jusqu'au moment où les données sont réellement stockées hors du serveur physique (TSM).

4 La Perte de Données Maximale Admissible (PDMA) Vous pouvez réaliser des sauvegardes plus souvent car le volume est moins élevé avec les sauvegardes incrémentales. La perte de données maximum sera d'une heure L exemple ci-dessus illustre ce qui se passe si vous réalisez une sauvegarde incrémentale à chaque heure impaire.

5 Durée Maximale d Interruption Admissible (DMIA) La durée maximum d'interruption pour l'application pendant un rétablissement sera plus courte en raison du fait que les données sont récupérées directement depuis TSM dans le serveur PostgreSQL. L'illustration ci-dessus indique un rétablissement complet de 4 bases de données en parallèle dans le serveur PostgreSQL. Les cases grises représentent la restauration et le rétablissement progressifs (journaux de transaction) sur le serveur PostgreSQL. Avec notre solution, l'interruption sera plus courte Restauration de fichier Restauration de PostgreSQL à partir de complet L'illustration ci-dessus indique comment restaurer une des bases de données PostgreSQL depuis TSM. Si la restauration avait été effectuée manuellement, l'interruption aurait été beaucoup plus longue car elle n'aurait peut-être pas pu être effectuée en parallèle et vous auriez dû effectuer la restauration et le rétablissement en plusieurs étapes. 1) Restauration des fichiers dump depuis TSM (cases rouges) 2) Restauration des fichiers de sauvegarde incrémentale depuis TSM (cases grises) 3) Restauration de la base de données PostgreSQL (case jaune) 4) Rétablissement des bases de données PostgreSQL à partir du fichier de sauvegarde incrémentale (cases vertes)

6 Obtenez votre copie de validation maintenant Allez à Sélectionnez «Produits» dans le menu Choisissez le produit Allez à «Téléchargements de produits» Vous pouvez tester pendant 30 jours. Commander votre propre Data Protector: Envoyez un à pour de plus amples informations. Bienvenue à Repostor REPOSTOR AB Första Långgatan 19 SE Göteborg Suède Cette solution a été certifiée par IBM