Source backup file has different block size

[scottf99]

Me again.
Since upgrading to V8 I cant get a new Backup Copy to run. I always get "Source backup file has different block size. Expected block size:1024, actual (backup name:*backup job name*, block size 256).

This happens if I try to add a backup copy to any of my existing jobs. I cant work out what to do.

Cheers
Scott

[tsightler]

Sounds like your jobs are mostly configured to use "WAN" optimization instead of "Local". You can't mix jobs with two different optimizations into the same Backup Copy. However, if you've somehow already run a backup copy and the interval expired or otherwise ended (perhaps by triggering a "force sync") I've seen cases where the Backup Copy transfers nothing at all, but creates the metadata file assuming 1M blocks so future runs will fail with this message.

It should be possible to recover from this situation by disabling the Backup Copy job, going to the Backups and right clicking and selecting "Delete from disk" to delete any backups associated with that backup copy job, but be sure to also check the "Remove archived backups" option. Note that this will DELETE all information from the disk associated with that Backup Copy job so only do this if you know there is nothing in the Backup Copy you want to keep.

Just reenable the copy job and don't interrupt it until it starts copying data (don't do a force sync or anything like that). If data won't start copying on the first pass without selecting "force sync" then you need to understand why as selecting force sync will likely cause the error to reoccur.

[Gostev]

Just to add to that, we have had the same restriction around mixing different block sizes in v7 as well, so this is nothing specific to v8.

[averylarry]

. . . but using a backup job as a replication source also has this restriction, which is new to v8. I've been bitten by that, and I haven't taken the time to figure out how to fix it yet.

[foggy]

Ted, have you tried just to change the corresponding setting (Storage optimization) in the replication job?

[averylarry]

I haven't really tried anything. Changing to the backup job as the source also causes the digests to be re-calculated, so I need to change it over slowly. Just haven't had the time yet.

[averylarry]

Does the *backup* job have to be set to WAN optimization? Right now I get the error and:

the backup job is set to High compression, Local target optimization.
the replication job is set to High compression, there is no choice for optimization.

[obroni]

If you need to change the replication block size:-

1. Set the replication job back to source vm
2. Change Block size (optimization) to match backup job
3. Run replication job and wait for it to recalc digests
4. Finally set Replication job back to source of back up job

I've been through this only to discover that a long running replication job is aborted if the backup job runs again. Would have been better if it just queued.

[averylarry]

Took me awhile to figure it out. What kept messing me up is that for replication jobs, the Optimization choice (which corresponds to block size) IS NOT VISIBLE when the source is a backup job. Hence obroni's instructions to change back to source vm.

[veremin]

You can also try to change block size without changing the source type of replication job, using the following commandlet; might do the trick:

Code: Select all

$Job = Get-VBRJob -name "Backup Job 1"
$Options = $Job.GetOptions()
$Options.BackupStorageOptions.StgBlockSize = "New value"
$Job.SetOptions($Options)

Thanks.

[briguyiu]

One of the new features I was really excited for was utilizing the source backup for replication jobs vs. creating a new snapshot etc. I switched them last week, and am now getting this warning Restore point is located in backup file with a different block size (512KB expected). My backup repositories aren't VMFS LUNS, they are RDM's directly to the SAN. I'm assuming this is the reason for the warning, since the destination is VMFS5, and RMD's aren't formatted with VMFS. I don't think the job is actually completing either, as the last creation time is before I made the source change. Is the only way to fix this to change the RDM's to VMFS LUNS with the same format?

[veremin]

The said error means that source backup job uses different block size. For more information, kindly, check answers provided above. Thanks.

[briguyiu]

All of my searches came up with backup copy jobs I thought....sorry for overlooking this one. So, since my backup repositories are RDM's and 512kb, is there any kind of workaround, other than making my repositories VMFS5 with 1MB block sizes, like the destination data stores at the DR site? I didn't fully understand obroni's second step, as I don't see any storage optimization options on job settings other than LAN/WAN/Local Targets.

[veremin]

The only thing that matters is the block size selected in the settings of source backup job (repository type does not matter).

You should follow procedure described by obroni. Most likely, now you don't see storage optimization settings, because you haven't specified VM as source (step number 1).

Thanks.

[Vitaliy S.]

Yes, VMFS block size is not related to this problem.

[briguyiu]

I did the first step, I just don't see anything related to block size here in the replication job???

[Vitaliy S.]

You're at the right place. See these instructions on the first page from obroni:

If you need to change the replication block size:-

1. Set the replication job back to source vm
2. Change Block size (optimization) to match backup job
3. Run replication job and wait for it to recalc digests
4. Finally set Replication job back to source of back up job

Hope this helps!

[briguyiu]

Oh, ok. I thought I would see something with the words block size. I just checked my backup jobs and they all have Local Target...So, I'll do the same for my replication jobs and let them run tonight, and then switch the source tomorrow. Thanks!

[averylarry]

If you have the disk space available, you can instead change the backup job to match the block size (Optimization) of the replication job. BUT you have to then run an active full backup to actually change the block size (hence the need for disk space).

[dspjones]

We've installed v8 several weeks ago and unfortunately other issues have prevented me from doing much else with Veeam. Finally I have some time to delve into the new features and I set our replication job from replicating the live environment to replicating from backup over WAN optimization. It seems to work but all of the servers now show a warning in the job.

I get this:

WARNING: A restore point is located in backup file with a different block size (xxxx KB expected)

What's going on and how do I resolve?

Thanks.

[veremin]

Your post has been merged into existing discussion talking about the same issue. Kindly, check answers provided above. In nutshell, you have to change block size settings of replication job to match those of backup job.

Thanks.

[fluxblocker]

I got this same error message when trying to replicate the backup jobs to a DR site. I was able to fix it by deleting and recreating the replication job. Also recommended to delete any replica VMs in the DR site with the same name.


Best,
Flux

[TheJourney]

The Replication jobs don't error and fail. They are just set to Warning, but have actually failed. I had no idea they were not actually running, until I needed one...

NOT GOOD!

[TheJourney]

If you need to change the replication block size:-

1. Set the replication job back to source vm
2. Change Block size (optimization) to match backup job
3. Run replication job and wait for it to recalc digests
4. Finally set Replication job back to source of back up job

This did not help my issue. Replication jobs still fail.

[TheJourney]

I got this same error message when trying to replicate the backup jobs to a DR site. I was able to fix it by deleting and recreating the replication job. Also recommended to delete any replica VMs in the DR site with the same name.


Best,
Flux

I had to delete the Failing replication jobs and recreate them as well. My system was an upgrade from 7.x.

Sam.

[TheJourney]

I actually only had to del the Replicas, not the jobs. After deleting the replicas the jobs run as they should.

[Felix]

I had the same problem, because the block size autodetection for copy jobs is faulty. All my source backup jobs had blocksize 1024 (LAN target optimization), but some of them had older restorepoints that were made with blocksize 512 (Default/Local target), so the autodetection assumed blocksize 512 and copy jobs failed.

To fix it I disabled the copy job, removed the jobs backup files from disk, went into PowerShell and did the following:

Code: Select all

$Job = Get-VBRJob -name "USB Backup Copy"
$Options = $Job.GetOptions()
$Options.BackupStorageOptions.StgBlockSize = "KbBlockSize1024"
$job.SetOptions($Options)

After that I re-enabled the copy job and on the second run it started working.

This would be much easier to fix if the copy job options allowed to manually set the storage optimization.

[tommyv]

FYI, I had this issue running a copy job from one DataDomain to another DataDomain. I followed tsightler's procedure and it fixed the problem. I suspect its because the original backup job storage optimization setting was changed and there is no way of updating the optimization in the copy job. Thanks for the help.

Sounds like your jobs are mostly configured to use "WAN" optimization instead of "Local". You can't mix jobs with two different optimizations into the same Backup Copy. However, if you've somehow already run a backup copy and the interval expired or otherwise ended (perhaps by triggering a "force sync") I've seen cases where the Backup Copy transfers nothing at all, but creates the metadata file assuming 1M blocks so future runs will fail with this message.

It should be possible to recover from this situation by disabling the Backup Copy job, going to the Backups and right clicking and selecting "Delete from disk" to delete any backups associated with that backup copy job, but be sure to also check the "Remove archived backups" option. Note that this will DELETE all information from the disk associated with that Backup Copy job so only do this if you know there is nothing in the Backup Copy you want to keep.

Just reenable the copy job and don't interrupt it until it starts copying data (don't do a force sync or anything like that). If data won't start copying on the first pass without selecting "force sync" then you need to understand why as selecting force sync will likely cause the error to reoccur.

[Felix]

I think the problem is, that a job still reports the block size it was originally created with instead of the block size it currently uses. I have jobs that don't have a single restore point with an older block size, but querying StgBlockSize through powershell still reports the old block size so creating copy jobs for those jobs fail.

[foggy]

I think the problem is, that a job still reports the block size it was originally created with instead of the block size it currently uses. I have jobs that don't have a single restore point with an older block size, but querying StgBlockSize through powershell still reports the old block size so creating copy jobs for those jobs fail.

Any chance you've populated the backup copy job from backups/infrastructure (as opposed to selecting particular backup jobs)?