Request Vimalin multiple target disks - 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: Request Vimalin multiple target disks (/showthread.php?tid=183) |
Request Vimalin multiple target disks - Sontec - 2024-01-30 Hi Wil, Recently some of our servers were infected. For the most important servers we luckilly had Vimalin backups, however I noticed that restoring e.g. a 500GB and a 900GB virtual machine from normal harddisk takes a long time Nowadays my VMs are running from NVMe RAID with a Vimalin backup to a big harddisk. Would you consider extending Vimalin with a way to backup/restore from a fast disk? I would like Vimalin to first backup to a fast disk e.g. NvME or SSD and afterwards copy it to a "slow" HDD. I could then add a 4TB disk as go between, so Vimalin would backup faster. Preferable the fast between disk would keep the last x backups (next to them being on the big harddisk). This way backup would be fast, but more important if I want to restore a recent backup, it would be faster than the 100-150MB/s I recently experienced RE: Request Vimalin multiple target disks - wila - 2024-01-31 Hi Sontec, Not sure I am understanding your request correctly. You can have multiple backup targets right now. Each backup schedule that you setup can have its own backup target assigned. -- Wil RE: Request Vimalin multiple target disks - Sontec - 2024-01-31 My setup is now as following:
Vimalin backups the VMs to the 10 TB "normal" disk. E.g. the backup to the harddisk takes 120 minutes. If I add another 4TB SSD (2,5") to my setup, the Vimalin backup might take +/- 30 minutes. This will have less impact on my system and restoring a backup will also be about 90 minutes faster. However maximum SSD sizes right now is 8TB (and € 1000) or anout € 300 for a 4 TB SSD. So instead of replacing my 10 TB harddisk, I rather have the backup done to the fast SSD and later on replicated to the harddisk. Now if I need the restore of a recent backup (e.g. the last 4 backups), I could just restore from the SSD. If I need an older backup, I have to restore it from the slower harddisk. Does the above make more sense ? If not, I could just call you to explain RE: Request Vimalin multiple target disks - wila - 2024-02-01 Sure I get it. Cloning the backup automatically to another disk target currently isn't supported. There's a request outstanding to add scripting support. So that you can automatically run a script after the backup process completes. Once that is implemented, it could be used for these type of things. Sadly not there yet and atm we're in the middle of a data center move, so currently no time for adding anything like that. Once things calm down again I can set some time apart to look at this. -- Wil RE: Request Vimalin multiple target disks - Sontec - 2024-02-02 Hi Wil, I could write my own script to copy the backup from Vimalin to another disk. However, if I have set Vimalin to do weekly backups to the SSD with a max of 4 (due to storage restrains), and copy those backup to a harddisk with e.g. room for 10 historic backups, am I going to get in problem with Vimalins versioning folders? Also how would I get Vimalin to acknowledge the backup at the other location, so I could restore it from within Vimalin ? Best regards, Martijn. RE: Request Vimalin multiple target disks - wila - 2024-02-02 Hi Martijn, You're getting a ahead of things now, the feature does not yet exist. Vimalin can import backups, although I'm sure it will need some extra work to make this easier / more flexible. Thanks for the suggestion. -- Wil RE: Request Vimalin multiple target disks - Sontec - 2024-02-02 Hi Wil, Programming my own workaround (until the featuure could/would be implemented), I will need adhere to the Vimalin folder versioning. Also not wanting to restore manually, I would have to find a way to add the "move/copied" backup to Vimalin. I was just enumerating the problems I would encounter if I created my own move script. Naturally, if in the future you would implement my feature request, you will probably have the same challenges |