copy job 9.5 - daily modified VBK

[lkwjochen]

Hi,

although I'm using B&R since years I just recently started to use copy jobs for offsite backups. It's still some kind of magic for me because the settings are not always clear to me.

Anyway... The primary backup follows the simple scheme of regulary full backups, followed by incremental backups. One reason I've choosed this backup scheme was that I also "backup the backups" to an independent server with it's own custom logic and custom scripts. One crucial attribute I need for my file based logic is the last write time / last modified attribute of a file.

I've expected that a copy job also offers a similar method but it seems that it only uses some kind of forward / reverse incremental methods which leads to a regulary modified VBK file. With that I currently have to copy this (huge) file daily and preserve a copy for every day on the independent server. That's not really suitable for me.

Is there any solution that a copy job produces a simple backup chain like my primary backup?

Regards

[Natalia Lupacheva]

Hi,

By default, Backup copy job uses forever forward incremental backup method. That means by default we will merge incrementals to the full backup file and get the modified .vbk file. You can learn more about this merging process here.

If you have configured your Backup Job as simple forward incremental and need to switch Backup Copy job to Forward incremental mode, you can use an option "Read the entire restore point from source instead of synthesizing it from increments".

Thanks!

[foggy]

Any chance you could replace that scripting approach with another backup copy job? In this case, it will copy only the actually changed blocks regardless of the source backup chain type.

[lkwjochen]

@Foggy
The intension for the scripting approach is to have a secondary independend backup solution on a non Windows system, totally detached from the primary backup procedure to have a fallback in the case of a crypto attack.

@Natalia
I'll give it a try this weekend and report the results.

[foggy]

Basically only a truly offline backup will protect you from a crypto attack, regardless of the way it was created.

[lkwjochen]

@Natalia
I guess your suggestion doesn't fit my needs. I don't need or want any archive files and further the Coby Job will always transfer from source instead of creating a forward incremental chain as/from a synthetic backup with this options - which would save time and bandwidth. At the moment I guess robocopy or fastcopy is more suitable for me to transfer the backups offsite.

Regards
lkwjochen

[soncscy]

lkwjochen,

FWIW, ransomware attacks backup data, not backup methods.

Ransomware attackers will sit in a system for weeks just to understand where the data is going, and rsync on the secondary server (or robocopy or whatever) surely is on such "to check" lists (it would be foolish not to as so many smaller solutions are in fact just shells for rsync; including it + robocopy and you basically get the entirety of smaller solutions in a few lines of code to check for these programs).

You're over-thinking a solved issue, and needlessly complicating your backup strategy. From having had this discussion with many clients, don't try to make backup solutions play nice with one another; each has its own assumptions about how to handle data that often makes this incompatible -- I get that rsync and its clones aren't really backup solutions, but they also have some implicit understandings of the source data they're working with, and file transformations are inherently incompatible with such systems. Right now, you're trying to make a file level incremental/differential backup tool work with an image level incremental tool that transforms the full backup file.

The problem you're having is that both tools are handling the data via intrinsically different ways and their data reduction methodologies are completely orthogonal -- Veeam works at the block level as it reads from the host and transforms blocks within the backup file, meaning frequent changes of the LastModifiedDate which it can safely do because it's reading and checking the blocks within the backup, while rsync/robocopy are looking for changed/modified files, and nothing more. This will forever be in conflict.

Either do only full directory copies of whatever sync tool you use so you have a complete grab of the backup chain, or set up a proper air-gap solution. How the data gets remote is not nearly as important as how you ensure that data is preserved, and right now you're just trying to make two differing solutions work, when each is expecting a different type of source data.