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.

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}

Il a bien été question d’utiliser le mode fuzzy de rsync mais la solution idéale vient du support de veeam et c’est avec leur accord que nous publions le workaround :

Please note this is not officially supported by Veeam so use at your own risk and make sure to backup your registry.

Here is the registry change that needs to be done:

1. HKEY_LOCAL_MACHINE\SOFTWARE\VeeaM\Veeam Backup and Replication
2. Create DWORD = DisableVBKRename
3. Set Value = 1
4. Restart Veeam Backup Server

You will also need 5.0.1.198 or newer installed.

A few things to note:

There is an issue where having DisableVBKRename dword in place will only work for new jobs or jobs you do “Delete from disk”/”Remove from backups” to remove the historical data from our DB. If you do Delete from disk/Remove from backups in the backups pane on the left and then do “Perform Full” on the job, it will append the timestamp again. If you do Delete from disk/Remove from backups  and then just do Right Click -> Start job, it will name it correctly without the time stamp.

You can make it use the new naming style by going into Backups and doing “Remove from backups” to remove historical data and then on the next scheduled job run or doing Right Click -> Start Job, it will start using the new naming convention. The issue is that if you ever do “Perform Full Backup” at any time, it will use the 5.x style naming and append a timestamp, rather than following the old 4.x style, even with the registry key in.

NOTE: As of 5.0.2.224 (and newer), this fix will not break should you attempt a new full backup — in fact, all you need to do is perform a full after rebooting the Veeam server, and the naming scheme will take effect.

Nous avons pu constater qu’un simple redémarrage du service veeam backup suffisait à rendre la modification effective.

Currently, VMware does not support quiesced snapshot of virtual machines running the vCenter Server database.

[...]

If quiesced snapshots are created by backup software to back up the virtual machine data, either use:

• A backup solution that provides application-level quiescing.
• Backup Agents in the guest operating system.

Il est donc recommandé d’utiliser un produit comme veeam backup pour faire un backup de votre VCDB avant de tout exploser

De toute façon, les snapshots c’est mal : Performance impact when using VMware snapshots

La version 5.0.2.224 de Veeam Backup & Replication est sortie le 1er avril mais ce n’est pas pour cela qu’elle contient un bug lié à la nouvelle feature “Deleted VMs retention period” qui a pour effet de supprimer tous vos restore points vieux de plus de 14j :

New “Deleted VMs retention period” feature is behaving incorrectly, causing backup files older than specified amount of days to be deleted even if they contain VMs which had not been deleted from infrastructure.

Le workaround ainsi que les détails sont dispo sur le forum de Veeam.

Voici l’extrait de cette feature qui reste néanmoins très intéressante (quand le problème sera réglé) :

Automated retention for removed and deleted VMs. Data belonging to removed or deleted VMs will now be automatically cleaned up from backup files according to new UI retention setting in days. Previously, it was necessary to remove such VMs from backup manually to explicitly confirm that VM data is no longer needed.

]]> http://www.hypervisor.fr/?feed=rss2&p=2842 0 http://www.hypervisor.fr/?p=2755 http://www.hypervisor.fr/?p=2755#comments Thu, 24 Mar 2011 20:03:03 +0000 NiTRo http://www.hypervisor.fr/?p=2755 Cette histoire date de début 2010 mais puisque nous avons du chercher un peu trop longtemps pour la retrouver, avec ce post cela n’arrivera plus.

Tout commence avec la technique de sauvegarde de Veaam Backup : le Synthetic Backup aka “reversed incremental“. Imaginez le principe de la sauvegarde incrémentale à l’envers, c’est à dire que le backup full est toujours le plus “up to date” et que les incrémentales vous permettent de remonter dans le temps. C’est donc beaucoup plus simple en cas de restauration du dernier backup (majorité des cas) et surtout en cas de backup sur bande car l’élément à backuper est toujours le même : la full (.vbk).

Veeam Backup “injects” the changes into the full recovery file (.VBK) and then also saves any data replaced during this process into the reversed incremental changes file (.VRB)

The .VBK file also has the most current modified date as it gets updated after each backup cycle.

Par contre, même si l’on force la politique de rétention à “1″, si un backup est déjà présent lors de l’exécution du job, un fichier .vrb (reversed incremental) est créé, alimenté durant toute la durée du backup et supprimé une fois le job terminé. L’inconvénient dans l’histoire c’est que si vous vous servez du même volume pour accueillir tous vos backup et que plusieurs job sont exécutés simultanément, il faudra prévoir l’espace “perdu” pour les fichiers .vrb temporaires.

Si l’on ne dispose pas de cet espace, on est évidement tenté de supprimer le fichier .vbk et laisser le job refaire une full. Dans la version 3 de Veeam Backup, il était tout à fait possible de procéder ainsi mais ce comportement à été modifié dans la version 4 : le job refuse de se lancer sans le .vbk précédent (à moins que l’on supprime manuellement le backup via la console) :

C’est dans le “release notes” de la version 4.1.1 que l’on trouve une partie de la parade:

Support for rotated media. Veeam Backup can now be instructed to automatically re-create full backup file if it is missing from the backup storage to better support scenarios with rotated media as backup target. This behavior can be enabled with a registry mod.

Et le “registry mod” le voici (pour la v4) :

[HKEY_LOCAL_MACHINE\SOFTWARE\VeeaM\Veeam Backup and FastSCP]
"ForceCreateMissingVBK"=dword:00000001

Ou si vous êtes en v5 :

[HKEY_LOCAL_MACHINE\SOFTWARE\VeeaM\Veeam Backup and Replication]
"ForceCreateMissingVBK"=dword:00000001

Nous espérons que ce lien vous permettra de découvrir/redécouvrir les produits/offres/avantages de veeam.

N’hésitez pas à nous faire part de vos réactions et commentaires liés à ce changement.

Runtime processes for guest processing (also known as the Veeam VSS agent) no longer require a direct network connection between the backup server and the processed VM. This allows you to process VMs that are behind firewalls or located in a DMZ or other network that the backup server cannot access.

Sortie il y a à peine quelques jours, la liste des nouveautés de Veeam Backup & Replication v5 est hallucinante. Instant VM Recovery mise à part, voici nos préférées :

• Universal Application-Item Recovery *
• SureBackup Recovery Verification **
• Guest File System Indexing ***
• VM-level retention
• ZFS support
• VM search (Restore)
• Datastore-based jobs
• Continuous job schedule

* Connecteurs applicatifs pour une restauration d’objet type AD, Exchange ou SQL
** Test/validation de restauration dans un environnement cloisonné
*** Catalogue d’index des fichiers contenu dans les backup

Ce qui frappe le plus dans cette liste c’est le nombre de “petites bonnes idées” qui fait de Veeam Backup un produit encore plus différent des solutions de backup traditionnelles. Consultez le User Guide de la v5 si vous avez encore des doutes

Revenons sur Instant VM Recovery qui nous a clairement marqué par son ingéniosité : vous avez la possibilité de démarrer la VM directement depuis l’archive de backup ! Vous pouvez ainsi valider instantanément si la VM (ou le restore point) que vous voulez restaurer est le bon.  Le tout grâce à un service NFS qui présente à l’ESX un datastore contenant la VM :

Et si le stockage qui héberge le fichier est trop lent, vous pouvez rediriger (grâce à un simple snapshot) les I/O sur un datastore plus rapide. Surpuissant !

Voici une video issue de notre test :

Veeam Backup & Replication 5.0 – Instant VM Recovery (avi)

Veeam réussi clairement à garder sa philosophie “proche des utilisateurs” pour le développement des ses produits. Ce qui explique, en autre, le succès de cette petite boite qui a pondu, fin 2006, l’un des outils les plus populaire pour VI3 : FastSCP.

C’est là que les cmdlet VBK entrent en jeu (présentes depuis la version 4.0), et plus particulièrement Set-VBRRestoreVM (la liste de toutes les cmdlet est dans le userguide) mais pour lister les VM disponibles dans un backup importé, il faut ruser car le “job” n’existe pas (Get-VBRJob ne renvoi que les jobs de backup) :

Get-VBRJobRestorePoints job_imported *|select ObjectName

Il faut ensuite choisir une “destination” au sens Veeam (host, datasore, ressourcepool, path) :

Get-VBRJobDestination esx.vmware.local datastore

Et lancer la commande qui restaure les VM :

Get-VBRJobRestorePoints job_imported *|%{Set-VBRRestoreVM $_ (Get-VBRJobDestination esx.vmware.local datastore) thin}

Exemple en images :

Vous pouvez évidement jouer sur le filtre de nom des RestorePoints (dans notre cas, 1 full par VM) :

Si l’on en croit le message d’un des PM de Veeam sur le forum officiel, la version actuelle supporterai déjà le (très imminent) vCenter 4.1 mais pas ESX 4.1 en connexion standalone. Veeam prévois une version supportée 1 semaine après l’arrivée de vSphere 4.1

Merci à William Lam pour son tweet.

C’est une kb Microsoft qui nous a mis sur la voie :

A heavily fragmented file in an NTFS volume may not grow beyond a certain size

The limit can also be reached by a sparse file. This size limit is usually between 40 gigabytes (GB) and 90 GB for a very fragmented file.

Après un bon defrag, plus de problèmes :