I'm finishing up my trial and I intend to go with CB Backup Desktop PRO.
Using Wasabi.
I have a very modest backup requirement. About 530GB of storage on a Network shared disk on a Windows 10 LAN.
The trial has backed up things to Wasabi over the past few days no problem.
But I need a larger disk moving forward, so I have just moved the data to a 2TB WD Black disk.
Now I've fired up CB Backup and
(1) It's taking over 25 minutes to figure out if there are modified files. There is not a lot of network traffic.[ Just completed in 27 min and found 4 modified files - the 4 screenshots I took for this posting.] Seems like a long time for such a small backup set. What if my business had 20 TB of files?
(2) CB Backup seems to be hitting the "C" system drive, which is an SSD pretty hard. This concerns me, since over time this will wear out the SSD. I have set the Memory Options to use the backup drive, so that's not on the SSD, but now I see that there is a Log folder and a Repository. Thankfully, as I change those, the repository is moved for me. Wouldn't it be a lot nicer to have just one thing to move/ change? How about one folder for Temp/Logs/Repository and you mange stuff in there. And for Cloudberry to just avoid using SSDs where possible by defaulting to a Spinning HARD drive for the temp data. Surely there is an OS or File system call to tell whether a disk can have Wear Issues. Don't use such a disk for temp data and other high traffic transfers unless there is no other choice.
Anything else I should watch out for as I move to CloudBerry?
Running again, outside of the Schedule Time?
I just came back to the backup computer and CB has been running for over an hour.
What Up?
The schedule clearly shows run at 12:00am for 6 hours and that has been true for a few days now.
And I just ran it after replacing the disk and it ran and STOPPED.
No new files. And now it's running and says 2% done after an hour of running.
What is up please? Seems like something fundamental I don't understand about when CB should be running. Again. CB Desktop PRO for windows on Win 10.
And look at the disk activity. What's it doing? Re hashing all the files again? 'cause I moved the repository or 'cause I copied the files to another drive? What Up?
After over 3 hours it was still running like mad. No progress. I can only conclude that it was stuck in a loop somewhere. I stopped the plan and restarted it and it started searching for modified files. Looks like a bug. Let me know what I should provide if anything to help with this. Of course the log says "Interrupted by user".
After 7 min after restarting, it's up to 9%, but never got off 2% in 3 hours. Log shows nothing interesting I can find. Can't see why it should have stuck in a loop. But grinding the disk again like before, but making progress.
Stuck at 9% after 20 minutes. No more progress.
I'm going to stop it, add some files and see if they are backed up this evening.
Any other suggestions? Looks like something is wrong to me.
Wait a sec. Is this thing stuck because I moved the Database, Logs and "Temp" files to the same drive as the files that are being backed up?
So if it sets a trigger that says "If any files are modified on this drive, notify me" and
Then it writes a log entry or touches the database or something It causes a trigger, and
goes out and checks to see if anything changed, and it didn't, so it touches the database/log/temp files, and
Gets another notification and around around we go..
And all this looping thing started when I moved those things to the same drive as is being backed up.
So........
Guess I'll add another drive that I don't need to be backed up, and move the Cloudberry stuff to that drive, away from SSDs and the hard drive that is backed up, and see if CB Backup will calm down.
Wait a sec. Is this thing stuck because I moved the Database, Logs and "Temp" files to the same drive as the files that are being backed up?
So if it sets a trigger that says "If any files are modified on this drive, notify me" and
Then it writes a log entry or touches the database or something It causes a trigger, and
goes out and checks to see if anything changed, and it didn't, so it touches the database/log/temp files, and
Gets another notification and around around we go..
And all this looping thing started when I moved those things to the same drive as is being backed up.
So........
Guess I'll add another drive that I don't need to be backed up, and move the Cloudberry stuff to that drive, away from SSDs and the hard drive that is backed up, and see if CB Backup will calm down.
Added 250GB drive for exclusive use of CB for Logs, Repository and Temp. Not backed up.So no triggers, if that was the problem.
Now I see what activity is going on. The repository is getting a stream of writes of different sizes,. I'm using Disk Activity in Resource Manager from Task Manager.
Looks like it's doing a total rebuild of the Repository. Just guessing here. But it already had that didn't it? Why the rebuild? I'll leave it run for a few hours and see if it calms down. This is a major grind activity. Notice that I let it run for 3 hours before I stopped it the first time. And I only have 350K files in 11K folders for 520GB. Is that large?
Whoa... Stopped after 16 minutes this time. Just as I hit POST on the last comment.
3 hours and 16 minutes for a rebuild? Or was it in a loop and this time it only took 16 minutes because I moved Repository to another drive?
Bottom line. I'm not sure if CB Backup is stable for me yet. And it's not as easy to use as Carbonite. I never had to fiddle with Carbonite to get it going like this.
Thanks for sharing your feedback with us.
Can answer your first 2 questions, but for proper investigation you need to create a support ticket by sending us the diagnostic logs via tools > diagnostic menu.
1) It all comes down to your PCs resources and certain parameters like HDD health and current system load
2) Repository updates might cause issues like that , but we would still need diagnostic logs from the machine for further investigation, like I mentioned previously.
For me, Cloudberry Backup became very slow after the latest update (6.0.2.22). I reinstalled the previous version (6.0.1.66) and the problem went away. So I'll be sticking to the slightly older version for now, hoping this gets resolved.
The slowness occurred when accessing a (very large) network share. I kept the newest version on one of our machines strictly backing up an image. So my guess is there is a bug in the newest version accessing file shares. It completes, but takes a hugely longer amount of time, especially if there are many changes. Again, going back to the previous version of Cloudberry cleared up the problem for me.
That can be a problem with database indexation.
Performing repository sync after update should help. If that doesn't help you need to create a support ticket where we can discuss the problem in more details.
I went ahead and reinstalled the new version (6.0.2.22) and performed a repository sync which completed OK. Unfortunately the slowness problem still happened with last night's backup - it was still running when I came in (usually finishes in a few hours). So I went ahead and reverted back to the previous version 6.0.1.66.
Since I have an easy fix here (going back to the previous version) I'm going that route and will hope your programmers fix whatever is happening in the newest version. Since this is our backup software, I can't be troubleshooting and not having good backups. I hope you understand. I'm happy to post about our environment to your support engineers if you think that would help.
Difficult to say what's going on without seeing the diagnostic info, but that is most likely a problem we've been working on during the last couple of months. Updates 6.0.1 and 6.0.2 were supposed to fix it, but there will be more improvements in version 6.1, which should be released in the beginning of June.
I was having the same problem. Running 6.0.2.22 on Windows 7. I'm trying to create a fresh/new backup with storage on Backblaze. I let it run overnight and in the morning it still said it was searching for modified files. So I killed it again--this had happened several times but was my first overnight trial. Strangely enough, as I was in the middle of writing this post, I tried it again...now it's actually successfully backing up files! I have no idea what changed, if anything, on my end.
In all cases like that it's best to contact support, since there could be several reasons for such things to happen(spike of I/O activity the disk caused by some other process, for example).