That explanation you posted is for image backups. Again, your example in the previous post is not a thing you can do. You can't run a legacy full backup that backs up every single file at any point. That function does not exist. The only time every file is backed up is the very first time you back up on a new plan. After that, only changed and new files are backed up. Whether those changed files are backed up in full or whether only the changes within those files are backed up depends on whether or not the block level backup option is selected and the size of the file - because small files will probably just be backed up in their entirety every time regardless. Any of the files that are backed up using block level will only be backed up in full again according to your full backup schedule. But just to reiterate, and to be clear, when the full backup runs only files that are new and changed are backed up and they are backed up in their entirety. Any files that are unchanged are not backed up.

As far as I'm aware you would need to create a new plan to transition to the new backup format and that would create a new backup set using the new format. Block level backup does not exist in the new format because we perform client side deduplication automatically and that effectively replaces the block level backup option.

Hard to diagnose without an actual error. You can open a support case form the web site and manually submit the logs. Things I might look at are: whether you change the service account for the backup service recently or whether you've installed any new security software which could possibly be blocking access to the cloud resources you need to touch. Can you also tell us what version you're running and what type of backup you're running and what the target is?

The latest version is 2.5.0.83 . Please download and try again.

May need to reboot this question because I assumed you were talking about the legacy format. Assuming that is the case, then there is no backup chain at the group level. There are only backup chains at the file level when using the block-level backup option. If you do not use block-level, then every backup of every file is always in full. Do not think of file backup in the context you are painting it in - your analogy is more applicable to image backups where you need to periodically run a new full backup or construct one using technology like a synthetic full backup. While a file backup plan might manage and back up tens of thousands of files, the metadata is managed at the file level.

If, however, you were referring to the new backup format, then let me know...

I have not seen that reported. Can you confirm the following:

• The platform you are running (Windows?)
• The version of Remote Desktop
• The default language your OS is set to

Let me also add that when I try to connect to a remote system, the Connect To entry does allow alphabetical characters.

Physical sockets. If you both your servers are 1 or 2 CPU Socket Servers, then two base VM licenses - one for each server is fine.

I'll have to loop back with you, but what you are saying is not a thing with file/folder. There is no such thing as a periodic full backup with respect to all the files / folders in a backup. If you use block-level, a file may only have the changed parts backed up and the full backup schedule will back up that file (and any other block-level files) in full as needed at that time. But at no time, are all files backed up in full after the initial backup. File backups are effectively incremental forever.

The error is on this file:

You could try to synchronize the repository. Possibly what's in storage is out of sync with the local database.

What type of backup are you running? File/Folder or Image? For File / Folder, deduplication may not have the storage savings you'd see with image-based backups since a true full backup of all files is only run once. In addition, if you use the Block-Level Backup option with the legacy file format, we'll back up only the changes within larger files that change little data to day. My opinion is that you would be better served by continuing to use the legacy hybrid backup format.

You can see the logs by going to Options - Logging and reviewing the log information for the date and time of the error. It may provide some additional details for you.

Maybe it's just an intermittent issue with OneDrive. OneDrive is no longer officially supported by us as it's not really designed for object type storage for backups, but we do support it for backwards compatibility for those customers that are still using it. If it happens again let us know. If you really want this investigated further you'll need to contact support and open up a support case. Apologies, but that error number is a generic one. You could try looking at the logs if you want if you feel like investigating more yourself.

If you change the Operation drop-down to Failed, do you see anything?

Engineering has confirmed this is a known issue with 7.1. They are evaluating and will fix soon. I’ll report back once I have the date of release.

What information would you like to have in your customer report? Total computers under management, total backups, individual backup stats, other?

If you use the same backup prefix and sync the data, I do not think you need to change anything on the S3 side. But if you have concerns, I'd recommend you open a Support case and get confirmation from one of our support reps.

The Differential backup you are restoring does not belong with the Full backup you restored - is the most likely reason. Has anyone run any full backups on that database after the full backup, but before the differential backup? If so, that's the reason. You would need to perform a COPY ONLY backup to prevent this issue.

You can check your msdb database to see what has been run on the database in question. I think you can check the database_backup_lsn column to see what set the backup belongs to. Run a query like this and change the database name as needed.

What is that screenshot from where you are showing the 706.var file versions? Is it from the S3 directly? If so, do you have S3 Bucket Versioning enabled?

If so, we do not support versioning by cloud providers. You need to use our retention settings to manage multiple versions of files in your backups. You may be able to use CloudBerry Explorer to copy the version you need locally - Explorer will perform a restore if it detects this is one of our Backup files.

What do you see when you look at History for that backup plan? Any indication what the issue is?

I am having the same issue on my local install. I am checking with Support to see if this is a know issue.

I do not see a way to do what you are requesting with a scheduled Group report. You can send Success emails at the backup plan level by editing the Notification tab.

Could you describe more about the reason you need this feature? What information are you looking to send to your customers?