24
Linux VM HyperV hängt jeden Montag bei fsck
Moinsen,
wir betreiben drei Ubuntu 14.04 LTS-VMs auf HyperV 2012R2. Damit die Daten auch schön konsistent bleiben, wird vor der Datensicherung jede Nacht die VM per Powershell heruntergefahren. Jeden Montag Morgen (und nur jeden Montag Morgen) bleibt die VM beim erneuten Hochfahren allerdings mit der Meldung hängen, dass bei der Prüfung Fehler in / festgestellt wurden. Es muss eine Entscheidung getroffen werden, ob eine Reparatur versucht werden soll o.ä.
Unschön, das. Um Fehler im Dateisystem auszuschließen, boote ich nun die VM mit einer Live-CD und lasse von dort ein fsck auf / los. Ergebnis jedes Mal: Keine Fehler.
Kennt jemand dieses Phänomen? Im Notfall könnte ich eine automatische "Reparatur" (ist ja scheinbar nix kaputt) konfigurieren, aber vielleicht hat noch jemand von Euch eine Idee... Was mich auch interessieren würde, wo ist dieser wöchentliche Check konfiguriert? Läuft das über die fstab? In der Cron konnte ich nichts finden.
Gruß
wir betreiben drei Ubuntu 14.04 LTS-VMs auf HyperV 2012R2. Damit die Daten auch schön konsistent bleiben, wird vor der Datensicherung jede Nacht die VM per Powershell heruntergefahren. Jeden Montag Morgen (und nur jeden Montag Morgen) bleibt die VM beim erneuten Hochfahren allerdings mit der Meldung hängen, dass bei der Prüfung Fehler in / festgestellt wurden. Es muss eine Entscheidung getroffen werden, ob eine Reparatur versucht werden soll o.ä.
Unschön, das. Um Fehler im Dateisystem auszuschließen, boote ich nun die VM mit einer Live-CD und lasse von dort ein fsck auf / los. Ergebnis jedes Mal: Keine Fehler.
Kennt jemand dieses Phänomen? Im Notfall könnte ich eine automatische "Reparatur" (ist ja scheinbar nix kaputt) konfigurieren, aber vielleicht hat noch jemand von Euch eine Idee... Was mich auch interessieren würde, wo ist dieser wöchentliche Check konfiguriert? Läuft das über die fstab? In der Cron konnte ich nichts finden.
Gruß
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 285758
Url: https://administrator.de/forum/linux-vm-hyperv-haengt-jeden-montag-bei-fsck-285758.html
Ausgedruckt am: 22.04.2025 um 04:04 Uhr
24 Kommentare
Neuester Kommentar
Hallo,
wozu schaltest Du die Server bitte immer aus?
Server sollen immer laufen.
Was für Dienste laufen denn da drauf? Normalerweise macht man ein Backup der laufenden VM (z.B. Veam) und je nach Dienst Backup (z.B. Mysql mit mysqldump)
Wenn Du den Rechner mit Powershell aus machst kann das für die Linux VM aber so ein als würdest Du einfach den Stecker ziehen.. Wenn lass sich die VM intern um Uhrzeit X selber runterfahren.
Pürfe mal das Host Dateisystem.
Mach einen fsck vom System selber ohne Bootcd.
Ein Linux wird nach X mal neu starten bzw nach X Tagen einem fsckeck nach dem nächsten booten machen wollen.
Und das solange bis das System den selber macht und dann den Timer im System zurücksetzt oder es in der fstab ausgeschaltet wird.
Bei Deinem dauernden runterfahren un d neu starten wird der Timer für die automatishe Prüfung in Abhängigkeit von Neustarts evtl erreicht sein.
Gruß
Chonta
wozu schaltest Du die Server bitte immer aus?
Server sollen immer laufen.
Was für Dienste laufen denn da drauf? Normalerweise macht man ein Backup der laufenden VM (z.B. Veam) und je nach Dienst Backup (z.B. Mysql mit mysqldump)
Wenn Du den Rechner mit Powershell aus machst kann das für die Linux VM aber so ein als würdest Du einfach den Stecker ziehen.. Wenn lass sich die VM intern um Uhrzeit X selber runterfahren.
Pürfe mal das Host Dateisystem.
Mach einen fsck vom System selber ohne Bootcd.
Ein Linux wird nach X mal neu starten bzw nach X Tagen einem fsckeck nach dem nächsten booten machen wollen.
Und das solange bis das System den selber macht und dann den Timer im System zurücksetzt oder es in der fstab ausgeschaltet wird.
Bei Deinem dauernden runterfahren un d neu starten wird der Timer für die automatishe Prüfung in Abhängigkeit von Neustarts evtl erreicht sein.
Gruß
Chonta
Hi Chonta,
danke für die Antwort.
PostgreSQL und MySQL, gesichert wird mit Veeam. Onlinesicherung bedingt doch aber in dem Fall eine nicht laufende DB? Konsistente Online-Sicherungen kann ich nur mit SQL- oder demnächst auch Oracle-DBs machen. Die VMs werden einmal pro Nacht um 04:00Uhr runtergefahren, die Sicherung geht schnell, nach 30 Minuten sind die wieder oben. Stört niemanden.
Nö, mit dem Powershell-Skript werden die ordentlich heruntergefahren, das läuft sauber.
Kann ich den Zeitpunkt beeinflussen? Ist tune2fs eine Alternative?
Gruß
danke für die Antwort.
Was für Dienste laufen denn da drauf? Normalerweise macht man ein Backup der laufenden VM (z.B. Veam) und je nach Dienst Backup (z.B. Mysql mit mysqldump)
PostgreSQL und MySQL, gesichert wird mit Veeam. Onlinesicherung bedingt doch aber in dem Fall eine nicht laufende DB? Konsistente Online-Sicherungen kann ich nur mit SQL- oder demnächst auch Oracle-DBs machen. Die VMs werden einmal pro Nacht um 04:00Uhr runtergefahren, die Sicherung geht schnell, nach 30 Minuten sind die wieder oben. Stört niemanden.
Wenn Du den Rechner mit Powershell aus machst kann das für die Linux VM aber so ein als würdest Du einfach den Stecker ziehen.. Wenn lass sich die VM intern um Uhrzeit X selber runterfahren.
Nö, mit dem Powershell-Skript werden die ordentlich heruntergefahren, das läuft sauber.
Ein Linux wird nach X mal neu starten bzw nach X Tagen einem fsckeck nach dem nächsten booten machen wollen.
Kann ich den Zeitpunkt beeinflussen? Ist tune2fs eine Alternative?
Gruß
Hallo,
zumindest für MySQL gibt es mysqldump mit dem Du wenn die Server laufen ein Backup machst.
Veam macht von der laufenden VM einen Snapshot wenn du so willst.
Du kannst den fscheck auch in der fstab einfach abschalten oder den Wert verändern jo.
Gruß
Chonta
zumindest für MySQL gibt es mysqldump mit dem Du wenn die Server laufen ein Backup machst.
Veam macht von der laufenden VM einen Snapshot wenn du so willst.
Du kannst den fscheck auch in der fstab einfach abschalten oder den Wert verändern jo.
Gruß
Chonta
Hallo,
Du solltest den Parameter "max-mount-counts" in der /etc/fstab abschalten bzw. auf 0 setzen.
http://crashmag.net/disable-filesystem-check-fsck-at-boot-time
MfG Andreas
Jeden Montag Morgen (und nur jeden Montag Morgen) bleibt die VM beim erneuten Hochfahren allerdings mit der Meldung hängen,
Du solltest den Parameter "max-mount-counts" in der /etc/fstab abschalten bzw. auf 0 setzen.
http://crashmag.net/disable-filesystem-check-fsck-at-boot-time
MfG Andreas
Hallo Coreknabe,
die Datensicherung umfasst immer die Sicherungs des Systems (Image) und die Sicherung der Daten.
Wenn du mit Veeam die VM sicherst hast du das Image schon erledigt.
Für die Sicherung der Daten sprich Datenbanken würde ich ein Script auf den Servern einrichten, das jeden Tag Abends ein Backup aller DB erstellt und die Backups der letzten 7 Tage aufhebt. Dieses Backups kannst du dann mit der Datensicherung deiner Wahl im laufenden Betrieb des Servers sichern.
Somit solltest du für alle Fälle gewappnet sein.
Das wäre aus meiner Sicht der sinnvollste Weg.
Grüße vom it-frosch
die Datensicherung umfasst immer die Sicherungs des Systems (Image) und die Sicherung der Daten.
Wenn du mit Veeam die VM sicherst hast du das Image schon erledigt.
Für die Sicherung der Daten sprich Datenbanken würde ich ein Script auf den Servern einrichten, das jeden Tag Abends ein Backup aller DB erstellt und die Backups der letzten 7 Tage aufhebt. Dieses Backups kannst du dann mit der Datensicherung deiner Wahl im laufenden Betrieb des Servers sichern.
Somit solltest du für alle Fälle gewappnet sein.
Das wäre aus meiner Sicht der sinnvollste Weg.
Grüße vom it-frosch
Moin,
danke für Eure Antworten!
Würde er ja machen, wenn er denn wüsste, was die Ursache ist.
Gruß
danke für Eure Antworten!
würde ich nicht machen, er soll lieber die Ursache beseitigen.
Würde er ja machen, wenn er denn wüsste, was die Ursache ist.
Gruß
Hallo,
wenn Du jede Nacht deine Linux VM per Powershell abschaltest, wird nach dem 7 Neustart automatisch ein fsck gestartet. Dieses Verhalten kannst Du selber in der Linux VM einstellen oder abschalten, z.B. "tune2fs -c 0 /dev/sda1".
Die andere Möglichkeit wäre die VM in Echzeit (VSS) zu sichern. Kurz vor der Sicherung kannst Du per Cron, in deiner VM evtl. vorhandene Datenbanken anhalten bzw. in einen konsistenten Zustand versetzen.
MfG Andreas
würde ich nicht machen, er soll lieber die Ursache beseitigen.
wenn Du jede Nacht deine Linux VM per Powershell abschaltest, wird nach dem 7 Neustart automatisch ein fsck gestartet. Dieses Verhalten kannst Du selber in der Linux VM einstellen oder abschalten, z.B. "tune2fs -c 0 /dev/sda1".
Die andere Möglichkeit wäre die VM in Echzeit (VSS) zu sichern. Kurz vor der Sicherung kannst Du per Cron, in deiner VM evtl. vorhandene Datenbanken anhalten bzw. in einen konsistenten Zustand versetzen.
MfG Andreas
Danke noch mal!
Schon klar, das würde helfen, die URSACHE habe ich damit doch aber immer noch nicht, nämlich warum das System jedes Mal der Meinung ist, ein fehlerhaftes Dateisystem vorzufinden. Meine Vermutung geht in Richtung HyperV, mit HyperV 2008R2 und Linux-VMs hatten wir nur Probleme.
Gruß
Schon klar, das würde helfen, die URSACHE habe ich damit doch aber immer noch nicht, nämlich warum das System jedes Mal der Meinung ist, ein fehlerhaftes Dateisystem vorzufinden. Meine Vermutung geht in Richtung HyperV, mit HyperV 2008R2 und Linux-VMs hatten wir nur Probleme.
Gruß
Hallo,
für diese Verhalten gab es einen (Hyper-V) Kernel-Patch am 16.4.2015. Selbst habe ich den Patch nicht getestet, habe lediglich:
Ubuntu 12.04 Server
Ubuntu 13.10
unter Hyper-V 2012 (ohne Probleme) am laufen. Evtl. hier mal nachsehen:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1445195
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1456985
Mit freundlichen Grüßen Andreas
für diese Verhalten gab es einen (Hyper-V) Kernel-Patch am 16.4.2015. Selbst habe ich den Patch nicht getestet, habe lediglich:
Ubuntu 12.04 Server
Ubuntu 13.10
unter Hyper-V 2012 (ohne Probleme) am laufen. Evtl. hier mal nachsehen:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1445195
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1456985
Mit freundlichen Grüßen Andreas
Hi Andreas,
danke... Das mit den Integration Service für Linux-VMs scheint nicht so ganz rund zu laufen, auch wenn die Links von Dir nicht unser Problem beschreiben. Ärgere mich schon ein wenig über den Umzug von Virtualbox auf HyperV, unter Virtualbox hatte ich überhaupt keine Probleme, da liefen die VMs auf einer Workstation.
Ich hatte vor einer Weile auch schon mal hier gepostet, die Meldungen im Eventlog bekommen wir immer noch...
https://social.technet.microsoft.com/Forums/de-DE/2e52b792-f990-4f30-ab5 ...
Gruß
danke... Das mit den Integration Service für Linux-VMs scheint nicht so ganz rund zu laufen, auch wenn die Links von Dir nicht unser Problem beschreiben. Ärgere mich schon ein wenig über den Umzug von Virtualbox auf HyperV, unter Virtualbox hatte ich überhaupt keine Probleme, da liefen die VMs auf einer Workstation.
Ich hatte vor einer Weile auch schon mal hier gepostet, die Meldungen im Eventlog bekommen wir immer noch...
https://social.technet.microsoft.com/Forums/de-DE/2e52b792-f990-4f30-ab5 ...
Gruß
Hallo,
Ich gehe mal davon aus, das Du kein ext2 Filesystem benutzt und auch den VSS Snapshot daemon (Ubuntu) nachinstalliert hast?
Die Punkte 3, 4, 5, 13 hier hast Du auch sicherlich schon abgearbeitet?
Wie schon beschrieben Server 2012 Hyper-V mit Ubuntu 12.04 Server (4 Server) keine Probleme, fahre jeden Tag um 22 Uhr ein Voll-Backup.
MfG Andreas
Ich hatte vor einer Weile auch schon mal hier gepostet, die Meldungen im Eventlog bekommen wir immer noch...
Ich gehe mal davon aus, das Du kein ext2 Filesystem benutzt und auch den VSS Snapshot daemon (Ubuntu) nachinstalliert hast?
Die Punkte 3, 4, 5, 13 hier hast Du auch sicherlich schon abgearbeitet?
Wie schon beschrieben Server 2012 Hyper-V mit Ubuntu 12.04 Server (4 Server) keine Probleme, fahre jeden Tag um 22 Uhr ein Voll-Backup.
MfG Andreas
Moin,
wir haben unter Server 2012R2 zweimal Ubuntu 14.04 mit LIS am Laufen.
Die PostgreSQL - Datenbanken werden mit Hilfe eines Skripts auf eine CIFS-Freigabe separat gesichert. Danach wird der Snapshot der jeweiligen VM mit Veeam durchgeführt. Somit sind OS und Datenbank sauber getrennt und je nach Ausfall kann flexibel Snapshot mit DB-Sicherung kombiniert werden.
Gruß,
Dani
wir haben unter Server 2012R2 zweimal Ubuntu 14.04 mit LIS am Laufen.
Nö, mit dem Powershell-Skript werden die ordentlich heruntergefahren, das läuft sauber.
Wie hast du das festgestellt? Dürfen wir das Skript mal sehen? Tritt das Problem auch auf, wenn du die VM manuell herunterfährst und wieder startest?Die PostgreSQL - Datenbanken werden mit Hilfe eines Skripts auf eine CIFS-Freigabe separat gesichert. Danach wird der Snapshot der jeweiligen VM mit Veeam durchgeführt. Somit sind OS und Datenbank sauber getrennt und je nach Ausfall kann flexibel Snapshot mit DB-Sicherung kombiniert werden.
Gruß,
Dani
Moinsen,
@andreas: Den Link habe ich schon gesehen und seinerzeit auch abgearbeitet.
@Dani: Skript in dem Sinne ist übertrieben, ich habe eine Batchdatei erstellt, die jeweils mit Powershell ein "stop-vm" und "start-vm" ausführt. Dass es sauber läuft, sehe ich, wenn ich das Skript ausführe und zeitgleich die Konsole der VM beobachte --> Keine Fehler, System kommt sauber wieder hoch.
Ich glaube, dieser Thread bekommt allmählich die falsche Richtung... Ich habe keine Probleme mit der Sicherung an sich, sondern JEDEN MONTAG das Problem, dass das System nicht sauber wieder hochfährt!
Da im Technet-Forum andere ebenfalls von dem Problem berichten, habt Ihr mit Euren VMs diese oben beschriebenen Eventlog-Einträge nicht?
Gruß
@andreas: Den Link habe ich schon gesehen und seinerzeit auch abgearbeitet.
@Dani: Skript in dem Sinne ist übertrieben, ich habe eine Batchdatei erstellt, die jeweils mit Powershell ein "stop-vm" und "start-vm" ausführt. Dass es sauber läuft, sehe ich, wenn ich das Skript ausführe und zeitgleich die Konsole der VM beobachte --> Keine Fehler, System kommt sauber wieder hoch.
Ich glaube, dieser Thread bekommt allmählich die falsche Richtung... Ich habe keine Probleme mit der Sicherung an sich, sondern JEDEN MONTAG das Problem, dass das System nicht sauber wieder hochfährt!
Da im Technet-Forum andere ebenfalls von dem Problem berichten, habt Ihr mit Euren VMs diese oben beschriebenen Eventlog-Einträge nicht?
Gruß
Hallo,
ja ich bekomme auch Meldungen im Hyper-V das eine der VM angeblich eine falsche Version von irgendwas verwendet, aber ich hab die Meldung auch bei Windows-Servern mit selben Patchstand wie der Hyper-V von daher....
Das so ziehmlich alle dein backup etwas in Frage stellen, sollte Dir zu denken geben.
Ob Dir der Hyper-V sagt alles ist in Ordnung oder nicht spielt keine Rolle, wenn das System in der VM um Hilfe brüllt.
Dazu wurde schon was gesagt, und auch wie Du den fscheck nach x neustarts ausschaltest.
Gruß
Chonta
ja ich bekomme auch Meldungen im Hyper-V das eine der VM angeblich eine falsche Version von irgendwas verwendet, aber ich hab die Meldung auch bei Windows-Servern mit selben Patchstand wie der Hyper-V von daher....
Das so ziehmlich alle dein backup etwas in Frage stellen, sollte Dir zu denken geben.
Ob Dir der Hyper-V sagt alles ist in Ordnung oder nicht spielt keine Rolle, wenn das System in der VM um Hilfe brüllt.
Ich habe keine Probleme mit der Sicherung an sich, sondern JEDEN MONTAG das Problem, dass das System nicht sauber wieder hochfährt!
Dazu wurde schon was gesagt, und auch wie Du den fscheck nach x neustarts ausschaltest.
Gruß
Chonta
Moin Chonta,
danke für die Rückmeldung.
Können sie gern tun, ich weiß aber, dass es funktioniert. Problem ist auch nicht das Backup an sich, sondern fsck. Wie ich das deaktiviere, weiß ich auch, habe ich auch schon im Eröffnungsthread geschrieben. Frage ist halt die Ursache und das hat meiner Meinung nach nix mit dem Backup zu tun, sondern mit einem regelmäßigen Anstarten des fsck, deshalb tritt das Problem ja auch nur Montags auf. Meine Vermutung: die Linux-VM ist nicht sauber in HyperV integriert. Ihr habt das Problem logischerweise nicht, weil Ihr die VMs nicht dauernd runter- und wieder rauffahrt. Bei einer sauberen Implementierung sollte das aber kein Problem sein.
Natürlich gibt es diverse Workarounds, aber meine Frage geht in die Richtung nach der Ursache...
Gruß
danke für die Rückmeldung.
Das so ziehmlich alle dein backup etwas in Frage stellen, sollte Dir zu denken geben.
Natürlich gibt es diverse Workarounds, aber meine Frage geht in die Richtung nach der Ursache...
Gruß
Hallo,
jeden Montag = alle 7 Tage = 7 Mounts
was sagt
tune2fs -l /dev/<deine root platte>
Mount count: ?
Maximum mount count: ?
Last checked: ?
Check interval: ?
Sagen die Logs im Linux auch das es sauber runtergefahren wurde oder gibt es da Anzeichen, das einfach PowerOff war?
Eine Umstellung auf einen cronjob der die VM intern aus macht, ist in jedem Fall sauberer als ein Befehl von außern der evtl nicht lange genug wartet.
Wenn Du keine Probleme hast, wenn die VM durch einen internen Job ausgemacht wird, liegt es am ausschalten durch Powershell, wenn da das gleiche Problem auftritt und "Maximum mount count" nicht zufällig 7 ist oder "Check interval" auf 7 Tage gestellt ist....
Ist die Frage was am Montag anders ist an den anderen Tagen, Überschneidung von backups? Lastpitzen? Raidcontrollercheck wennd ie VM wieder starten soll?
Kurzum was läuft am Montag zwischen Backup beginnend dem Ausschalten und dem starten der VM?
Was sagen die Logs im Linux?
Gruß
Chonta
jeden Montag = alle 7 Tage = 7 Mounts
was sagt
tune2fs -l /dev/<deine root platte>
Mount count: ?
Maximum mount count: ?
Last checked: ?
Check interval: ?
Sagen die Logs im Linux auch das es sauber runtergefahren wurde oder gibt es da Anzeichen, das einfach PowerOff war?
Eine Umstellung auf einen cronjob der die VM intern aus macht, ist in jedem Fall sauberer als ein Befehl von außern der evtl nicht lange genug wartet.
Wenn Du keine Probleme hast, wenn die VM durch einen internen Job ausgemacht wird, liegt es am ausschalten durch Powershell, wenn da das gleiche Problem auftritt und "Maximum mount count" nicht zufällig 7 ist oder "Check interval" auf 7 Tage gestellt ist....
Ist die Frage was am Montag anders ist an den anderen Tagen, Überschneidung von backups? Lastpitzen? Raidcontrollercheck wennd ie VM wieder starten soll?
Kurzum was läuft am Montag zwischen Backup beginnend dem Ausschalten und dem starten der VM?
Was sagen die Logs im Linux?
Gruß
Chonta
Hi Chonta,
tunefs sagt dies:
In den Logs finde ich keine Auffälligkeiten.
Gruß
tunefs sagt dies:
tune2fs 1.42.9 (4-Feb-2014)
Filesystem volume name: <none>
Last mounted on: /
Filesystem UUID: 9685efdc-04d4-440a-b243-9a9f7f2120e0
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 6291456
Block count: 25136640
Reserved block count: 1256832
Free blocks: 22793422
Free inodes: 5966931
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 1018
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Flex block group size: 16
Filesystem created: Thu Sep 29 12:18:13 2011
Last mount time: Thu Oct 29 05:00:33 2015
Last write time: Thu Oct 29 05:00:33 2015
Mount count: 17
Maximum mount count: 30
Last checked: Mon Oct 12 09:46:51 2015
Check interval: 15552000 (6 months)
Next check after: Sat Apr 9 09:46:51 2016
Lifetime writes: 956 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: ef7a6653-3c2f-40b0-b477-1e825d86894c
Journal backup: inode blocksIn den Logs finde ich keine Auffälligkeiten.
Gruß
Hallo,
Hast Du den mal durchlaufen lassen mit dem Check oder immer abgebrochen?
Gibt es noch mehr Partitionen oder ist alles unter / auf einer partition?
Nicht das eine andere Partiton geprüft werden will.
Gruß
Chonta
Last checked: Mon Oct 12 09:46:51 2015
Ist länger als 6 Monate her.Next check after: Sat Apr 9 09:46:51 2016
Der will einen Check machen.Hast Du den mal durchlaufen lassen mit dem Check oder immer abgebrochen?
Gibt es noch mehr Partitionen oder ist alles unter / auf einer partition?
Nicht das eine andere Partiton geprüft werden will.
Gruß
Chonta
Hi,
Check läuft ohne Probleme durch, wenn ich den mache.
Alles liegt unter /
Gruß
Check läuft ohne Probleme durch, wenn ich den mache.
Alles liegt unter /
Gruß
Hallo,
alles liegt immer unter /
Hatte auch überlesen das next Check after 2016 und nicht 2015 ist.
Dein Problem ist echt komisch.
Das es kontinuierlich Montags auftritt würde ich sagen das ein Anderer zeitgleich laufender Prozess auf dem Hyper-V ein Problem verursacht.
Wenn Du mal die Zeit des Montagsbackup vareierst?
Gruß
Chonta
alles liegt immer unter /
Hatte auch überlesen das next Check after 2016 und nicht 2015 ist.
Dein Problem ist echt komisch.
Das es kontinuierlich Montags auftritt würde ich sagen das ein Anderer zeitgleich laufender Prozess auf dem Hyper-V ein Problem verursacht.
Wenn Du mal die Zeit des Montagsbackup vareierst?
Gruß
Chonta
Hi,
"alles liegt immer unter /" wie "alles in Linux ist eine Datei"?
Herrje, ich habe doch gerade noch einmal den Backupvorgang unter die Lupe genommen... Das eigentliche Backup läuft problemlos durch, in der Nacht von Sonntag auf Montag jedoch folgt im Anschluss ein "Backup Copy Job", der das Backup zusätzlich auf ein anderes Target auslagert. Von dort erfolgt später eine Bandsicherung. Dem Backup Copy Job fehlen jedoch in der Konfiguration die "vorher/nachher"-Befehle, so dass vermutlich die VM einfach runterklatscht. Ist mir nicht aufgefallen, weil die Befehle und das Backup im Prinzip ja funktionieren. Das habe ich jetzt mal geändert und gebe dann am Montag morgen eine Rückmeldung, ob's geklappt hat.
So viele Bäume, so viel Wald...
Bis dahin schon einmal vielen Dank, insbesondere Dir, @Chonta !
"alles liegt immer unter /" wie "alles in Linux ist eine Datei"?
Herrje, ich habe doch gerade noch einmal den Backupvorgang unter die Lupe genommen... Das eigentliche Backup läuft problemlos durch, in der Nacht von Sonntag auf Montag jedoch folgt im Anschluss ein "Backup Copy Job", der das Backup zusätzlich auf ein anderes Target auslagert. Von dort erfolgt später eine Bandsicherung. Dem Backup Copy Job fehlen jedoch in der Konfiguration die "vorher/nachher"-Befehle, so dass vermutlich die VM einfach runterklatscht. Ist mir nicht aufgefallen, weil die Befehle und das Backup im Prinzip ja funktionieren. Das habe ich jetzt mal geändert und gebe dann am Montag morgen eine Rückmeldung, ob's geklappt hat.
So viele Bäume, so viel Wald...
Bis dahin schon einmal vielen Dank, insbesondere Dir, @Chonta !
Moin die Damen,
der Backup Copy Job war wie vermutet das Problem, jetzt rennt alles wie gewünscht. Danke Euch für's Schubsen in die richtige Richtung!
Wünsche einen guten Start in die Woche!
Gruß
der Backup Copy Job war wie vermutet das Problem, jetzt rennt alles wie gewünscht. Danke Euch für's Schubsen in die richtige Richtung!
Wünsche einen guten Start in die Woche!
Gruß
