Image Backup
Hello,
I had this only a few days and why does it seem that the image backup process is not only taking far too long the backup size is huge? I was under the impression that it only backed up used space? This can't be the case, since I'm only using ~350GB of a 1TB hdd. I had checked it this morning and it said it had backed up ~700GB+ and still had a day to go, note this is the same for "Entire PC" and/or partition type backups. I'm running 16GB ram and an AMD Ryzen 1300x. What am I missing?
Hello,
Thank you for getting back to me regarding this. The selected disks were the same drive just different partitions EFI & "C". The speed is another thing and the FTP server is in my localnet on a Centos 7 server I run. My biggest concern is the overall size of the backup which appears to 2x+ the actual size of used disk space. This is the case whether I choose "Entire PC" or "Disks", which makes me think it's trying to backup all sectors and not used space only. I did not nor do I have the sector backup or related setting set within the image backup section/setting.
Jonathan, please download the MVP Log Viewer tool (link below) and use this to look at the log for your backup task then post a copy of the log here for us to review with you.
How many disk drives are actually connected to the source computer here?
Steve,
I've attached two different logs and an image of my disks. Note that I did kill the process since I'm not waiting 2days for a backup of ~350GB to complete. I've used alternative software "urbackup" and others and they worked quickly I just always liked Acronis back in the day so figured I'd buy it again and give it a shot. I appreciate the continued assistance and merry Christmas!
Jonathan,
The logs you posted show that errors are occurring during the file creation process. In response the application is retrying the write process. I also note that it appears that long time spans are taken between the file splitting that occurs when using FTP due to a 2GB maximum file size limit. The log shows 3 hours between each file creation time!
This is clearly not normal. There are probably a number of reasons for this problem. Given that other transfers work good for you I would rule out anything network related.
In my way of thinking I would suspect possible disk corruption of the source disk. If you attempt a backup of only the C: partition on the disk do you see the same behavior? If yes run chkdsk /r on the C: partition if your source disk is an HDD, chkdsk /f if an SSD, and see if any errors are found and corrected. If yes, attempt the backup again.
If the C: partition comes up clean then corruption may exist on the other disk partitions. Chkdsk run on those partitions would then be appropriate.
Check out the How-To article in my signature link below entitled "Fix Disk Corruption" for an in depth on using Windows chkdsk.
If those attempts fail then opening a support case with Acronis on the issue would be advised. If that become necessary please reference this thread when you do.
Jonathan, in your initial post you wrote "I'm only using ~350GB of a 1TB hdd" and then later, "The selected disks were the same drive just different partitions EFI & "C". "
Your latest screen image shows as if there are 2 physical disk drives of the same type, each being 1TB in size, and your My disks log file shows:
Create Backup Archive Password Protected From: Disk 1; Disk 2 To file: ftp://linda058:21/My disks.tib
which again suggests 2 separate disk drives?
I have never seen a single drive which is partitioned as you suggest above showing in this way as 2 separate disks.
The second log looks to be for a different backup task given the information shown:
Create Backup Archive From: To file: ftp://linda058:21/SKD.tib
This doesn't say what the actual backup source involved is here? This second task looks to have encountered some issues when writing to your remote FTP location and doing retries for this.
14/12/2018 03:03:23 :679 Writing full version to file: SKD_full_b1_s1_v84.tib
14/12/2018 03:06:27 :141 Error 0x40003: Error occurred while writing the file.
14/12/2018 03:06:57 :141 Error 0x40003: Reattempting the operation. Error: Error occurred while writing the file..
The first backup task was terminated by yourself as shown in the log.
15/12/2018 11:44:51 :455 Writing full version to file: My disks_full_b1_s1_v362.tib
15/12/2018 11:46:24 :037 Terminated by user.
I would recommend clicking on Full partition list on the Source selection panel for where you captured the screen image showing the 2 disks, and check that this does not also include any other hidden / system partitions that are also selected.
I've already defrag'd and ran chkdsk before attempting these backups. One of the files is for the "Entire PC" and the log is for the "disks", that image is all disk/partitions full list. Technically speaking I do have two disks in the machine, just the second one is running Ubuntu so I figured it wouldn't detect it since its EXT4 but I suppose I'm wrong. If it is detecting it does that mean while trying to perform an "Entire PC" backup it would try to back this up too? I haven't tried just doing the "C" partition(s)/disk. These shouldn't be any networking issues, but machines, this windows & my CentOS 7 server are both local and 1GB throughout the network. I'm able to connect and upload/download from the FTP server fine. But I'll double check my settings again there. Enchantech I must be blind where are you seeing this long time for splitting?
One of the files is for the "Entire PC" and the log is for the "disks", that image is all disk/partitions full list. Technically speaking I do have two disks in the machine, just the second one is running Ubuntu so I figured it wouldn't detect it since its EXT4 but I suppose I'm wrong. If it is detecting it does that mean while trying to perform an "Entire PC" backup it would try to back this up too?
Entire PC means exactly that - so it will backup both your disks, including the EXT4 partition(s)!
Johnathan,
In the below image I have encircled the time between backup file splits. The first file write began at 17:16:48 or 5:16 and 48 seconds. The next began at 17:20:09 or 5:20 and 9 seconds. Over 3 minutes to write just under 2GB of data, 2000MB divided by 183 seconds = 10.93MBps. That's terrible!
Hello,
Thank you for pointing that out. Well, I was able to deduce my disk space by 200GB so backed up ~140GB last night (only C & EFI not ext4). Log attached, it took ~4hr but half of that was the validation process. I did and do have compression on maximum and priority set to high compress wise, I'm sure it adds to some overhead. My desktop is 1G NIC I thought my server was as well, but I'm showing only 100M which I believe may be the bottleneck. The server's HDD that I'm putting the backup on via FTP seems to write quick enough for 7200 HDD although this disk is very lightly used only a few docker containers (data wise) on it at the moment and using it for backups since it's my largest at 4TB. I use this server a lot mainly for MediaServer content Plex. The MOBO is to handle 1G nic but not sure why its set at 100Mb so I'll have to check into that.
[root@linda058 15:25 ~]$ ethtool enp3s0 | egrep -i "speed|duplex"
Speed: 100Mb/s
Duplex: Full
[root@linda058 15:16 ~]$ time dd if=/dev/zero of=/data2/test1.img bs=2G count=1 oflag=dsync
0+1 records in
0+1 records out
2147479552 bytes (2.1 GB) copied, 13.7489 s, 156 MB/s
real 0m14.071s
user 0m0.000s
sys 0m6.243s
At any rate I think I got what I need thank you all very much again for the help greatly appreciated!!
Hello,
Don't think my last comment got posted. Thank you very much for pointing that out. I believe the bottleneck is the server's NIC it should be 1G but is showing/running at 100MB at the moment so I'll have to investigate that when I can soon. The Seagate 7200rpm hdd seems to write quickly enough. I was able to remove ~200GB and backup ~140GB took about 4 hours, but half of that was validation log attached.
[root@linda058 15:25 ~]$ ethtool enp3s0 | egrep -i "speed|duplex"
Speed: 100Mb/s
Duplex: Full
[root@linda058 15:16 ~]$ time dd if=/dev/zero of=/data2/test1.img bs=2G count=1 oflag=dsync
0+1 records in
0+1 records out
2147479552 bytes (2.1 GB) copied, 13.7489 s, 156 MB/s
real 0m14.071s
user 0m0.000s
sys 0m6.243s
At any rate, I believe I got what I needed to thank you all again for the help, greatly appreciated!!!
Steve Smith wrote:... FTP backups are also split into 2GB file segments due to the limitations of the protocol.
Off topic for this thread, but ...
Steve, that 2GB limit is due to the Acronis implementation of the FTP client, not a restriction of the FTP protocol. Many FTP clients and servers do not have any limit on file size. The FTP protocol does have a 32 bit sequence number but it wraps so does not limit file size. It's an error recovery nightmare if an acknowledgement is delayed and shows up after the sequence number has wrapped but many clients and servers accept that risk.