Administrator@vsphere usage short hint

I’ve some customers who are using the local Administrator@vsphere for different things like Backup-User, or Reporting things. From my point of view I can’t recommended this and say please create Service-Users for all different topics. Like one user for Backup – in my example something like: _svc_veeam_bck or for Horizon _svc_vdi. Give the local Administrator a good and secure Password, write it down, put it in Keepass or something else and use it only when it’s really needed! This is your last resort to login to your vCenter.

What do you think about using the Administrator@vsphere User?

Raum ist in der kleinsten Hütte…

Das zumindest denkt sich Veeam Backup & Replication, wenn es eng wird im Repository – zumindest zu eng für ein weiteres Vollbackup.

Bei der klassischen “Forward Incremental” Methode, bestehend aus einer (z.B. wöchentlichen) Vollsicherung und mehreren (täglichen) inkrementellen Sicherungen kann man in einem zu klein dimensionierten Backup Repository schon mal schnell an die Grenzen stossen.

Ich sehe es leider viel zu oft bei meinen Kunden, dass der Speicherplatz viel zu knapp bemessen wurde, so dass stellenweise weniger als drei Vollsicherungen gleichzeitig Platz finden. Daran, dass Veeam ja auch noch etwas rangieren muss, gerade wenn Synthetic Fulls erstellt werden, denken leider die wenigsten Entscheider.

Die Inkrements sind dabei natürlich alle abhängig von sämtlichen vorherigen Backups im aktuellen Zyklus, so dass der Verlust einer Sicherungsdatei alle darauf folgenden vollkommen unbrauchbar macht.

Aber zurück zum Titel dieses Posts: Steht am Wochenende mal wieder eine Vollsicherung an, obwohl nicht ausreichend Speicherplatz im Repository vorhanden ist, wird Veeam stattdessen eine weitere inkrementelle Sicherung starten, getreu dem Motto “Besser als gar keine Sicherung!” und “Einer geht noch!”.

So weit, so gut, aber dadurch wird das Problem weiter nach hinten geschoben und früher oder später ist das letzte Kilobyte geschrieben und der Backup Job läuft vor den berühmten Hammer.

Genau das ist mir heute zum wiederholten Male begegnet. Der Backup Job war für 30 Restore Points konfiguriert, vorhanden waren 160 – alle in ein- und demselben Backupzyklus, alle abhängig von ihren Vorgängern. Eine unangenehme Situation, wenn man dem Kunden erklären muss, dass er sich von seiner kompletten Datensicherung trennen muss, um eine aktuelle zu erstellen. Glücklich, wer dann die 3-2-1 Regel befolgt hat und über weitere Kopien verfügt.

Wo aber ist der Unterschied zur “Forever Forward Incremental” Methode, in der ja auch niemals eine aktuelle Vollsicherung erstellt und der ursprüngliche Zyklus bis in alle Ewigkeit weitergeführt wird?

Die Antwort liegt in der Konfiguration der Restore Point Anzahl versteckt. Während bei der klassischen Methode ganz optimistisch davon ausgegangen wird, dass schon irgendwann wieder Platz für ein weiteres Full sein wird, und ältere Sicherungsdateien aufgrund ihrer Retention automatisch gelöscht werden können, ist bei “Forever” ja von vorneherein klar, dass die Kette unendlich weitergeht.
Um also das Repository nicht platzen zu lassen und gleichzeit die geforderte Anzahl an Restore Points vorzuhalten, wendet Veeam nach der eigentlichen Sicherung die Methode der “Transformation” an. Dabei werden die Datenblöcke des ältesten inkrementellen Restore Points in das am Anfang der Kette stehenden “Full” injiziert und die danach nicht mehr benötigte inkrementelle Sicherung aus dem Repository gelöscht.
Dadurch hat man immer exakt die eingestellte Anzahl an Wiederherstellungspunkten, bei 30 Stück also eine Vollsicherung und 29 Inkremente.

Die gute Nachricht ist: Ich kann jederzeit aus meinem Forward Incremental Backup ein Forever Forward Incremental machen, indem ich in der Job Konfiguration (unter Storage -> Advanced) einfach die Haken für Synthetic Full und Active Full entferne und den Job ein weiteres Mal laufen lasse (siehe Screenshot).

Gesetzt den Fall, dass mein Repository noch ein bisschen Platz zum Rangieren hat, erzeugt das erst eine weitere inkrementelle Sicherungsdatei und transformiert anschliessend die ältesten Restore Points in eine “neue” Vollsicherung.

In den letzten 9 Stunden sind mittels dieser Vorgehensweise aus den oben genannten 160 Restore Points mittlerweilen 116 geworden – die 30 sind dann wohl irgendwann am Wochenende auch erreicht…

Syslog HASHMAP

I’ve a customer who have several DataCenters in the vCenter and each DataCenter needs different Syslog-Server. With this script you should be able to set for each Datacenter different Syslog-Server.

#Map DC to log server:
 
$servermap = @{
 
    "DC1" = "tcp://syslog01.v-crew.int:514,tcp://syslog02.v-crew.int:514";
    "DC2" = "tcp://syslog03.v-crew.int:514,tcp://syslog04.v-crew.int:514";
    "DC3" = "tcp://syslog05.v-crew.int:514,tcp://syslog06.v-crew.int:514";
 
};
 
  
 
foreach ($vmhost in (Get-VMHost)) {
 
    $DC = (Get-Datacenter -VMHost $vmhost)
 
    echo $vmhost.Name 
 
    echo $servermap.($DC.Name)
 

    $syslog = $servermap.($DC.Name)
 
    Get-AdvancedSetting -Entity $vmhost -Name "SysLog.Global.loghost" | Set-AdvancedSetting -Value $syslog -Confirm:$false
 
    Write-Host "Restarting syslog daemon." -ForegroundColor Green
 
    $esxcli = Get-EsxCli -VMHost $vmhost -V2
 
    $esxcli.system.syslog.reload.Invoke()
 
    Write-Host "Setting firewall to allow Syslog out of $($vmhost)" -ForegroundColor Green
 
    Get-VMHostFirewallException -VMHost $vmhost | where {$_.name -eq 'syslog'} | Set-VMHostFirewallException -Enabled:$true
 
}

https://github.com/Vaiper/syslog-servermap/blob/master/syslog-servermap.ps1

We hope it helps some of you.

Veeam Repository Configuration

For my Lab, i was in the lucky postion last year to got some awesome old Hardware HPE ProLiant DL380p Gen 8 etc. and with that I was able to build a awesome small Lab.


On this Server I’ve Windows Server 2016 running and as you can see under X: I’ve configured the Veeam-Repo. Here is as well Deduplication configured (I like dedup! ;))

How do you configure your Veeam-Repo? Do you know the awesome https://www.veeambp.com/ site? There are so many great tips and tricks. I’ve as well an external Server for my offsite Backups here, I’ve an Windows Server 2019 with REFS and 64 KB allocation unit size as well configured with Dedup.

How do you configure your Veeam-Repos?

another IT blog

Moin zusammen!

Ja, genau ein neuer IT Blog… mal wieder. Oliver @opalz und meiner einer @stimmermann probieren unser Glück mal, in Denglisch :D.

Themen werden im Groben: #Architektur #Design #Sizing #Performance #Administration #Projektleitung #Projektplanung #Beschaffung #DataCore #VMware #VDI #Linux #Windows #Veeam #DataCenter #Hardware #SDDC #DR #Network #Office365 #DSGVO #GoBD #CloudGate365 #Lizenzen #Backup

NXLOG Config for Windows 10

I use Graylog in my Environment for centralized logging infrastructure.

and while I playing at this time a lot of with VMware Horizon 7.9 I also created a new Windows 10 Master image with UEM etc. and I want to send all windows 10 instant clone logs to my existing Graylog infra.

So for windows logging there is at this time only NXLog for doing this job really great.

In case you need a working configuration here is mine:

Panic Soft
#NoFreeOnExit TRUE
define ROOT     C:\Program Files (x86)\nxlog
define CERTDIR  %ROOT%\cert
define CONFDIR  %ROOT%\conf
define LOGDIR   %ROOT%\data
define LOGFILE  %LOGDIR%\nxlog.log
LogFile %LOGFILE%
Moduledir %ROOT%\modules
CacheDir  %ROOT%\data
Pidfile   %ROOT%\data\nxlog.pid
SpoolDir  %ROOT%\data
######################################################
############## Extensions ############################
<Extension gelf>
    Module      xm_gelf
</Extension>
########## INPUTS ###########
<Input eventlogs>
    Module      im_msvistalog
# For windows 2003 and earlier use the following:
#   Module      im_mseventlog
</Input>
########################################
################# OUTPUTS ##############
<Output out>
    Module      om_tcp
    Host        log.XXXXX.int
    Port        12201
    #Exec       to_syslog_snare();
    OutputType  GELF_TCP
</Output>
#######################################
#################### ROUTE  ###########
<Route eventlogs>
    Path        eventlogs => out
</Route>

The input in Graylog looks so:

and here you see an example extracted message in Graylog

I hope it helps someone!

Oracle VM und Monitoring über SNMP

Seit OracleVM 3.2 liefert Oracle die Option, den Server mittels SNMP zu überwachen.
Die Basiskonfiguration hat noch nicht sonderlich viel Informationen geliefert, so dass der Einsatz etwas eingeschränkt ist.
Wim Coakerts hat in seinem nun beschrieben, wie die MiBs erweitert werden können und dazu noch ein passendes RPM geliefert.
Ist zwar offiziell vom Support nicht unterstützt, wird dafür über MyOracleSupport bereit gestellt und bietet eine interessante Erweiterung des SNMP-Überwachung.
Folgende MiBs werden ergänzt:
ovsType : Oracle VM Server
ovsVersion : Version of Oracle VM Server installed
ovsMaster : Master node in serverpool?
ovsClusterState : Cluster configured / online?
ovsClusterType : NFS or Lun based
ovsClusterStorage : the nfs mount or lun used for the server pool filesystem
ovsManagerUUID : UUID of the Oracle VM Manager instance
ovsServerpoolName : serverpool name this server is a member of (or None)
ovsServerpoolIP : Virtual IP address of the serverpool master
ovsAgentState : Agent running or stopped
ovsFreeMemory : free memory available for Virtual Machines on this server
ovsHostname : hostname as known by the Oracle VM Manager instance

vmTable : table with an index listing all the currently running VMs
columns -> vmIndex, vmType