DC Backup/Restore

Das Active Directory ist das Herz eines modernen Netzwerks, welches alle Anmeldekonten verwaltet und die Authentifizierung vornimmt. Natürlich haben sie mehrere Domain Controller um die Last zu verteilen und die Verfügbarkeit zu erhöhen. Aber alle DCs sind nun mal im gleichen Forest und ein Administrator kann alle auf einmal kaputt machen. Die Berichte von geschädigten Firmen kennen sie alle und der Spruch "Kein Backup, kein Mitleid" hilft ihnen nicht weiter.

Daher sollten Sie nicht nur ein Backup machen sondern auch die Funktionsfähigkeit und Prozess einer Wiederherstellung gelegentlich prüfen. Das ist kein Witz! Wenn Sie es noch nie versucht haben, dann sollten Sie es jetzt tun.

Auslöser

Auch diese Seite habe ich mir nicht ausgedacht, sondern ist das Ergebnis eines realen Einsatzes. Ein Kunde wollte man das Szenario "AD ist verloren" durchspielen. Das passiert schnell mal, z.B. weil ein Hacker das System übernommen, ein Administrator einen kapitalen Fehler gemacht hat oder Feuer im einzigen Serverraum die Systeme zerstört hat. Es beginnt also alles damit, aus einem Backup den ersten Domain Controller wieder zu restaurieren, um basierend darauf dann die überlebenden Systeme wieder einzubinden oder ebenfalls wieder herzustellen.

Der Kunde hat das "versucht" aber die Wiederherstellung des DCs wollte einfach nicht gelingen. In dem Umfeld wurden alle Server über ein "Enterprise Backup" wie z.B. Veeam, TSM u.a. gesichert aber zusätzlich auch immer noch ein "Windows Server Backup" parallel macht. Ein geplanter Task sicherte jeden DC auf eine zusätzliche Festplatte, um im Falle eines Falles schnell wieder Dateien oder Einstellungen zurückholen zu können. Wir haben nun angenommen, dass durch einen Cyberangriff das AD nicht mehr funktionsfähig ist und in der Folge natürlich auch ein Zugriff auf das Enterprise Backup, Netzwerk etc. nicht mehr möglich war. Vielleicht kommen Sie auch nicht mehr an ihre auf dem Server abgelegte Kennwort-Datenbank.

Hier liegt der Schwerpunkt aber auf dem Restore mit Windows Bordmitteln, die letztlich deswegen nicht funktioniert haben, weil das Backup-Skript nach dem Update der DCs von Windows 2008 auf Windows 2016 nicht angepasst wurde und zwar der "Systemstate" gesichert wurde aber die "Bare metal recovery"-Option nicht eingeschlossen wurde. In meiner Testumgebung (Laptop mit HyperV und Backup eines Win2022 DC und Restore in eine neue VM hat das weniger als 30 Minuten gedauert. Hier wurde aber schon mehrere Tage ein Restore "versucht", ehe ich dazu gezogen wurde. Es kommt aber noch mehr zusammen.

Nur gut, dass der Kunde das Restore mal durchgespielt hat, sonst wäre das nie aufgefallen und im Notfall viel kostbare Zeit verstrichen.

Die Sicherung

Die Sicherung eines DCs ist mit Bordmitteln recht einfach möglich. Sie müssen das Feature "Windows Server Backup" installieren, denn die GUI "wbadmin.exe" ist zwar vorhanden, aber ohne den Unterbau kann sie nichts tun.

Add-WindowsFeature Windows-Server-Backup

Sie sollten dann erstmalig einfach ein Backup per GUI auf das Ziel einrichten und dabei darauf achten, dass Sie auch wirklich "alles" mitnehmen, was Sie mitnehmen möchten. Sie können ein "Full Backup" starten oder selbst die Komponenten auswählen. Sind sie dabei aber nicht zu sparsam. Wer z.B. nur den "Systemstate" sichert, kann damit keinen Server per "Bare metal" restaurieren.

Genau das ist aber das Szenario, welches ich hier durchspielen möchte. Ich möchte einen Server allein mit einer Windows-ISO-Datei und dem Backup auf einer virtuellen Disk wieder hochziehen. Das geht nur, wenn ich hier auch "Bare metal recovery" aktiviert wird und dann auch die EFI und anderen Partitionen gesichert werden.

Eine Sicherung des "System State" alleine ist nicht ausreichend!

Das sehen sie schon anhand der Liste, was im Systemstatus enthalten ist:

The system state contains boot files (Boot.ini, NDTLDR, NTDetect.com), the Windows Registry including COM settings, the SYSVOL (Group Policies and Logon Scripts), the Active Directory and NTDS.DIT on Domain Controllers and, if the certificates service is installed, the Certificate Store. If your server has the Web server role installed, the IIS Metadirectory will be included. If the server is part of a cluster, Cluster Service information will also be included.
Quelle: Parameter "-systemstate" https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/wbadmin-start-backup

Das Backup nimmt damit schon viele Dateien mit aber wie zuverlässig ist eine auf der Basis wiederhergestellte Windows Installation, wenn z.B. der komplette Virenscanner aus C:\Programme\Produktname fehlt?. Zudem wird ihnen eine reine Systemstatus-Sicherung gar nicht bei einer Wiederherstellung über eine CD angezeigt. Prüfen Sie daher, dass ihr Backup genug Daten mitnimmt.

REM Sicherung des Servers mit allen Bestandteilen nach E:
wbadmin start backup -allcritical -systemstate -backuptarget:e: -quiet

C:\>wbadmin start backup -allcritical -systemstate -backuptarget:e:
wbadmin 1.0 - Backup command-line tool
(C) Copyright Microsoft Corporation. All rights reserved.

Retrieving volume information...
This will back up (EFI System Partition),(C:),(\\?\Volume{d3d25179-2134-4313-a55e-4db21d0e0b04}\) to e:.
The backup operation to E: is starting.
Creating a shadow copy of the volumes specified for backup...
Creating a shadow copy of the volumes specified for backup...
Creating a shadow copy of the volumes specified for backup...
Windows Server Backup is updating the existing backup to remove files that have
been deleted from your server since the last backup.
This might take a few minutes.
Creating a backup of volume (EFI System Partition) (100.00 MB), copied (0%).
Creating a backup of volume (EFI System Partition) (100.00 MB), copied (100%).
Compacting the virtual hard disk for volume (EFI System Partition) (100.00 MB), completed (0%).
The backup of volume (EFI System Partition) (100.00 MB) completed successfully.
Creating a backup of volume (C:), copied (13%).
Creating a backup of volume (C:), copied (40%).
Creating a backup of volume (C:), copied (72%).
Creating a backup of volume (C:), copied (92%).
The backup of volume (C:) completed successfully.
Creating a backup of volume (533.00 MB), copied (100%).
Summary of the backup operation:
------------------

The backup operation successfully completed.
The backup of volume (EFI System Partition) (100.00 MB) completed successfully.
The backup of volume (C:) completed successfully.
The backup of volume (533.00 MB) completed successfully.
Log of files successfully backed up:

Wenn Sie wirklich Platz und Zeit sparen wollen, dann können Sie mit dem Parameter "-exclude" bestimmte Laufwerke, Verzeichnisse oder einzelne Dateien ausschließen.

Dann brauchen Sie nur noch einen geplanten Task auf dem Server einrichten, der zyklisch den Server sichert. Natürlich kann auch ein zentraler Scheduler aus der Ferne das Backup auf dem Server fernstarten. Dann haben Sie auch eine zentrale Zeitplanung und Kontrolle.

Schutz des Backup

Das Windows Server Backup kann eine Sicherung auf lokale Festplatten oder auch UNC-Pfade ablegen. Der aktive Part ist dabei aber immer das Backupprogramm auf dem Server. Für den Schutz gegen "Angreifer" hilft das nicht weiter, da ein Angreifer dann ebenfalls diese Pfade ansprechen, verschlüsseln oder löschen kann. Wir müssen also irgendwie erreichen, dass die Sicherungen selbst "sicher" sind und am besten mit einer Versionierung versehen sind. Leider ist mit den Windows Server Backup keine "Remote Sicherung" möglich. Sie können also erst einmal keinen Server aus der Ferne von einem besonders geschütztem System "abziehen".

Aber es gibt andere Optionen, damit nicht der Server selbst etwas schreiben muss.

  • Holen statt Schreiben
    Das eigentlich Backup-System könnte den Server im ersten Schritt anweisen, dass er ein Backup auf eine lokale temporäre Festplatte macht und nach dem Backup kopiert das Backup-System diese Dateien über das LAN auf seinen Langzeitspeicher. Das Backupsystem hat einen Benutzernamen, um auf dem Quellsystem die Daten von einer Freigabe zu lesen aber es gibt in die Gegenrichtung keine Berechtigungen.
    Wenn man die "Offenheit" von SMB vermindern möchte, dann kann auch ein anderes Transferprotokoll (RSync, FTP, HTTP) eingesetzt werden.
    Denkbar ist auch, dass das Ziellaufwerk in einem SAN liegt oder eine virtuelle VHDX-Datei ist, welche dynamisch bereitgestellt und eingebunden wird. Dann sichert das Backup nur noch virtuell auf eine "lokale" Festplatte, die aber dann woanders liegt.
  • Dynamische UNC-Freigabe
    Eine andere Überlegung nutzt die Möglichkeit auf Netzwerkfreigaben zu schreiben. Das Backup-System könnte vor dem Start einen "Share" einrichten, das Backup starten und danach die Freigabe wieder entfernen. Das Backup-System könnte jeden Tag ein neues Verzeichnis für die Server freigeben. Damit ist einem Angreifer kein Zugriff mehr auf die früher gesicherten Daten möglich. WBBackup kann selbst auf UNC-Pfade sichern aber man könnte auch eine VHDX-Datei mit "Mount-VHD" auf einem UNC-Pfad bereitstellen, die später im Ziel direkt eingebunden werden kann.

In allen Fällen ist natürlich zu beachten, dass der Speicher im Hintergrund, d.h. der BackupServer natürlich nicht Domainmitglied sein darf, sonst ist er auch nicht besonders geschützt. Sie sehen aber auch, dass die Einschränkungen der Bordmittel durchaus eine Change für 3rd Party Programme ist.

Einbinden einer VHDX-Datei auf anderer Disk oder gleichen Disks mit Exclude:

Wiederherstellung

Nehmen wir nun mal an, dass ihr Active Directory komplett verloren ist und sie nur noch ein Windows ISO-File und eine halbwegs aktuelle und vermutlich nicht korrumpierte Sicherung des Domain Controllers haben. Dann können Sie wie folgt vorgehen:

  • VM einrichten
    Dazu kann auch HyperV oder VMWare auf einem Notfall-Laptop reichen, welche eine leere Festplatte bekommt, die gleich oder größer als die Backupquelle ist, mit ausreichend CPU und RAM versehen ist und natürlich Zugriff auf das letzte Backup bekommt. Ich würde nicht davon ausgehen, dass das Backup über einen UNC-Pfad zu erreichen ist, wenn ihr gesamtes Netzwerk gerade "unpässlich" ist. Daher ist ein kopieren oder direkt eine Speicherung in einem passenden Festplattencontainer (VHDX, VMDK o.ä.) der natürliche Weg.

Die VM kann gerne eine Netzwerkkarte haben, die aber bitte noch keine Außenverbindung hat. Ein virtueller Switch kann dies bereitstellen.

  • Windows ISO-Datei
    Nun brauche ich noch die Windows Server Installationsquelle in der gleichen Version, um diese als DVD-Laufwerk an die virtuelle Maschine zu binden.
  • VM von CD starten.
    Je nach Virtualisierung ist es nun mehr oder wenig schwer die VM zum Booten von der CD zu bewegen, da eine Windows Server CD nur recht kurz zum Drücken einer Taste auffordert. Notfalls müssen Sie die VM eben mehrfach neu starten, den noch gibt es keine bootbare Installation
  • Reparatur auswählen
    Nach dem Start von der DVD und der Auswahl von Land, Sprache und Keyboard-Layout müssen Sie die Funktion "Repair" auswählen.

    In dem dann folgenden Menüs wählen Sie zu erst "Troubleshoot" und dann System Image Recovery
  • System Restore Punkt auswählen
    Wenn Sie alle Vorbereitungen korrekt abgeschlossen haben, dann sollten Sie nun direkt das letzte Backup des Servers angeboten bekommen.

    Wenn Sie keine Auswahl haben dann ist die Disk mit ihrem Backup nicht für Windows sichtbar (Treiber?) oder ihr Backup ist einfach nicht gültig und Sie müssen die Einstellungen bei der Sicherung noch einmal prüfen.
  • Optionale Einstellungen
    Im nächsten Dialog sehen Sie, dass Windows sogar die Partitionierung selbst macht. Weiter Anpassungen habe ich hier nicht machen müssen.

    Danach folgt noch eine Zusammenfassung mit der Warnung, das die Disks überschrieben werden.

    Und dann startet die Wiederherstellung selbst

Nach der Wiederherstellung wird das System automatisch neu gestartet.

Nach einigen Minuten wird das restaurierte Windows sie mit dem damaligen Stand begrüßen und zur Anmeldung an der Domain auffordern. Es ist ja ein Domain Controller. Denken Sie daran, dass das der erste Domain Controller im Feld ist und er noch keine Netzwerkverbindung haben darf. Entsprechend kann das Hochfahren etwas länger dauern und ist sicher nicht ohne Fehler. Das gilt umso mehr, wenn der DNS-Server noch nicht verfügbar ist und andere Abhängigkeiten einfach Zeit brauchen.

Manchmal sehen Sie den "Shutdown Tracker", da das Backup ja per VSS im laufenden Betrieb erfolgte und Windows daher keinen "Clean Shutdown" finden kann.

Ehe Sie das System aber für den weiteren Betrieb vorsehen, sind einige wichtige Dinge vorab zu erledigen, die ich weiter unten noch beschreibe.

Probleme mit Restore

Zuerst beschäftige ich mich aber mit den ein oder anderen Problemen, die ich bei Kunden beseitigen bzw. in meinem Testumgebungen nachstellen konnte.

  • Kein Backup sichtbar
    Mein erster Fehler war, dass Windows Backup gar kein gültiges Restore-Medium angezeigt hat. Da durfte ich das erste mal lernen, dass ein "SystemState"-Backup alleine nicht reicht. Ich habe dann versucht, zuerst einen identischen Windows Server zu installieren und dann ein Systemstate-Restore zu machen. Das hat aber nicht funktioniert, über den Weg aus dem Server einen DC zu machen und dauert auch wohl zu lange. Daher haben wir das Backup dann "richtig" gemacht, so dass das Restore auch eine gültige Quelle findet.
  • Festplatten "passen" nicht
    Die Wiederherstellung partitioniert die Zielfestplatten, die dazu aber nicht kleiner sein dürfen. Wissen Sie aber auswendig gerade, wie groß genau ihre Festplatten eines ausgefallenen DCs sind?. Die Fehlermeldungen sagen dazu zumindest nicht viel aus:

  • Buchstabenchaos
    Wenn sie auf ihrem Quell-Server die Laufwerke z.B. C:/D:/E: nummeriert haben und das (virtuelle) DVD-Laufwerk nach Z: verschoben haben, dann wird nach dem Restore die Kennzeichnung anders sein. Wenn D: dann das DVD-Laufwerk ist, dann sind alle anderen Laufwerke verschoben. Wenn Sie dann noch SYSVOL und NTDS von C: auf D: verschoben haben, dann kann der DC beim Hochfahren kein AD starten. Dann brauchen Sie den NTDS Recovery Mode, um ohne lokales AD die Laufwerken zu sortieren.
  • Offline-Disks
    Wenn Sie mit Windows Backup einen Server mit mehreren Disks restaurieren, dann sind die weiteren Disks erst einmal "Offline". Das gilt auch wieder für DCs, deren NTDS.DIT auf so einer anderen Disk liegt.

    Nach dem Restore müssen Sie also die Disks über das Festplattenmanagement oder DISKPART erst einmal online schalten.
  • ReadOnlyFestplatten
    Eine weitere Überraschung ist, dass die Festplatten dann aber auch noch "ReadOnly" gekennzeichnet sind. Zuerst habe ich im Windows Explorer gesehen, dass ich kein "New"-Menü hatte und keine Dateien löschen oder umbenennen konnte. Eine Auswertung der NTFS-Berechtigungen hat aber keine Einschränkungen angezeigt:

    Hier hilft dann DISKPART, um die Disk von ReadOnly nach ReadWrite umzustellen. Mich hat das auf einem DC-Restore erwischt und alle Prüfungen mit EXEUTILNT oder NTDSUTIL haben natürlich keine Fehler gezeigt, das diese erst einmal nur lesend unterwegs sind.
  • Win2022DC Restore mit Windows 2019 DVD
    Einmal habe ich eher aus Unachtsamkeit eine Windows 2019-ISO-Datei zum Booten genutzt um dann ein Restore eines Windows 2022 DCs zu machen. Das hat überraschenderweise funktioniert.

Ich habe die Testserie nun nicht weiter auf unterschiedliche Vm-Generationen (Getn1 vs. Gen2)  UEIF

Sonderfall NTDS.DIT

Bei der Wiederherstellung eines ersten Domain Controllers erwartet man, dass die NTDS.DIT fehlerfrei angekommen ist. Das tut sie meist und meine Probleme waren wirklich nur ein unvollständiges Backup, verdrehte Laufwerksbuchstaben, Offline und ReadOnly-Disks. Sie sollten dennoch wissen, wie Sie eventuell einen fehlenden NTDS-Eintrag ins Bootmenü addieren, oder mit NTDSUTIL die Existenz einer AD-Konfiguration prüfen und mit ESENTUTL ggfls. Reparieren. Dennoch möchte die Fehler dazu nicht unterschlagen.

  • STOP Code 0xc0002e2
    Das bedeutet, dass der Domain Controller das Active Directory nicht starten kann. Windows macht einen Neustart. Zur Fehlersuche sollten Sie dann den NTDS RecoveryMode durch Drücken von F8 beim Booten starten. Dann können Sie sich an Windows mit dem Wiederherstellungskennwort anmelden und z.B. im Eventlog (Verzeichnisdienst) nach den Ursachen schauen oder die NTDS.DIT mit ESEUTLNT.EXE analysieren.
  • Eventlog Fehler -510 JET_errLogWriteFail / Failure writing to log file
    Dieser Fehler sagt eigentlich aus, dass das Active Directory keine Protokolldateien schreiben kann. Die Microsoft Hinweise deuten auf Festplattenfehler, defekte Disks oder auch einen Virenscanner hin. Eine nach der Wiederherstellung auf Offline oder ReadOnly gesetzte Disk steht noch nicht auf der Liste
    https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/jet-database-errors-recovery-steps#-510-jet_errlogwritefail--failure-writing-to-log-file

Wenn ihr Active Directory nicht läuft, dann gibt es den "DSRM Mode". Beim Booten müssen sie nur rechtzeitig "F8" drücken:

Sollte der Eintrag nicht vorhanden sein, können Sie diesen manuell mit BCDEDIT addieren.

BCDEDIT /copy {current} /d "DSRMMode"
BCDEDIT /set {GUID der Copie} safeboot dsrepair
BCDEDIT /timeout 10
reboot

In einer administrativen Shell können Sie mit NTDSUTIL erst einmal die Informationen abrufen.

C:> ntdsutil.exe
activate instance ntds 
files
status

Wenn das Active Directory "down" ist, dann können Sie mit ESENTUTL.EXE erst einmal den Status anschauen. Wünschenswert ist ein "CleanShutdown". Sollte hier ein "DirtyShutdown" stehen, dann braucht die Datenbank die darunter aufgeführten Logdateien, um wieder konsistent zu werden. Die Exchange Administratoren werden hier sehr große Ähnlichkeiten zu ESEUTIL und Exchange Datenbanken sehen.

ESEUTIL /MH C:\Windows\NTDS\NTDS.DIT

Dieser Befehl geht nur, wenn das Active Directory "down" ist, da ansonsten die Datei natürlich gesperrt ist.

Wer mag, kann mit "/k" auch die physikalische Konsistenz prüfen, da die Datenbank über jede Page eine CRC-Prüfsumme legt.

Wenn hier allerdings Fehler erscheinen, dann sollten Sie ein neues Restore starten, denn technisch bedeutet dies, dass sich zwischen dem letzten "Schreiben" und dem jetzigen "Lesen" etwas verändert hat. Meist Festplattenfehler/Treiberfehler oder auch mal ein voreiliger Virenscanner oder doch ein Cryptotrojaner.

Ein weitere Check betrifft die NTFS-Berechtigungen. MIttels CACLS/ICACLS können Sie die Rechte auf der NTFS.DIT.

C:> cacls c:\windows\ntds\ntds.dit
C:> cacls c:\windows\ntds\*.*

Normalweise haben "SYSTEM" und "BUILDIN\Administrators" hier Vollzugriff (vererbt).

Die meisten Probleme sollten über diese Prüfungen aber behoben werden können.

Nacharbeiten

Wenn nun ihr restaurierter Domain Controller in einer VM-Umgebung eigentlich wieder "ready" ist, so dürfen Sie diesen dennoch nicht sofort ans Netzwerk anschließen. Da gibt es schon einige Aufräumarbeiten, damit das System die Keimzelle ihrer neuen Umgebung mit den früheren Daten ist.

  • Kennworte ändern
    Sie haben eine Unmenge an Zugangskonten in ihrem Active Directory. Damit meine ich nicht nur die Menschen, sondern auch Admin- und Dienstkonten aber auch Computerkonten. Ein Angreifer kann jedes Konto kennen oder übernommen haben. Daher ist es wichtig, dass alle Konten entweder deaktiviert oder mit einem neuen Kennwort versehen werden.
  • Updates und Patches
    Wenn das AD durch eine "Traversal-Attacke" angegriffen wurde, dann hat der DC zum Glück keine Sicherheitslücke, sondern wurde von einem leider berechtigten Benutzer übernommen. Wenn Sie aber nicht wissen, wie lange das her ist, könnte der Angreifer schon lange eine Hintertür auf dem DC hinterlegt haben. Sie sollten also den DC genau untersuchen, z.B. durch verschiedene Virenscanner.
    Wenn es natürlich eine bekannte Lücke gibt, dann muss die zuerst gestopft werden, ehe die neue VM ihr neues AD wird.
  • IP-Adresse/Namensauflösung/DNS
    Der restaurierte Server hat ja eine "neue" Netzwerkkarte und diese nutzt DHCP. Sie sollten der Netzwerkkarte die frühere statische Adresse samt sich selbst als DNS-Server geben. Eventuell müssen Sie im Gerätemanager die alte nicht mehr aktive Karte entfernen.
  • AD-Cleanup
    Ich gehe mal davon aus, dass sie auch alle anderen DCs nun basierend auf dem ersten DC "neu" installieren und nicht per Restore zurückholen. Dann müssen Sie aber erst mal alle alten DCs aus der Konfiguration entfernen. Das betrifft die Objekte in AD-Sites&Services, aber auch AD Users&Computers und vergessen Sie die FRS-Replikation (SYSVOL/NETLOGON) und die alten DNS-Einträge unter _msdcs.<domain> nicht, die noch auf die alten DCs verweisen.

Diese Liste nicht nicht vollständig aber die Details sind doch abhängig von ihrer individuellen Umgebung. Ab nun müsste die Beschreibung noch mehrere Seiten länger werden, denn die Liste ist nur ein Anfang. hier noch ein paar Stichpunkte.

  • DHCP/DNS
    Wenn der neue Server kein DNS/DHCP-Server ist, dann müssen Sie diese Dienste auch wieder erst bereitstellen, ehe die ersten anderen Server und später die Client wieder online gehen können. Denken Sie auch an Radius und 802.1x-Anmeldungen.
  • Server "Rejoinen"
    Wenn es Server gibt, die noch "vertrauenswürdig" sind, dann "sollten" diese mit dem neuen DC eigentlich problemlos weiter laufen, Computerkennworte sind ja 60 Tage gültig. Aber können Sie den "Computerkonten" noch trauen. So haben Exchange Computer als "Exchange Trusted Subsystem" doch richtig viele Rechte. Vielleicht ist es besser, die Computerkonten zurückzusetzen und neu zu verbinden. (NET DOM etc.)
  • Benutzer-Zugänge
    Auch die Zugangsdaten der Anwender müssen, sobald die Server und minimalen Dienste wieder verfügbar sind, auf einem sicheren Weg zum Anwender kommen.
  • Und noch viele Dinge mehr
    Die Liste ist hier noch lange nicht fertig.

Am besten denken und spielen Sie einmal in Ruhe durch, welche Dinge sie wiederverwenden können und welche sie wie neu machen müssen. Jetzt sollten Sie die Ruhe haben und sich die Zeit dazu nehmen. Wenn Sie Freitags abends auf den Einbruch aufmerksam gemacht wurden, dann ist ein Wochenende ganz schnell vorbei. Spätestens ab Montag kostet "nicht arbeitsfähige" Mitarbeiter, Vertrieb, Auslieferung, etc. viel Geld und der Druck nimmt deutlich zu.

Weitere Links