Backing up is very easy with Virtualmin 3.82 GPL. But I have some problems with the restore.
I backed up a few domains using the option “one file per server” and ssh. This basically creates a directory with a few domainname.tar.gz and domainname.tar.gz.info files. Total roughly 1GB
Now I want to restore all virtual servers (using the same ssh server and the backup directory). When I click on “show what will restored button” virtualmin quickly finds all virtual servers and lists them, but without any features and consequently no “restore button”.
So I tried the following, I deleted all info files and repeated the whole procedure, and this time the restore works. However it is kind of slow, because virtual downloads everything twice (“at each button click”).
Why do I have to delete the info files to make it work? And does it really have to download the everything to show can be restored?
Why do I have to delete the info files to make it work?
That’s a fine question! I’ve never heard of that happening before. It’s possible something got corrupted along the way.
And does it really have to download the everything to show can be restored?
Yeah, it does a lot of checking on the backups before offering what can be restored. One option might be to copy the backups locally first, which may speed things up.
However, even locally, that can take a little while.
I’ll mention it to Jamie and see if there’s a more efficient way to do all that.
If I had to guess the purpose of these info files, I would say these describe the features of each server, to enable some kind of quick lookup (to avoid downloading the whole backup).
I think this is actually also a pretty new feature? So this sounds like it could be a bug actually?
I suspect that the restore functionality with the new format has not been well tested by many users (good for them
I think this is actually also a pretty new feature? So this sounds like it could be a bug actually?
Well, the problem with naming anything “new” is that the term is relative
It’s actually been in place a few years now, and I hadn’t heard of folks having the trouble you’re having. It’s been the default format throughout that time.
However, if you’re consistently seeing problems with restores such as what you described above, you may want to file a bug report.
If you do file a report – I’m sure Jamie would love to see a copy of a non-functioning backup
I believe the backup is functioning very well. The problem is restoring from a backup directory that contains info files created only for SSH or FTP destinations. The workaround is to delete these info files, but then you lose the performance gain. But as you said already, this can be handled by copying the remote file to a local folder.
Thanks again for responding.
I think the problem is not important enough to file a bug report, since a workaround exists.
I just checked my backups, and they do not have “info” files. Is that maybe because I use “local file or directory” mode?
In fact though, that “local directory” is not really local, but a CIFS mount from a backup server. So if creation of “info” is omitted cause it’s considered local - you might reconsider and make that a checkbox.
