Re: qemu-kvm VM died during partial raid1 problems of btrfs

["Austin S. Hemmelgarn" <ahferroin7@gmail.com>]

On 2017-09-13 10:47, Martin Raiber wrote:
> Hi,
> 
> On 12.09.2017 23:13 Adam Borowski wrote:
>> On Tue, Sep 12, 2017 at 04:12:32PM -0400, Austin S. Hemmelgarn wrote:
>>> On 2017-09-12 16:00, Adam Borowski wrote:
>>>> Noted.  Both Marat's and my use cases, though, involve VMs that are off most
>>>> of the time, and at least for me, turned on only to test something.
>>>> Touching mtime makes rsync run again, and it's freaking _slow_: worse than
>>>> 40 minutes for a 40GB VM (source:SSD target:deduped HDD).
>>> 40 minutes for 40GB is insanely slow (that's just short of 18 MB/s) if
>>> you're going direct to a hard drive.  I get better performance than that on
>>> my somewhat pathetic NUC based storage cluster (I get roughly 20 MB/s there,
>>> but it's for archival storage so I don't really care).  I'm actually curious
>>> what the exact rsync command you are using is (you can obviously redact
>>> paths as you see fit), as the only way I can think of that it should be that
>>> slow is if you're using both --checksum (but if you're using this, you can
>>> tell rsync to skip the mtime check, and that issue goes away) and --inplace,
>>> _and_ your HDD is slow to begin with.
>> rsync -axX --delete --inplace --numeric-ids /mnt/btr1/qemu/ mordor:$BASE/qemu
>> The target is single, compress=zlib SAMSUNG HD204UI, 34976 hours old but
>> with nothing notable on SMART, in a Qnap 253a, kernel 4.9.
>>
>> Both source and target are btrfs, but here switching to send|receive
>> wouldn't give much as this particular guest is Win10 Insider Edition --
>> a thingy that shows what the folks from Redmond have cooked up, with roughly
>> weekly updates to the tune of ~10GB writes 10GB deletions (if they do
>> incremental transfers, installation still rewrites everything system).
>>
>> Lemme look a bit more, rsync performance is indeed really abysmal compared
>> to what it should be.
> 
> self promo, but consider using UrBackup (OSS software, too) instead? For
> Windows VMs I would install the client in the VM. It excludes unnessary
> stuff like e.g. page files or the shadow storage area from the image
> backups, as well and has a mode to store image backups as raw btrfs files.
> Linux VMs I'd backup as files either from the hypervisor or from in VM.
> If you want to backup big btrfs image files it can do that too, and
> faster than rsync plus it can do incremental backups with sparse files.
Even without UrBackup (I'll need to look into that actually, we're 
looking for new backup software where I work since MS has been debating 
removing File History, and the custom scripts my predecessor wrote are 
showing their 20+ year age at this point), it's usually better to just 
run the backup from inside the VM if at all possible.  You end up saving 
space, and don't waste time backing up stuff you don't need.

In this particular use case, it would also save other system resources, 
since you only need to back up the VM if something has changed, and by 
definition nothing could have changed in the VM (at least, nothing could 
have legitimately changed) if it's not running.