Fragen nach Erstinstallation

Hi Volker,

The missing settings on appliance look really strange - this data is stored on the 2nd disk (2GB or 4GB) of the virtual appliance and are kept permanently no matter whether appliance is shut down or rebooted. This includes the licensing information and other settings of the backup tasks. I'd recommended contacting our support team to figure out what could be the problem (it's the first time I see something like this actually).

Concerning the deduplication process - in vmProtect we use inline deduplication where the hash database is built in RAM on the appliance side and therefore its performing dedup on fly without necessity to perform any additional maintenance. It might be slightly less effective than VDP deduplication, but much faster in any case.

Within one backup task the VMs are backed up one by one, since the data is saved into the same backup archive, however you can run up to 5 (by default - it can be adjusted) backup tasks simultaneously into different backup archives. Typically backing up 2 VMs in 2 separate backup tasks simultaneously is faster than backing up 2 VMs within 1 backup task consequently.

Concerning NFS support: there is currently no ability to save backups from vmProtect onto NFS share directly (this is however supported in Acronis Backup and Recovery Virtual Edition product line), so the only way to achive this is as you correctly mentioned attach the NFS share to ESXi host, then create a virtual disk on this datastore and attach this disk to virtual appliance (yes 2TB limit will be in place here for vSphere 5.1 or less - it can be overriden by using vSphere 5.5).

Thank you.
--
Best regards,
Vasily
Acronis vmProtect Program Manager

Hallo Vasily,

vielen Dank für Ihre Hinweise.
ich habe mehrere Tests durchgeführt. Mittlerweile ist Punkt 1 erledigt - warum, weiß ich auch nicht - ich habe meine Vermutungen im Support-Call
aufgeschrieben. Na jetzt geht es, von daher alles bestens...

Jetzt habe ich aus ihrer Beschreibung ihrer Vorgehensweise der Deduplizierung und der Hashtable im RAM Rückschlüsse gezogen und mehrere Tests
zum Sichern durchgeführt. Um das Ganze vergleichbar zu machen, habe ich nach jedem Versuch über die Console die Archive.TIB immer wieder
gelöscht.

5 virtuelle Maschinen - CPU wurde immer voll ausgenutzt
Test 1:
Komprimierung normal
4CPU
4GB RAM
Dauer 22min
Archivgröße 15,7GB

Test 2:
Komprimierung max
4CPU
4BG RAM
Dauer 23min
Archivgröße 13,8GB

Test 3:
Komprimierung max
8CPU
30GB RAM (hiervon max 12GB in Nutzung)
Dauer 12min
Archivgröße 13,8GB

Dies sagt mir, das die Hashtable der Deduplizierung eine scheinbar nicht änderbare Größe hat. Desweiteren scheint eine optimale Nutzung der
Acronis-App bei 8CPU + ca. 16GB RAM vorzuliegen. Dabei macht es richtig Spass der Sicherung zu zuschauen :-) Ist bei mehr RAM nicht noch eine
größere Hashtable möglich um die Deduplizierung noch zu verbessern oder wird die Hashtable hier nur aufgrund der geringen Backup-Datenmenge
nicht größer? Würde die Hashtable größer, wenn ich alle meine VMs darüber sichere (ca. 12 mit viel mehr Platzbedarf)? Zum besseren Verständnis,
3 von den 5 VMS sind nahezu identisch. Ich habe eine Windows-VM mit 11,6GB Datenmenge aufgesetzt und diese 2x dupliziert und lediglich PC-Name +
IP-Adresse geändert. Dennoch sichert das Backup 5,8 + 7,6 + 7,1 GB. Hier müsste doch die Deduplizierung viel stärker wirken?
Wie würden ihre Empfehlungen für eine optimale Einstellung von Anzahl CPU + RAM lauten? Würde mehr RAM eine bessere Deduplizierung ermöglichen? Ziel ist die optimale Verkleinerung der Archive.TIB.

Generell bin ich sehr begeistert von der Acronis-Appliance, ich habe auch mittlerweile die vmProtect mit 6CPU-Lizenzen gekauft.
Mehrere Wünsche habe ich noch offen und würde mich freuen, sollte dies in Ihrer Weiterentwicklung berücksichtigt werden können:
1. Ich finde (außer über die Console und Linux-Befehlen) über die GUI keine Möglichkeit die Archive.TIB zu löschen - gern auch mit zusätzlichen Warnhinweisen etc. - wenn sich etwas richtig verhakt hat, wäre dies eine gute Möglichkeit für einen schnellen Neuanfang...
2. Ich finde keine Möglichkeit, innerhalb der Archive.TIB eine einzelne VM zu löschen. Hier wünsche ich mir einen Task ähnlich der Validierung, mittels dem ich das Archiv lesen kann, eine oder mehrere VMs auswählen kann und diese dann samt all ihrer Replicationspunkte entfernt werden. Wenn ich eine VM im vsphere gelöscht habe, brauche ich diese auch im Archiv nicht mehr und möchte dazu gern den Platz wieder nutzbar machen.
3. Ich sehe in der Möglichkeit der NFS-Unterstützung großen Nutzen, da mein physischer Backup-Storage auf einem Linux-PC liegt und die Nutzung von Samba auf dem Linux gegenüber NFS erhebliche Performance-Verluste in der Geschwindigkeit der Sicherung mit sich bringen wird. Würde es was bringen - sozusagen als Workarround per Console die NFS-Freigabe zu mounten?

Noch eine letzte Frage: sollte ich nachdem ich das Produkt gekauft habe, nochmals die Installationsdatei herunterladen (gleiches Build, nur ohne dem Text Trial im Dateinamen) und Neuinstallieren oder reicht es, einfach die Seriennummern in der Appliance zu hinterlegen?

Hi Volker,

Thank you for the update! In terms of resources it makes sense to add up to 4GB of RAM to appliance - it's 32bit one, so it won't recognize more than this amount. The amount of CPUs affect performance during compression and deduplication activities. Dedup is based on 256kb blocks comparison, so its hash table will be practically the same when you back up the same VMs.

The 5.8 + 7.6 + 7.1 GB (=20.5Gb) sizes you see in recovery points view are actually not taking into account the deduplication - these sizes are calculated basing on each VM size + compression ratio. That's why the total size of them is not equal to the actual size of the archive (13.8GB).

Concerning your wishlist ideas:

1) The archive removal from GUI feature is currently pending for the next version only. Right now you can remove the archive by removing all of its recovery points from View->Recovery Points (not really convenient for archive including multiple VMs - that's true).
2) The recovery points for one VM can be all deleted in single action: you can ctrl-click or shift-click on recovery points in View->Recovery Points for selected VM and choose to delete them.
3) Not sure if I correctly undestood the question, but NFS support (saving backups to NFS) is planned for the next version currently and it's already present in Acronis Backup and Recovery product line. Hope I got it correctly :)

Thank you.
--
Best regards,
Vasily
Acronis vmProtect Program Manager

Hallo Vasily,
das Linux scheint dennoch mehr RAM verarbeiten zu können, es hatte bei meinem 30GB-RAM-Versuch 12 GB RAM im Einsatz. Sehen Sie dazu auch die erste Zeile ganz links im TOP-Command (Anhang) von der Acronis-vApp-Konsole (Der Screenshot ist jedoch nach der Sicherung entstanden). Ist es daher wirklich eine 32bit-Maschine und nutzt einen PAE enabled Kernel? Dann scheinen mir 16GB als sinnvoll...

Bei den Speichergrößen haben sie jedoch recht, die Speichergrößen aller 5 VMs sind 7,9+5,8+7,6+7,1+8,5=36,9GB. Da ist das Resultat 13,8GB ein sehr guter Wert

Nochmal meine letzte Frage: sollte ich nachdem ich das Produkt gekauft habe, nochmals die Installationsdatei herunterladen (gleiches Build, nur ohne dem Text "Trial" im Dateinamen) und Neuinstallieren oder reicht es, einfach die Seriennummern in der Appliance zu hinterlegen?

Hi Volker,

I have double-checked and indeed we have recently enabled PAE support in our linux kernel, so while it's still 32bit - it allows addressing more than 4GB limit. Sorry for misleading in my first reply - looks like that was the change I wasn't aware of before.

Concerning your last question - there is no need to re-download or re-install the virtual appliance after licenses purchase. You can simply add them under Configure->Licenses and this will upgrade the appliance to fully-functional one. Note that the licenses reassignment (trial->full) will occur automatically after the trial period expires, i.e. you don't need to revoke or re-assign the licenses manually.

Thank you.
--
Best regards,
Vasily
Acronis vmProtect Program Manager

Hallo Vasily,

vielen Dank für die Info, das macht das Ganze für mich rund.

Darf ich noch einen anderen Wunsch äußern, nachdem ich ein wenig getestet habe: Ich habe VM-Gäste, die ich täglich sichere (wichtige VMs) und nicht so wichtige, die ich wöchentlich sichere. Nun möchte ich natürlich alle Vorteile einer Archive.TIB wie Deduplizierung etc. nutzen. Derzeit wäre der Weg, zwei Backup-Tasks für die gleiche Archive.TIB anzulegen, einen Täglichen und einen Wöchentlichen und darauf zu achten, das nicht beide gleichzeitig laufen. Genau das kann Probleme verursachen.
Ich würde mir in einer der nächsten Versionen wünschen, das beim Starten eines zweiten Tasks den momentane Zugriff auf die Archive.TIB innerhalb der Appliance geprüft wird und im Falle eines anderen bereits gestarteten Tasks mit Zugriff auf die Archive.TIB der zweite Task nicht mit Fehler abgebrochen wird, sondern in eine Warteschlange gestellt wird, die sofort nach Ausführung des ersten Tasks abgearbeitet wird. Da ja eh nur alle VMs nacheinander in eine Archive.TIB gesichert werden sollte doch hier statt eines Fehlers eine Backup-Task-Warteschlange der zielführendere Weg sein.
Dies würde eventuelle Sicherungsfehler minimieren, dennoch für korrekte Sicherung sorgen und Konfigurationsprobleme umgehen.

Ach und wünschen würde ich mir auch im Dashboard die Anzeige der Task-Statistiken per Default auf täglich zu sehen - das wäre toll...

Hi Volker,

It is possible to back up different VMs in separate tasks into one single archive (archive.tib), but as you correctly mentioned it is important to ensure that tasks do not run at the same time to avoid write conflict. Right now there is an error handling setting which may help you to overcome the task failure (when 2 tasks are trying to write into the same archive): it's Retry VM processing option under Backup Options->Error Handling. This one allows to re-try the backup operation for the VM within the backup task. If you set up a larger re-try period (30 minutes for example) then the 2nd task should be able to re-try write attempt automatically once the 1st task finishes its activity.

What concerns the tasks statistics defaults - I've added your request to our wish list. Thank you for the feedback! :)

Thank you.
--
Best regards,
Vasily
Acronis vmProtect Program Manager

Hallo Vasily,
die Einstellungen kenne ich bereits und habe sie auch probiert, die haben jedoch einen entscheidenden Nachteil: In der Zeitleiste im Dashboard stehen nur noch Fehler. Im Übrigen funktioniert die Einstellungen in diesem Fehlerfalle auch nicht, der fehlgeschlagene Task wird nicht ein zweites Mal gestartet, er bleibt fehlgeschlagen!!
Dies ist auch sehr gefährlich, wenn man dadurch wichtige Fehler im Log nicht mehr erkennt. Das Dashboard mit geplanten Fehlern zu überschütten ist da keine gute Lösung.
Daher auch die Anfrage auf eine bereits geöffnete Archiv.TIB innerhalb der Appliance zu prüfen um hier eine Warteschlange ohne Fehlerdokumentation zu ermöglichen. Der zweite Tasks, der da gerade nicht starten kann, könnte doch 1x je Minute prüfen, ob die Archive.TIB innerhalb der Appliance anderweitig geöffnet ist UND mindestens ein anderer Backup-Task läuft. Dann wartet er einfach wieder 1 Minute und so weiter... Wenn dann zum Beispiel nach 3 Stunden die Archive.TIB nicht mehr im Zugriff ist, startet einfach der nächste Task und arbeitet alles ab usw...
Das Fehlerprotokoll bleibt sauber und alles ist bestens :-)

Momentan bleibt da nur die Möglichkeit die Backup-Tasks so weit auseinander zu legen, das sie sich nicht überschneiden... Ich würde mich freuen, wenn hierbei das Handling ein wenig angepasst werden kann...

Wäre es möglich, die Acronis-Einstellungen, welche ich derzeit nur als Textdatei runterladen und auf meinem PC speichern kann, auch automatisch bei jeder Sicherung mit in die Archive.TIB zu schreiben? Wäre es desweiteren auch möglich die ESX-Konfig-Sicherungen automatisch mit in die Archive.TIB zu schreiben?
Dies hätte den Vorteil, das ich im Desaster-Falle einen ESX minimal aufsetze, SSH freischalte, die Acronis-vApp installiere, die Archive.TIB einbinde und ab dem Zeitpunkt alles zurücksichern kann. Sowohl die Acronis-Einstellungen wie auch die ESX-Konfiguration.
Ich würde mich hierbei über einen planbaren wiederholbaren Task freuen, den ich zum Beispiel jeden Montag geplant ausführen würde und dabei sichergehe, das alle ESX- und Acronis-Einstellungen auf dem neuesten Stand sind.

Vielen Dank

Hi Volker,

We are considering merging the backup activities for different items (such as configuration + ESXi configuration + VM backup itself) into single unit in the next version where hopefully we will be able to get rid from "archive"-centric concept, so that the end-user won't have to worry about the archive naming (just specify the backup location). Thank you for the suggestion!

Thank you.
--
Best regards,
Vasily
Acronis vmProtect Program Manager

Hi Vasily,

vielen Dank für ihre Ausführungen, da bin ich ja schon sehr gespannt auf die nächste Version.
Ich hab gestern das System in den Echtbetrieb genommen und bin sehr begeistert von der Geschwindigkeit der Sicherung meiner gesamten ESX-Umgebung - große Klasse!!!

Meine Sicherungsumgebung sieht vor, die VMs in die Archive.TIB zu schreiben, welche per NFS eingebunden ist. Die NFS-Freigabe liegt auf einem Linux-System (CentOS) in welchem per Task nach der Acronis-Sicherung ein Kopiervorgang (cp) von meinem NFS-Storage auf eine 2TB-Festplatte stattfindet. Die 2TB-HDD wird täglich gewechselt, daher habe ich tägliche Vollsicherungen unserer ESX-Vmware-Umgebung auf Wechselfestplatten. Derzeit startet der Task, fährt die Acronis-Appliance per VCenter-Scripting herunter, kopiert die NFS-vmdk-Datei (samt Archive.TIB includiert) auf die Wechsel-HDD und startet danach wieder die Acronis-Appliance.

Hierfür wäre es toll, wenn ich aus Sicht des CentOS sicher herausbekommen könnte, ob die Acronis-Appliance gerade einen Sicherungsjob aktiv ausführt. Ist es möglich, per SSH oder Webabfrage o.ä. aus Linux-Batch-Scripting remote die Acronis-Appliance abzufragen, ob sie gerade einen aktiven Job (Backup/Restore/usw.) ausführt? Falls ja, wie wäre ein Beispielaufruf? Falls nein, könnte dies einprogrammiert werden? Also z.B. "https://Acronis-IP/#active" und ich bekomme ein False oder True z.B. als XML zurück. Damit könnte ich kurz nach Acronis-Job-Start den Kopierbefehl auf meinem CentOS starten und dieses Script würde z.B. alle 5min bei Acronis-App nachfragen, ob gerade ein Job aktiv ist. Nachdem dies mit False beantwortet wird, könnte CentOS die Acronis-Appliance ohne Gefahr herunterfahren und auf den Wechseldatenträger sichern. Das Sichern aus der Acronis-Appliance direkt auf einen zweiten Sicherungsort klappt dabei leider nicht, da die Wechsel-HDD nicht freigegeben ist. Daher auch meine Anfrage.

Hi Volker,

The fact that there are some backup/replication tasks are running can be checked via "top" or "ps | grep /bin/demon" commands from appliance command line (you can check how to switch to command line and enable SCP in troubleshooting section of http://kb.acronis.com/content/36100 article). I'm thinking of some script which connects via SCP to appliance (see the same 36100 article) and checks the presense of the started /bin/demon process. Depending on it the decision is made when to copy.

Note also that you can actually download the .tib files from the localy attached storage - it is mounted on appliance under /mnt/local_storage/ folder and you can check the files there (and download through SCP). Probably this would be a more elegant solution than copying entire .vmdk.

Thank you.
--
Best regards,
Vasily
Acronis vmProtect Program Manager

Hi Vasily,

perfekt, mit SSH komm ich hier weiter. Wo muss ich den Autostart von SSH eintragen, damit beim Neustart der Acronis-Appliance ssh automatisch mitgestartet wird UND im vmProtect-Konfigurations-Export (configuration_of_IP_Date.vmpcon) dieser automatische Start mit enthalten ist?

Hi Volker,

The '/bin/sshd' command can be added into /bin/autostart script on appliance side - this script starts the required services, so SSH access will be automatically enabled each time appliance is restarted. However this change won't be reflected in the configuration export (via Export/Import configuration feature) - it doesn't track the /bin/autostart file.

Thank you.
--
Best regards,
Vasily
Acronis vmProtect Program Manager

Alles klar, ich hab das Ende der autostart um den Zweizeiler für ssh (übernommen aus start portmap...) erweitert und es geht :-)

#start portmap and nfs service
echo "$procs" | grep -q portmap || /usr/bin/portmap

#web-server related startup
#web server is started by /bin/product himself
echo "$procs" | grep -q wcs || /bin/wcs &

#start ssh
echo "$procs" | grep -q sshd || /bin/sshd

if grep -q quiet /proc/cmdline; then
if [ -f /etc/customstart.sh ]; then
. /etc/customstart.sh
else
exec $1
fi
fi

Schade das es da keine Möglichkeit gibt, per Zusatzdatei solche Einträge zu schreiben, diese könnte dann auch mittels Konfig-Export gesichert werden. Na jetzt stehts ja hier im Forum, da kann ich es beim nächsten Update hier wieder raus kopieren (und jeder andere der es braucht)

Eventuell wäre es auch möglich das SSH in der Weboberfläche unter Konfiguration dauerhaft ein- und ausschaltbar zu machen, dann kann es mit gesichert werden und es ist einfacher für externe Scripte bei Versionssprüngen weiterzuarbeiten...

Mir scheint so, als wenn die Deduplizierungs-Table, welche in den RAM geladen wird, eine bestimmte Größe nicht übersteigt. Insbesondere daher, weil mir so vorkommt, das bei meiner Menge der Datensicherung die Deduplizierung nicht mehr so stark wirkt.
Jetzt ist ja die Default-Einstellung der Acronis-Appliance in Bezug auf RAM nicht so stark belegt. Ich habe meiner Appliance 30GB-RAM zugewiesen. Dieser wird zwecks Komprimierung auch gut ausgelastet.
Sollte es eine Obergrenze der Deduplizierungs-Table geben, wäre es möglich, diese anhand der verfügbaren RAM-Größe nach oben zu öffnen?
Größere Deduplizierungs-Table im RAM = bessere UND schnellere Komprimierung!!!

Hi Volker,

It actually doesn't make sense to add such huge amount of RAM to appliance as it won't affect the deduplication effectiveness. The required RAM size depends on the amount of recovery points which are analyzed during deduplication process which is done on archive level, so it depends on the number of VMs you back up into the same archive. The deduplication is most effective when you back up similar VMs (with similar file system/OS inside), but the effectiveness doesn't depend on RAM size.

Thank you.
--
Best regards,
Vasily
Acronis vmProtect Program Manager

Ich hab das System nun eine Weile im Einsatz und den Eindruck, als ob das GVS-Bereinigungsschema der Recovery-Punkte nicht richtig funktioniert.

Ich sichere zwei Sicherungstasks in ein Archiv. Die erste Sicherung fand am 6.2.14 statt

Task 1 Sicherung Mo/Di/Mi/Do/Fr/Sa - GVS 5 Tag / 2 Woche / 3 Monat
Alle VMs, die in Task 1 gesichert wurden weisen momentan die Recovery-Punkte aus: 6.2. / 18.2. / 22.2. / 24.2. / 25.2. / 26.2.
Das 5-Tage Aufheben klappt (22.2. / 24.2. / 25.2. / 26.2.)
Das 2-Woche Aufheben scheint NICHT zu klappen (hier fehlt der 11.2.)
Das 3 Monat Aufheben - kann ich noch nicht sagen...

Task 2 Sicherung So - GVS 5 Tag / 2 Woche / 3 Monat
Alle VMs, die in Task 2 gesichert wurden weisen momentan die Recovery-Punkte aus: 6.2. / 16.2. / 23.2.
Das 5-Tage Aufheben spielt hier keine Rolle
Das 2-Woche Aufheben scheint zu klappen
Das 3 Monat Aufheben - kann ich noch nicht sagen...

Warum wird bei Task 1 ausgerechnet der Dienstag aufgehoben?
Warum fehlt für Task 1 ein Eintrag aus der Woche 10.2.-16.2.?
Warum steht bei Task 2 die Sicherung vom 6.2. noch drin?
Muss das GVS-Schema bei mehreren Tasks in ein Archiv identisch sein? Oder bearbeitet jeder Task nur die VMs an, welche zu dem Task gehören?

Hi Volker,

The GFS scheme behavior depends on the type of the archive which you selected for it, but in any case it's better to contact our support team describing the GFS issue so that we can assist. So far all problems that we saw reported regarding the GFS scheme appeared to be expected behavior, i.e. we've not submitted any bugs on it yet. It's a pretty complicated scheme so some "missing" recovery points typically have logic explanation, but it needs to be analyzed first of course.

Thank you.
--
Best regards,
Vasily
Acronis vmProtect Program Manager

Any updates on new findings here yet? I was wondering if there were new ones.

Hallo Vasily,

ich habe nun einen größeren Storage zum Sichern. Ich habe über vsphere der Accronis-Appliance 4TB als Festplatte zur Verfügung gestellt. Wenn ich die Appliance gestartet habe, wird mir die 4TB-Platte als Sicherungsplatte zum Einrichten angeboten. Nachdem ich diese ausgewählt habe, sie mir dort auch mit 4TB angezeigt wird und sie zum Sichern bestimmt habe, wird mir die Platte kurze Zeit später in der Weboberfläche nur mit 2TB angezeigt. Ein kurzer Blick per ssh auf die Console ergab: "/dev/sdc1 on /mnt/local_storages/D: type ext2 (rw,relatime,errors=continue)"
ext2 kann doch nur 2TB zur Verfügung stellen - sprich die restlichen 2TB sind nicht verfügbar :-(
Ein weiterer Blick in die Console:
"mkfs.btrfs" ergab, das Sie doch andere Filesysteme zur Verfügung haben, um auch größere HDDs zu verwalten.
Wie kann ich nun 4TB zum Sichern auf der einen Platte nutzen?

Vor der Bereitstellung sieht die Console so aus - obwohl die Platte 4TB hat!!!:
Disk /dev/sdc: 2199.0 GB, 2199023255040 bytes
64 heads, 32 sectors/track, 2097151 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes

Disk /dev/sdc doesn't contain a valid partition table

Da scheint doch auch etwas nicht stimmig zu sein? In der Console0-GUI wird mir beim ersten Bereitstellen die Platte definitiv mit 4TB angezeigt, nur nach dem Formatieren sind nur noch 2TB übrig :-/

Hi Volker,

The current version of Acronis Backup for VMware supports only MBR disks for local attached storage which therefore means that the maximum size of the locally attached storage is 2TB and any size beyond this boundary will be ignored. We are adding support for GPT disks (internal ticket ID: ABV-2636) in the next version of Acronis Backup for VMware (this support is alreade added in Advanced edition in the latest update). This new version will be launched as Beta in the nearest months and we target the final release by the end of the year. Until then the workaround is to create 2x2TB disks and attach both of them to the virtual appliance to use as locally attached storage. Another workaround is to attach the entire 4TB disk to some Windows VM and install Acronis Backup for VMware Windows Agent on it (so it will be backing up to local 4TB disk).

Thank you.
--
Best regards,
Vasily
Acronis Virtualization Program Manager

Hi Vasili,

ich habe jetzt 2x 2TB-Platten eingefügt - das klappt. Jetzt hat es jedoch beim (wieder) ersten Backup Fehler erzeugt und abgebrochen.
Diese lauten:
1. und 2. Fehler:
Interner Recovery Fehler: 458,791.

3. Fehler:
Die Aktion 'Validierend' ist fehlgeschlagen.
Zusätzliche Info:
--------------------
Fehlercode: 26
Module: 100
Zeileninfo: 48afbd3608a410ca
Felder:
Nachricht: Die Aktion 'Validierend' ist fehlgeschlagen.
--------------------
Fehlercode: 1080
Module: 1
Zeileninfo: 145a191bfe9050d1
Felder:
Nachricht: Ausführen der Aktion fehlgeschlagen.
--------------------
Fehlercode: 1080
Module: 1
Zeileninfo: ccb580038dbe2e93
Felder:
Nachricht: Vorbereiten der Aktion 'Archiv überprüfen' ist fehlgeschlagen.

4. Fehler:

Task 'Wichtige VMs' fehlgeschlagen: 'Erstellen eines Backups fehlgeschlagen.
Zusätzliche Info:
--------------------
Fehlercode: 3
Module: 435
Zeileninfo: 555b5abba0950340
Felder:
Nachricht: Erstellen eines Backups fehlgeschlagen.
--------------------
Fehlercode: 32786
Module: 114
Zeileninfo: 28314c961de7d337
Felder:
Nachricht: Vorbereitung auf das Backup fehlgeschlagen.
--------------------
Fehlercode: 353
Module: 149
Zeileninfo: a71592046cb2c5f6
Felder:
Nachricht: Backup der Gruppe fehlgeschlagen.
--------------------
Fehlercode: 2
Module: 218
Zeileninfo: 338a407ad20e0987
Felder:
Nachricht: Fehler während Ausführung der Backup- und Recovery-Engine aufgetreten.
--------------------
Fehlercode: 1080
Module: 1
Zeileninfo: 145a191bfe9050d1
Felder:
Nachricht: Ausführen der Aktion fehlgeschlagen.
--------------------
Fehlercode: 1080
Module: 1
Zeileninfo: ccb580038dbe2e93
Felder:
Nachricht: Vorbereiten der Aktion 'Archiv überprüfen' ist fehlgeschlagen.
--------------------'.

Zum letzten Fehler die erweiterten Informationen:
Plattformtyp linux
Plattform-Architektur unknown
Kernel-Version der Plattform 3.15.0
Produktname vmProtect
Produktversion 9.2
Produkt-Build 10535
Produktsprache de_DE
Ereignistyp error
Ereigniscode 0x01B30003+0x00728012+0x00950161+0x00DA0002+0x00010438+0x00010438

Zu diesem Ereigniscode gibt es keine Informationen seitens Acronis - was kann ich tun?
Auch das Archiv ist zwar belegt, aber der Inhalt ist nicht zu sehen - siehe Bild.

Hi Volker,

The "Interner Recovery Fehler: 458,791." is a very low level one - it usually indicates hardware or file-system consistency problems with the backup storage and this is the cause of the archive validation failure (and the fact that recovery points list is empty). To check it you can detach this particular disk from the appliance, then attach it to some other system and run validation (fsck) of the disk file system (it is "ext4" Linux FS). Other than that the only viable option is to re-format this particular disk.

Thank you.
--
Best regards,
Vasily
Acronis Virtualization Program Manager

Hallo Vasily,

du hattest geschrieben "The current version of Acronis Backup for VMware supports only MBR disks for local attached storage which therefore means that the maximum size of the locally attached storage is 2TB and any size beyond this boundary will be ignored. We are adding support for GPT disks (internal ticket ID: ABV-2636) in the next version of Acronis Backup for VMware".

Gibt es schon einen Zeitplan wann ich Sicherungsplatten größer 2TB in Einsatz bringen kann?

Und eine weitere Frage: Das Acronis kann die VCenter-VM nicht sichern - es bricht immer ab - woran liegts - siehe log?

Ausführen der angeforderten Aktion fehlgeschlagen.
Zusätzliche Info:
--------------------
Fehlercode: 13
Module: 149
Zeileninfo: d1ab7fa1e56eca4e
Felder:
Nachricht: Ausführen der angeforderten Aktion fehlgeschlagen.
--------------------
Fehlercode: 103
Module: 83
Zeileninfo: a859dd78cc91df40
Felder:
Nachricht: Öffnen der virtuellen Maschine fehlgeschlagen ([HDD Datastore] VMWare VCenter/VMWare VCenter.vmx).
--------------------
Fehlercode: 253
Module: 83
Zeileninfo: c7610e0a857bedf4
Felder:
Nachricht: VMware-Fehler: 'Remote-Methodenaufruf ist fehlgeschlagen.'.
--------------------
Fehlercode: 32
Module: 0
Zeileninfo: c7610e0a857bedf4
Felder:
Nachricht: Erwarteter Task 'CreateSnapshot' fehlgeschlagen. Ursache: Fehler beim Speichern des Snapshots: Das Stilllegen der virtuellen Maschine ist fehlgeschlagen..

Hi Volker,

Concerning the 2TB limitation for locally attached storages - it will be removed in the next version of Acronis Backup for VMware which is coming this year.

The error you quote is coming from an attempt to create quiesced snapshot of the vCenter appliance machine. You should try to create the snapshot of this VM manually from vSphere client (with quiesced=on, memory=off parameters), and continue troubleshooting from there. See http://kb.acronis.com/content/4559 article.

Thank you.

--

Best regards,

Vasily

Acronis Virtualization Program Manager