Antwise community forums
Feature request: Check consistency before backup - Printable Version

+- Antwise community forums (https://forums.antwise.com)
+-- Forum: Vimalin (https://forums.antwise.com/forumdisplay.php?fid=4)
+--- Forum: Vimalin for Windows (https://forums.antwise.com/forumdisplay.php?fid=9)
+--- Thread: Feature request: Check consistency before backup (/showthread.php?tid=130)



Feature request: Check consistency before backup - Sontec - 2022-07-20

Hi Wil, 
I while ago, about 3 of my VM guest were broken, because a .VMDK was probably deleted by the virusscanner.
Thanks to your hint, I excluded the VmWare folders in Defender now, so this should not happen anymore. Big Grin

I have Vimalin scheduled to keep 4 backups of every Vmware, but because I was to late,
all good backups were overwritten by bad ones.

To overcome this in the future, I want to ask for the following feature:
Could you check before the backup starts, if the Vmware is consistent (e.g. no missing files, and should be in "running" state)

Also this just came to mind, would you also consider adding a configuration switch to ONLY backup,
the Vmware when it is running ?
Just doing the restores rightnow, I see Vimalin kept backing up the Vmware guests, though they were not running.
So my "good" backups were overwritten by "bad" once.

I hope you will consider the above requests. Smile


RE: Feture request: Check consistency before backup - wila - 2022-07-20

Hi Sontec,

Ouch!

Your requests make sense, but how about the following instead?

What if Vimalin would skip a backup in the case that the VM has not changed?

The exception being if you are running a backup to another backup location.

If I'm not mistaken then that would take care of both requests and also has the added benefit of not having multiple identical backups taking up disk space.

--
Wil


RE: Feture request: Check consistency before backup - Sontec - 2022-07-20

(2022-07-20, 12:58:57)wila Wrote: Hi Sontec,

Ouch!

Your requests make sense, but how about the following instead?

What if Vimalin would skip a backup in the case that the VM has not changed?

The exception being if you are running a backup to another backup location.

If I'm not mistaken then that would take care of both requests and also has the added benefit of not having multiple identical backups taking up disk space.

--
Wil

Hi Wil,
That seems like a good solution, however when would you consider a VM not changed ?
If I, try starting the Vmware and it errors out, would that be a change ?
Opening the VMX-file to lookup settings or trying to fix an error, would that be a change ?
Are you thinking of creating a CRC-check for each VM file ?

As an extra thought: is it possible to backup the guest with a certain "keep time"?
E.g. Keep last 7 days, last month, last 6 months, last year...

Best regards, Martijn

Sorry for making a mess of this topic. While restoring a backup, is it possible to stop the restore ?
Just "restored" the wrong backup and had to wait *30 minutes* until the restore was ready to start the restore I intended ;-)

Martijn


RE: Feture request: Check consistency before backup - wila - 2022-07-20

Martijn,

Thank you.

We're already keeping MD5 hashes of each file.
It's an important part of Vimalin to determine if the backup is correct when restoring it.
If one of the MD5 hashes does not match the hash made during the backup then Vimalin will report that the file has changed (but still continue the restore)

In the solution I'm suggesting above we're only going to look at virtual disk and configuration of the VM.
So at most there would be one backup of the broken VM. Note that the broken VM might still have additional data that you might want to recover,  so I think it still makes sense to have a backup you can fall back on.
I made a note however that to test that it should never make more than one backup for this particular scenario.

FWIW, I have also opened a ticket for the consistency check (the a disk slice is missing issue) to see what can be done and investigate what the best course of action would be.


--
Wil