Maintenance is designed to provide support, and free version upgrades. It's recommended, but not required. If you do have a problem with the software, however, and you have not purchased maintenance, then support may just direct you to the forums on the website instead.

Having said that that's a lot of servers. Do you think you would be better served by using our managed product?

Windows XP is no longer supported. The only reference to that error message I see in this system was from 4 years ago, and it was an issue that was fixed in the 5.6 release. Since I assume you're using the latest 7.0, it could be that the latest version simply will not run on Windows XP. We do not test that operating system any longer.

Depending on how you are running the VM, and whether or not you are running it from another more recent copy of Windows, or Windows Server, then the other option would be to expose the data in the VM that you want to back up as a share and back it up from the main operating system on the host or another computer on the network that can see the share. If however you're backing up from VMware or Hyper-V then I think the only other option would be to back up that VM using our virtual backup product, but that only backs up at the virtual machine level, not at the file level.

If you want to provide more details about your particular use case, we may be able to come up with a different solution.

Seems like what you're after for this particular backup is more file-sync and not file backup. There is no function in the product that will duplicate what you're looking for. That is, back up files only once and then back up only new files from then on. I cannot think of a way to avoid backing up changed files to solve your particular use case.

I assume you're not concerned about editing a photo and re-saving it under the same name.

The best you can do if you're not planning on changing the files in any way is to use a custom retention (set it in the backup plan) and do not select any of the retention options. That will allow you to keep all versions of all files forever since you are not versioning, you are not setting a backup delete based on time so old versions will never be deleted, and you are not deleting files from backup even if they are deleted on your local system, so once backed up they are in backup storage forever.

You should not use the Block-Level Backup option which backs up changes within files - as opposed to backing up the file in full each time it is modified. You're not planning on modifications anyway.

If nothing is ever modified, then keeping all versions for all time will not add you your backup storage and pretty much do what you need. If you ever experienced a big corruption that caused a lot of files to be backed up again, you would easily see this in the backup notification. At that time, you can stop the backup, replace the hard drive, and delete any backup versions not needed from the backup storage tab.

The hidden and system attributes are just that; attributes on files. The obvious system files are those that are installed by windows itself, although I would guess that not all of them are marked as system. Hidden files are also used by the operating system but you could also be have that attribute applied manually if somebody wanted to hide a file from view unless hidden files are being shown by default in Windows Explorer. Whether you back them up or not for a file backup is entirely up to you. You won't get likely unnecessary files like the thumbs.db files which are used to cache thumbnails of images in a folder, but you could be missing other important files like an app that keeps certain important files hidden. So we leave it up to the end user to decide whether or not those files with those flags are important. You can search for them easily in Windows using the ATTRIB command from the command-line. You can research that command if interested.

So, you're running nested RD connections? Have you tried sending the command from the server in the middle?

Thanks for letting us know.

Thanks for the update. I found our KB article on this B2 limitation: https://kb.msp360.com/cloud-vendors/backblazeb2/unsupported-characters-b2

Cloud Storage? Is it B2? I've only ever seen that error on Backblaze B2. Usually it means the file has illegal characters and wouldn't be transferred to B2, but since you say you've already removed it from the backup storage tab, it would sort of imply that the file maybe was already backed up. So I would go out to your backup storage, wherever it is, and make sure the file is officially removed from backup storage. If that doesn't work let me know, and we'll maybe have to have you open the support case.

See if this post help. https://social.technet.microsoft.com/Forums/en-US/a34bafb2-21e3-4550-bc61-c96480ab1a59/getting-warning-quotthe-system-failed-to-flush-data-to-the-transaction-log-corruption-may-occur?forum=winserverfiles

Or possibly this one: https://social.technet.microsoft.com/Forums/en-US/33df79c8-440f-44bc-acdd-5992dc49ad09/problems-with-server-2012-essentials-various?forum=winserveressentials

If not, I'd open a support case since I don't see that error in the system.

Merging the checkpoints should happen automatically. I had someone in Support test on Hyper-V and he was not able to reproduce this issue - all the checkpoints (both Production and Standard) were being merged right after the backup completed.

To see why you're running into this issue, we'll need to have you create a Support Ticket. You can open one up from the Tools | Diagnostic toolbar option or on the web site.

Thanks.

If you are seeing this behavior, then I need you to open a support case. The team was unable to reproduce the issue and asked me to ask you the following:

Please instruct the customer to
1) Enable High-Level Logging from Options - Logging
2) Send the logs via Tools | Diagnostic toolbar option
3) Mention "Vlad L" in the ticket so it gets assigned to him
4) Turn Logging back to Low

Thanks for the update.

We can actually resume an image backup, but in order to do so, there cannot be any changes to the blocks already backed up - and sometimes that's not possible because the system ran for some time before the backup resumed.

From Support:

"When there are any issues with the installation process, and those issues are clearly caused by an outdated .NET package, we always recommend to uninstall that outdated .NET package and install .NET Framework v. 4.5.2 instead:"
https://www.microsoft.com/en-us/download/details.aspx?id=42642


So you can check to see if you have any old .Net versions installed that are no longer needed by other applications. If you do uninstall, I'd reboot and try Explorer again. If you still have the issue, try installing 4.5.2 as instructed above.

File backups will continue from where they left off. You can stop the backup, wait for it to stop, then reboot, and start up the backup manually or wait for the next schedule as needed. No need to upgrade.

Those options you mentioned are not related to keeping locally deleted files. You didn't mention the product version or the type of backup you are running, so I'll just assume it's a File Backup on 6.x. If you're using a different backup or are using 7.0, then please clarify and, in addition, if you're on 7.0 let me know if you are using the new backup format.

Set the Retention Policy in the backup plan, rather than setting in Global Options. Uncheck the option for "Delete Files that have been Deleted Locally" and that should prevent any local files from ever being removed from backup storage. As an alternative, you can use the option with the delay to prevent those locally deleted files from being removed, for say 90 days.

What version are you using (6.x or 7.x) and what type of backup are you running (file, image, virtual, etc)?

This is being tracked in the other thread: https://forum.msp360.com/discussion/2036/restore-backup-onto-different-hard-drives

It should. Have you run a consistency check. https://help.msp360.com/cloudberry-backup/restore/about-restore/performing-a-consistency-check

Possibly, some of the metadata is out of sync. If that does not address your issue, then the support team will have to take a look at the logs to see what is going on. Use the Tools \ Diagnostic toolbar option to open a case, reference this post, and mention I asked you to open up the support case.

I would not do that with S3 Glacier / Glacier. Initiating a consistency check will require a long wait time of 4-5 hours. How much data is retrieved during that time, I cannot say. I do not believe it's moving / staging the data, but instead refreshing the inventory stored in S3 from the the data in Glacier. Either way, it's a wait, and there may be cost involved.