Source backup file has different block size

[ramnefors]

OK, I will open a support ticket.

Optimization of underlying job has not changed, it has been set to "storage > advanced > LAN optimization" since it was originally created.

Backup mode is reverse incremental for the underlying full backup.

[foggy]

I would appreciate if you post back your findings or at least provide case ID once opened, so we could check for a possible solution in future. Thanks!

[ramnefors]

Sure, case id is #00910040.

I will post a solution once we arrive at one.

Thanks for the suggestions sofar.

[ramnefors]

This was the response from support:

Hello Mats,

This message means that the original backup chain was created with a different blocksize (Local) and then it was switched to LAN target.

[30.04.2015 15:10:19] <01> Info [OibFinder] Searching Oibs in backup [Full backup:e46c72e5-b3d9-4500-8301-d69a9e860950]
[30.04.2015 15:10:19] <01> Info [OibFinder] Found 14 Oibs
[30.04.2015 15:10:19] <01> Info [OibFinder] Following Oibs are located in storages with different (KbBlockSize512 expected) block sizes and excluded from search:
[30.04.2015 15:10:19] <01> Info id='9eb1a2d5-4e6e-4996-8dbc-eac4387d4588', time='2015-04-16 20:02:17', block_size='KbBlockSize1024'
....

The blocksize change does not happen until active full, so please run an active full backup on the source backup job, and after that the Backup Copy should pick up.

I did as suggested and the Backup Copy completed successfully.

At bit confusing to me was that there was a previous Copy job in place from v7 which run OK. The error only occurred when that job was deleted and a new job added under v8.

[foggy]

So my assumption regarding block size change was correct. Thanks for getting back with this!

[lightsout]

So I run active fulls weekly, and I reset my backup copy jobs after Update 2 but I'm still getting the block size error on one job (the first one I configured). My block sizes were changed some time back in 2014, and my chain isn't that long.

Any idea what could be causing it?

[foggy]

Better address this to support, logs should tell the reason of this behavior.

[rccl_ecain]

So, in relation to the Replica jobs, coming from a backup.

WHY does the block size matter, when all that's happening is the backup data is being read from the source and being written, uncompressed to the target datastore? It shouldn't matter what the block size is of the source...

This is really kinda annoying as I changed the job settings on a bunch of backups recently to reflect your recommendations for Dedupe Storage (which is another mess... Srsly why would I want BIGGER blocks for DataDomain?) and then all my replicas stop working. And what's worse is it's a Warning, not a Failure. If a job can't run, then it should Fail.

UGh...


/rant

[foggy]

WHY does the block size matter, when all that's happening is the backup data is being read from the source and being written, uncompressed to the target datastore? It shouldn't matter what the block size is of the source...

It actually doesn't matter, if you are on Veeam B&R Update 2. In case of block size mismatch, replication job should re-calculate digests during the next run and continue normally.

Srsly why would I want BIGGER blocks for DataDomain?

Reading with larger block requires less IOPS, which results in increased restore performance (comparing to using smaller block on the same storage).

[rdc373]

Can some give me a step by step for Offsite copy jobs?

I have followed everything in the Veeam guide.
- Two repositories
A - USB offsite 1
B - USB offsite 2

Two Copy Jobs:
1 - for Repository on USB Drive A
2 - for Repository USB Drive B

Tried:
Disabling Copy Job 1 to USB Drive A
Enabling Copy Job 2 -> Running :: Veeam Warning :: block-size mismatch



Tried:
Switching Repositories for the copy job. No worky. Every morning I end up spending two hours fixing / playing with these?


When the new disk came in (that are from the SAME REPO) : I get this: 3/3/2016 4:52:37 PM :: Source backup file has different block size. Expected block size: 512, actual: ([backup name: -> Backup, block size: 1024])


I even removed the old copy job backups from the USB drvie?? This was its first rotation and I had to fix many errors when I first roates the last one? Does this just work?

[Shestakov]

Hello,

Do you have one or several backup jobs used as a source for the backup copy?

Try to run an active full on the source job(s) and then backup copy job.
It will just work.

Read the thread for more info.
Thanks!

[rdc373]

1 Backup Job
2 I will try that again - even though I cannot during business hours because of performance hits on a live server.


Tried everything in the thread. Still not working..... I have yet to see just work after a single rotation.

[foggy]

I'd first like to get a better idea of how your jobs are configured. Do you have just a single backup job and two backup copy jobs (with different target backup repositories backed up by a USB drive each) that use that backup job as a source? (if that's the case, why not to use just a single backup copy job to a rotated repository then?)

Any chance storage optimization settings on the original backup job were changed recently? In this case making active full and starting from scratch should help. Please contact support for further assistance otherwise.

[RWeiss]

I encountered this issue today with v9 Update 2.
To be honest, I cannot tell you what caused this issue with my Backup Copy job. I do not recall changing any storage/compression level settings. I only enabled (not sure whether this has any effect) the option "Exclude deleted file blocks" in the backup copy job.

Currently, the compression/dedupe options are "Optimal" and "LAN target" in the actual Backup Job and "Auto" in the Backup Copy job.


I might have missed in in this thread, but what would be the most straight-forward way to fix this issue without starting a new backup copy chain? Can I do something with the existing backup copy chain to fix this issue?

Many thanks in advance.

[veremin]

Can initiate active full cycle for source backup job and, then, check whether backup copy job proceeds as expected? Thanks.

[RWeiss]

I did try this and performed an active full backup on the source backup job. The backup copy job still reports the same issue (expected: 1024, actual: 512).

[RWeiss]

I think the issue is more that the source backup file won't change back to 1024 anymore, even though I do an active full backup.
Which settings are necessary to change it back to 1024 block size?

[foggy]

You need to select "Local target" in storage optimization settings.

[RWeiss]

In this case I'm a bit clueless as I certainly did not change this setting in the Backup Job, it was always set to LAN Target and I would like to keep it that way.
I exported the logs for the affected backup and when I search for "StgBlockSize" it clearly states that 512Kb is used <StgBlockSize>KbBlockSize512</StgBlockSize>. I checked for the last 6 days and it always stated KbBlockSize512. Both the Backup Job and the Backup Copy Job actually did run successfully this morning (apparently with a block size of 512Kb).

If this is the case, the Backup Copy Job must have changed, for whatever reason. I also exported the logs there and it was always set to "Automatic" for the last 6 days. Why does it suddenly decide to use 1024 Kb then?
Anyway, there is no "Local target" in the backup copy job settings, only "Auto" (which was always set), "None", "Dedupe-friendly", "Optimal", "High", "Extreme". Which one of these corresponds to 512 Kb?

[foggy]

I was talking about the source backup job settings, backup copy doesn't have the corresponding option. Anyway, I'd suggest contacting support for a closer look at your logs, since the behavior doesn't look expected from your words.

[romwarrior]

RWeiss - have you recently mapped the source backup job or did it do an active full recently? Block size only changes during active fulls and is only set in the source backup job. The copy job expects the block size to never change.

I had an issue a while back where I changed the server running a source backup job (created a new job on the new server and then mapped) and didn't set the block size to match the original backup job. My copy jobs ran just fine until the source backup job did an active full, which changed the block size which caused the copy jobs to start failing.

[RWeiss]

Hi romwarrior

I have not mapped any backup job. If I look in the logs (and interpret them correctly), the Backup Job has always run with the same block size for the past 6 days. Because of this, Backup Copy should also have used a block size of 512 if I understood this correctly. I did not run an active full backup since the last time the copy job worked and the time it stopped working (it happened literally within a few hours).
For whatever reason the copy job just started to expect a block size of 1024.

I did open a ticket now and will keep you posted (Case ID 01875640)

[hyvokar]

I have the same problem. Backup Copy job stopped working and gives me an error 28.9.2016 9:09:58 :: Source backup file has different block size. Expected block size: 512, actual: ([backup name: ServerXXX, block size: 256]) .
Afaik, no changes have been made to backups and backup copy has been working for 6 months.


E: Just remembered that I enabled per-vm backup files on the repository and run active full backup a while ago, could this break backup copy job?

[hyvokar]

E: Just remembered that I enabled per-vm backup files on the repository and run active full backup a while ago, could this break backup copy job?

they dates seem to match with enabled per-vm backup files.

So... Sorry if I missed, but how to fix this?

[foggy]

Most likely storage optimization settings were changed on the backup job some time ago and took effect after running active full, causing the backup copy job to fail, since it does not support mix of block sizes. You either need to recreate the backup copy job or revert the block size changes on the original job and perform another active full.

[hyvokar]

Thanks! I'll try reverting settings (i guess 512 is lan target), and take a new backup.

[foggy]

Correct, 512 KB block size corresponds to the 'LAN target' setting.

[rnt-guy]

In this case I'm a bit clueless as I certainly did not change this setting in the Backup Job, it was always set to LAN Target and I would like to keep it that way.
I exported the logs for the affected backup and when I search for "StgBlockSize" it clearly states that 512Kb is used <StgBlockSize>KbBlockSize512</StgBlockSize>. I checked for the last 6 days and it always stated KbBlockSize512. Both the Backup Job and the Backup Copy Job actually did run successfully this morning (apparently with a block size of 512Kb).

If this is the case, the Backup Copy Job must have changed, for whatever reason. I also exported the logs there and it was always set to "Automatic" for the last 6 days. Why does it suddenly decide to use 1024 Kb then?
Anyway, there is no "Local target" in the backup copy job settings, only "Auto" (which was always set), "None", "Dedupe-friendly", "Optimal", "High", "Extreme". Which one of these corresponds to 512 Kb?

What Log file for the backup and copy job did you look in and did you just search for 'blocksize' to see it?

[foggy]

It can be found in the corresponding job log (Job.<Jobname>.Backup.log, for example).

[Anguel]

I am running multiple endpoint backups via Veeam Agent 2 for Windows to a VBR 9.5 Update 2 server where the main repository is. From there I use single copy jobs to copy ALL endpoint backups to NAS or to USB. Inline data deduplication is enabled for those copy jobs.
Now I noticed that all my endpoints were configured for local target, but LAN target would be more appropriate. So I changed some endpoints to LAN target and also added some new endpoints with LAN target already selected.
Today I noticed that the copy job for all those "LAN target" endpoints fails with:
Source backup file has different block size. Expected block size: 1024, actual: ([backup name: Backup Job SOME-PC, block size: 512])
Deleting all old backups from the job for those endpoints and running a new active full does not solve the problem.
So I wanted to make sure that in latest VBR it is still the case that endpoint backups of different blocksizes cannot be mixed in one copy job.
If this is the case I would probably have to delete all old backups and recreate all backup copy jobs - not sure if this is worth it.
Or I would have to go back to local target for all endpoints (also future endpoints).
Can you please confirm that there is no other workaround? Thanks.