Winclone 8.0.1 Stuck at Archiving file data

Another version, same old childhood diseases :wink:

I had the very same issue when I jumped on board with Winclone 6 and then 7.

After creating an image from a 100GB Bootcamp partition (65GB occupied) under Catalina 10.15.1, the backup finished quite quickly, but the Archiving file data step has been stuck at about 5% for 2hrs now.

If I cancel out of it here, will the backup still be valid?

How do I get this to work properly, and what can I do to help you troubleshoot this?
I have come to rely on this excellent piece of software, so I hope that this can be resolved quickly.

Also, where is Incremental Backup? I enabled it in Preferences, but can’t find it.

When I enable Block-Based imaging in Preferences, the backup actually finishes (or so it claims), but upon looking at the generated .winclone archive file, it is only 688 bytes in size.

Not very confidence instilling. Still seems like a work in progress to me.

Hope this can get resolved quickly :-/

5 days later and no attempts to figure this out?

Could someone from twocanoes please chime in here?

It is probably an issue with the Finder showing the incorrect file size for a bundle. Try control clicking on the image and select show package contents and look at the size of the boot.img.gz.

Thanks for chiming in, tperfitt, but no, that’s definitely not it…and why would that be the case with Finder showing me the right sizes of every other archive and CCC backup I have ever generated.

The Winclone archive shows 49KB in Finder.

Where am I to look for boot.img.gz?

Also, where do I find the Incremental Backup feature?

I found the boot.img.gz file inside of the .winclone archive…it shows 13.57GB.

So what makes the .winclone archive inherently different in such a way that it would report the incorrect file size to Finder?

And can this backup be trusted or not? Since I have been waiting to wipe out my drive and restore both the APFS System container and the Bootcamp partition, I don’t want to find later that all the hours of setting up my Bootcamp environment have been in vain.

And why do all of the .winclone archives that I generated with the last (7.x) versions of Winclone report the correct sizes?

And Winclone crashes, every time, when checking for updates while the Create Image from Volume dialog window is open.

No offence, but this is exactly what happened after v7 was released, and it took until well into the 7.2.x cycle until I was able to rely on Winclone 7.

If you remember, you even sent me the 7.2 beta to see whether it would resolve some of my issues. I love Winclone, what it does and how it does it, but I can’t afford to lose many hours of work with Bootcamp (which is plenty finicky in and of itself, as it is) with backups that may or may not work.

Where do I start a new ticket for this version’s issues, so that I am not wasting space here on the Forum with all of this?

“Show Incremental Imaging Menu item” in Preferences has no effect on my end.

If I do not check “Use Block-Based Imaging…” in Preferences, the archiving process will stall at “Archiving file data” every time.

If I do * check “Use Block-Based Imaging…” in Preferences, Winclone will generate an archive that reports a file size of less the 100KB, but contains files amounting to greater than 13GB, but much less than the size of the Bootcamp data.

So in essence, as it is, Winclone is unusable in its current state, at least for me.

Could other users chime in and maybe report their success or failure with any of these things I mentioned? I mean, maybe it is just me, but how would I know?

Is anyone making Incremental backups with Winclone 8.0.1, and if so, how?

Is anyone successfully making regular WIM backups, and if so, on what macOS version? Could this be a Catalina 10.15.1 only issue?

If anyone could take a minute to confirm any of this, then I would at least know that there is something funky going on with my system, and start troubleshooting from there.

Thanks in advance for your input!

Quick update: I started another WIM Archive of my Bootcamp partition, and what I thought to be a stall before is actually just a reeeealllly slow moving progress bar. I started this backup of a 100GB Bootcamp partition that has about 60GB of data on it at 9:02pm, and it is now 9:42pm…the progress bar is at 9.6% (let’s be generous and call it 10% for ease of math), so at this rate those 60GB would take about 6hrs…when my Windows system is fully configured with all the software and supporting data that I use and need, it typically comes in at about 250-300GB, so then we’d be talking about 25-30hrs for a full backup…incrementals would be much less, of course, but why would the first backup of 60GB take 6hrs? Carbon Copy Cloner backs that amount of data up in about 10-15mins.

What’s going on here?

A lot of information here so let me know if I miss anything:

  1. The Finder bug seems to be triggered if you “Get Info” on the image (bundle) while it is running. If you make a copy of the image after it has completed, the new image will have the correct size. Were you doing a “Get Info” while the image was running?

  2. Speed: Winclone has 2 different modes: block-based and file-based. file-based was introduced due to Apple’s SSD having a different physical block size on more recent Macs. If block-based imaging is used, the NTFS catalog has the old block size and references to files on the filesystem are off. We switched to WIM-based images, but that was a lot slower on non-SSD drivers. We now prompt if you have a non-SSD to see if you want to switch to block-based imaging. It was a tradeoff but works well for most applications. Hope that explanation helps. (WIM-based imaging also enabled us to do incremental imaging).

  3. You can see exactly what is going on by opening the log prior to creating the image.

tim

When I woke up this morning, the WIM-based backup had finished after about 7hrs, which is totally unacceptable for 60GB of data, any which way I look at it. I am backing up to an Apple SSD (MBP 2018) which is capable of read/write rates of 3GB/sec, although I know that tasks like this will always come in far below that…but 8GB per hour seems ludicrously slow.

I was getting the same results whether I did Get Info while the process was running and after it was finished. This last backup shows exactly the same size of what is inside, which is the same 13.76GB that I see from a previous backup that shows 688 bytes in Finder, but has 13.76GB in its package. That can also not be right as I added about 30GB of software and data to it between the two. So it can not be trusted.

For one, I still can’t find the incremental imaging UI anywhere…could you give me a step-by-step to enable and use it? Is there a help file you can link to?

Also, how do I start a new ticket with these issues, so that I won’t bore anyone here in the forum…the interest from the community to chime in is at 0% anyway, so let’s please take this into a private exchange in form of a support ticket.

So what now? The archives are obviously incomplete but I need to make a proper backup of my Bootcamp partition that I can rely on 100%.

Btw, is Winclone 7.x not compatible with Catalina 10.15.1? Maybe it would serve me better until the kinks have been worked out in v.8.x?

EDIT: Just tried it, no. It immediately alerts that it supports 10.14 only.

When I woke up this morning, the WIM-based backup had finished after about 7hrs, which is totally unacceptable for 60GB of data, any which way I look at it. I am backing up to an Apple SSD (MBP 2018) which is capable of read/write rates of 3GB/sec, although I know that tasks like this will always come in far below that…but 8GB per hour seems ludicrously slow.

I agree. I did a 2013 MacBook Pro with boot camp partition last night that had a Boot Camp partition that used 59GB and it took about 5 minutes. Something else is going on here. Time Machine, antivirus, security software?

When you say " I am backing up to an Apple SSD" can you explain a bit more how you are saving the image?

That can also not be right as I added about 30GB of software and data to it between the two. So it can not be trusted.
The image itself is compressed, and the swap files and hibernate files are not saved so those sizes do not seem unreasonable to me. When I do a spot check, I restore to a disk image and look at total amount used in the restored disk image. That should match for the used files, minus the swap+hibernate.

Also, the only true way to trust any backup is to restore and test the restoration. I understand this is hard when you have a single machine. We recommend having at least 2 different ways to back up critical data. Winclone is great for snapping back to specific time or for migrating, but is less so for restoring individual files. It saves time for not having to reinstall Windows and all your apps, and user data, but should be used in conjunction with other backups.

For one, I still can’t find the incremental imaging UI anywhere…could you give me a step-by-step to enable and use it? Is there a help file you can link to?
It is now enabled in the preferences:
image
http://twocanoes.com/knowledge-base/incremental-imaging-winclone-8/

tim

Aha! Thanks Tim…I wasn’t aware of the small menu item up there where that is configured…got it!

my fault, in this case I was actually backing up to my externally connected USB3 SATA drive…but even so, it shouldn’t be that slow, right?

Not at all. I saved to an external Samsumg USB-C drive and it was like 5 minutes for a 60 GB winclone partition.

Yes, I am well aware of and practice a very stringent backup strategy, but currently (where I am) only have access to this one MBP 2018, with no realistic way to restore this Winclone image to anything else.

No Time Machine, AntiVirus, or Security services are active either.

Just heard back from someone on your end who saw the ticket I opened. For now I’ll try to continue with her about this. Thanks again, Tim!

1 Like

Hi tillkrueger, did you manage to figure out how to fix this? I’m having the same issue updating my Winclone image (archiving file data gets stuck at 5% for a long time, then stops logging anything).

Been looking around, but this is the only place I’ve found that mentions this issue.

The issue was that it was not a GUID partitioned disk. Not sure if that applies to your issue.

tim