On va en profiter pour remercier VMware, Veeam et toute la communauté pour les nominations de vExpert, vExpert vSAN et Veeam Vanguard de cette année, c’est toujours un honneur. 10 étoiles ca commence à faire

Nous avons même eu droit à une “honorable mention” dans un des vSpeaking Podcast de VMware pour SexiGraf. La classe

Et puisque c’est les 30 ans du World Wide Web ET de/du la/le Game Boy, nous nous sommes permis :

Get-VM nobackup|Get-View|?{-not $_.Config.Template -and $_.Runtime.ConnectionState -eq "connected"}|%{$_.ReconfigVM((New-Object VMware.Vim.VirtualMachineConfigSpec -Property @{extraconfig=@((New-Object VMware.Vim.optionvalue -Property @{Key="snapshot.maxSnapshots"; Value="0"}))}))}

Ça pique mais ça marche :

A general system error occurred: Exceeded the maximum number of permitted snapshots

Any vendor claiming support for #vStorage 5.1 API, CANNOT perform consistent backups

Réponse bien précise de veeam :

Our development team wasn’t able to fix these issues but they did realize that separating the VDDK calls into a separate process monitored by a watchdog process will help to dramatically increase overall reliability. In case this process hangs, we simply kill the process without affecting the job. With an alternative architecture not featuring such isolation, VDDK code hang will cause they whole backup and restore “job” to hang just as the VMware KB article explains.

Additionally, Veeam sets extra timeouts on some critical VDDK calls to avoid possible deadlocks.

Conclusion :

In short, Veeam customers are immune to VDDK issues while Symantec customers need to go back and verify the recoverability all of their VMware VM backups, as per Symantec’s own tweet.

Ça fait mal.

B&R 6.1 will not be officially supported with vSphere 5.1
[...]
we will NOT be performing any further testing of B&R 6.1 vs. vSphere 5.1, and instead will focus our efforts on B&R 6.5 release – which, in addition to all the new functionality, will include full vSphere 5.1 support.

C’est pas cool mais la bonne nouvelle c’est que B&R 6.5 intégrera gratuitement Veeam Explorer for Exchange, en beta depuis quelques semaines. Ce super outil permet de visualiser ou d’extraire des mails vers un fichier pst depuis un backup d’une base exchange.

Veeam Explorer for Exchange is a new feature of Veeam Backup & Replication. Currently available as a beta, Veeam Explorer will be included in all editions of Veeam Backup—even Free Edition. You no longer need expensive standalone tools for Exchange item recovery that are licensed per mailbox.

MAJ 28.08.2012 : Veeam nous confirme que ce bug à été corrigé dans le patch 1a 6.1.0.204, au cas ou vous auriez la version 6.1.0.203 (une “early” version du patch 1), assurez vous de re-télécharger la dernière version.

Nous avons pu observer par hasard la fuite mémoire d’une console veeam B&R 6.1 (6.1.0.181) laissée ouverte dans une session RDP pour un accès plus rapide :

Tom Sightler, Solutions Architect chez Veeam, nous confirme le leak et conseil de ne pas laisser le client ouvert tant que le bug n’est pas résolu.

[...] the 6.1 GUI has a pretty big leak. The larger the environment the faster it seems to grow. In some cases it only takes a few hours to get so big as to impact performance. I’ve even seen cases where the memory used by VeeamShell is large enough to cause problems with backup jobs. For now the only workaround is to keep the GUI closed when not in use.

Nous vous proposions il y a quelques temps un script qui stop les jobs en cours sur un serveur veeam backup, aujourd’hui nous allons plus loin dans la démarche avec 2 fichiers xml correspondant à 2 export de tache planifiée pour Windows 2008 R2 contenant les commandes. Le fichier StopActiveVBRJobs.xml va vous permettre de créer une tache planifiée qui arrêtera les jobs veeam en cours à 7h du matin, les jours de semaine, et le fichier RetryFailedVBRJobs.xml automatisera le retry des jobs arrêtés ”manuellement” à 21h, les mêmes jours.

Nous vous proposons également une tache planifiée qui automatise l’export des jobs veeam backup sur un partage CIFS (\\server\share\ à ajuster) et un autre qui permet d’exporter régulièrement (en xml) la liste des points de restauration possibles pour chaque vm de chaque job.

Voici maintenant un oneliner pour un usage très particulier, celui de trouver (replacez le get-item par remove-item pour supprimer) les fichiers veeam backup orphelins dans les répertoires cibles des jobs (cela peut arriver en cas de reboot violent du serveur veeam ou indisponibilité du repository pendant un backup).

v5 :

Compare-Object (Get-VBRJob|%{$_.Info.TargetDir|%{Get-ChildItem $_|%{$_.FullName}}}) (Get-VBRBackup|%{$_.GetStorages()|%{$_.FilePath}})|%{Get-Item $_.InputObject}

v6 :

Compare-Object (Get-VBRJob|%{$_.Info|%{Get-ChildItem "$($_.TargetDir)\$($_.Path)"|%{$_.FullName|?{$_ -match ".vrb|.vbk|.vib"}}}}) (Get-VBRBackup|%{$_.GetStorages()|%{$_.FilePath}})|%{Get-Item $_.InputObject}

On continue avec un autre oneliner qui permet d’afficher la liste des vm dont la date du dernier backup veeam (si vous avez activé la fonction qui rempli l’un des custom fields, “veeam” dans notre exemple) est supérieure à 21 jours, que vous pouvez utiliser dans un script pour vous envoyez un mail périodiquement par exemple.

Get-View -Viewtype virtualmachine|select name,@{n="backup";e={[Regex]::Match(($_.value|?{$_.key -eq ((get-view (Get-View ServiceINstance).content.CustomFieldsManager).field|?{$_.name -match "veeam"}).key}).value, "([0-9]{1,2}/){2,2}201[0-9]{1,1}[ ]*([0-9]{1,2}:?){3,3}").Value}},@{n="pool";e={(get-view $_.ResourcePool).name}}|?{$_.backup}|?{([datetime]::ParseExact(($_.backup), "dd/MM/yyyy HH:mm:ss", (New-Object System.Globalization.CultureInfo("fr-FR")))) -le (get-date).AddDays(-21)}

Et pour finir, un oneliner qui nous a prit un peu de temps (à cause du comportement bizarre du -ExpandProperty de la cmdlet Select-Object) qui vous permet de lister les vm présentent dans plusieurs jobs de backup.

Get-VBRBackup|select jobname,@{n="vm";e={$_.GetObjectOibsAll()|%{@($_.name,"")}}}|select jobname -ExpandProperty vm|select @{n="vmname";e={$_}}, @{n="jobname";e={$_.jobname}}|?{$_.vmname}|Group-Object -Property vmname|?{$_.Count -gt 1}|select name, @{n="jobs";e={$_.group|%{$_.JobName}}}

If you plan to use Direct SAN access mode, are running a localized version of Microsoft Windows, or are upgrading from a previous version of Veeam Backup & Replication, consider installing the patch.

Vous n’avez sans doutes pas pu passer à coté du lancement de la version 6 de Veeam Backup & Replication tant la liste de nouvelles features est impressionnante. La capacité à faire un failback sur les jobs de réplication, le support d’Hyper-V (avec “CBT” via un driver “made in” Veeam) et le changement d’architecture (proxy/server/repository) étant les 3 changements majeurs.

Attention toute fois, la v6 souffre encore de quelques bugs (plusieurs patch successifs ont été mis à dispo par le support veeam) qui en ont même découragé certains, nous y avons d’ailleurs dédié un short link : vm.lc/v6

N’hésitez pas à utiliser notre script de linked clone pour tester vos upgrades.

Comme toujours, c’est dans les petits détails que l’on peut juger de la finition d’un produit :

Avec le nouveau report de la v6, adieu les taux de transferts cosmique qui plaisait tant aux commerciaux…

Et pour inaugurer notre nouveau slogant “There’s A One-liner For That”, en voici un qui aura sa place dans vos taches planifiés pour “retry” un job “failed” :

Get-VBRJob|?{$_.GetLastResult() -eq "Failed"}|%{Start-VBRJob $_ -RetryBackup -RunAsync}

Add-PSSnapin VeeamPSSnapIn ; Get-VBRJob|?{$_.GetLastResult() -eq 'Failed'}|?{($_|%{$_.FindLastSession()}|%{$_.info}).Description -match 'Job has been terminated'}|%{Start-VBRJob $_ -RetryBackup -RunAsync}

Add-PSSnapin VeeamPSSnapIn ; Get-VBRJob|?{$_.GetLastResult() -eq 'Failed'}|?{($_.FindLastSession()|%{$_.GetDetails()}) -match 'Job has been terminated'}|%{Start-VBRJob $_ -RetryBackup -RunAsync}

MAJ 07/11/2011 : Apparemment ce sera possible dans la v6.

L’une des petites options pratiques qui rapprocherai veeam backup de la perfection serai de pouvoir définir une heure limite d’exécution par job. Par exemple, vous ne voulez peut être pas qu’un job continue après 7h du matin. Pour ça il vous suffit de coller ce petit one-liner en tache planifiée sur votre serveur veeam et tous les jobs au statut ”Working” serons stoppés :

Add-PSSnapin VeeamPSSnapIn ; Get-VBRJob|?{$_.GetLastState() -eq "Working"}|%{Stop-VBRJob $_ -RunAsync}