Discussions specific to object storage
wishr
Veeam Software
Posts: 1163
Liked: 117 times
Joined: Aug 07, 2018 3:11 pm
Full Name: Fedor Maslov
Contact:

Re: 9.5 Update 4 and Microsoft Azure Blob Storage

Post by wishr » Sep 09, 2019 1:59 pm

Hello,

Usually, we cannot comment on future release plans or product ETAs, but as Gostev mentioned in the July forum digest, it should be shipped before the end of this year if nothing unexpected pops up (particularly around 3rd party platform updates).

Thanks

dw432948jkk
Novice
Posts: 8
Liked: 1 time
Joined: Sep 05, 2019 8:26 am
Full Name: Peter Müller
Contact:

Re: 9.5 Update 4 and Microsoft Azure Blob Storage

Post by dw432948jkk » Sep 13, 2019 12:49 pm 1 person likes this post

yasuda wrote:
May 29, 2019 5:15 pm
Hi Dan, do you have any comment on the previous discussion of immutable storage? Is Wasabi's immutable storage diferent from "...Amazon object-level immutability is more of a marketing term, in reality what they sell behind this term is regular object versioning..." ?
Is there any reason why WasabiDan does not answer this question?

Gostev
SVP, Product Management
Posts: 24810
Liked: 3567 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: 9.5 Update 4 and Microsoft Azure Blob Storage

Post by Gostev » Sep 13, 2019 7:38 pm

Because he did not log on here once after his only post above ;) I just checked his forum account.

In any case, I can answer this: Wasabi does not support S3 Object Lock at all at this time.

I also wanted to clarify: I did not mean that Amazon's implementation is somehow invalid. It does the job - just requires a lot more code from our side to work with, for obvious reasons. I mean - a single, actually immutable copy of an object that cannot be deleted or overwritten would have been so much simpler to architect against. While dealing with potentially deletable and overwriteable "immutable" objects requires tracking the required object versions in its version history (separately for each and every object), which adds significant complexity.

But anyway, it did not stop us :D

dw432948jkk
Novice
Posts: 8
Liked: 1 time
Joined: Sep 05, 2019 8:26 am
Full Name: Peter Müller
Contact:

Re: 9.5 Update 4 and Microsoft Azure Blob Storage

Post by dw432948jkk » Sep 14, 2019 7:23 am

Did I understand correctly that veeam is working to set up veeam-backups so that they can be copied (not moved) (with whatever other third party program) to the immutable storage of cloud backup providers like Azure, AWS, etc.? That would be great because, to my knowledge, no backup program can do this.

Gostev
SVP, Product Management
Posts: 24810
Liked: 3567 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: 9.5 Update 4 and Microsoft Azure Blob Storage

Post by Gostev » Sep 15, 2019 10:32 pm

Peter, actually what you explained sounds like something that was always possible with Veeam... if you use an incremental backup mode with periodic synthetic or active fulls, you can certainly use any 3rd party program to copy those backups to object storage buckets with immutability enabled. Thanks!

yasuda
Enthusiast
Posts: 63
Liked: 10 times
Joined: May 15, 2014 3:29 pm
Full Name: Peter Yasuda
Contact:

Re: 9.5 Update 4 and Microsoft Azure Blob Storage

Post by yasuda » Sep 16, 2019 3:10 pm

Gostev wrote:
Sep 13, 2019 7:38 pm
...I also wanted to clarify: I did not mean that Amazon's implementation is somehow invalid. It does the job - ...
Thanks for the clarification!

Is it also true Glacier or Deep Archive data would be protected, because there is a minimum duration data has to be left there, before it can be deleted? Assuming you are only concerned with recovering your most recent backups.

Gostev
SVP, Product Management
Posts: 24810
Liked: 3567 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: 9.5 Update 4 and Microsoft Azure Blob Storage

Post by Gostev » Sep 17, 2019 9:00 am

My understanding is that Glacier has minimum duration charge, not minimum duration storage. Meaning, you can still delete data immediately after uploading, but you will be charged as if the data was stored there for a minimum required duration.

dw432948jkk
Novice
Posts: 8
Liked: 1 time
Joined: Sep 05, 2019 8:26 am
Full Name: Peter Müller
Contact:

Re: 9.5 Update 4 and Microsoft Azure Blob Storage

Post by dw432948jkk » Sep 24, 2019 8:07 pm

Gostev wrote:
Sep 15, 2019 10:32 pm
Peter, actually what you explained sounds like something that was always possible with Veeam... if you use an incremental backup mode with periodic synthetic or active fulls, you can certainly use any 3rd party program to copy those backups to object storage buckets with immutability enabled. Thanks!
The problem with this is the veeam backup chain metadata file.

Even with incremental backups, this file will always have the same name and will not be transferred by the programs that are supposed to do the uploads (rclone, cloudberry, etc.) because, for example, Azure reports back that the file already exists and can not be overwritten.

There is (unless you create a script that versioned this file before each upload and then always uploaded a modified version) from the perspective of upload programs no solution.

Is there a solution planned here from veeam?

Gostev
SVP, Product Management
Posts: 24810
Liked: 3567 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: 9.5 Update 4 and Microsoft Azure Blob Storage

Post by Gostev » Sep 24, 2019 9:56 pm

You might be confusing Veeam with some other vendor, because Veeam names each incremental backup file uniquely.

dw432948jkk
Novice
Posts: 8
Liked: 1 time
Joined: Sep 05, 2019 8:26 am
Full Name: Peter Müller
Contact:

Re: 9.5 Update 4 and Microsoft Azure Blob Storage

Post by dw432948jkk » Sep 25, 2019 5:03 am

The files ending in .vib have different names, but one .vbm file always has the same name within a backup.

Well, I'm actually confused now :?

Gostev
SVP, Product Management
Posts: 24810
Liked: 3567 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: 9.5 Update 4 and Microsoft Azure Blob Storage

Post by Gostev » Sep 25, 2019 11:11 am 1 person likes this post

VBM is a metadata file which is not essential for restore, as the actual data sits in VBK (full) and VIB (incremental) backup files.
Click Browse and select the necessary VBM or VBK file. If you select the VBM file, the import process will be notably faster. It is recommended that you select the VBK file only if the VBM file is not available.

dw432948jkk
Novice
Posts: 8
Liked: 1 time
Joined: Sep 05, 2019 8:26 am
Full Name: Peter Müller
Contact:

Re: 9.5 Update 4 and Microsoft Azure Blob Storage

Post by dw432948jkk » Sep 25, 2019 1:00 pm

Ie. the vbm file is actually solely responsible for enabling a faster backup?

Otherwise, there are no disadvantages if you do not have the vbm file?

So far it has not emerged for me from the documents.

veremin
Product Manager
Posts: 16901
Liked: 1439 times
Joined: Oct 26, 2012 3:28 pm
Full Name: Vladimir Eremin
Contact:

Re: 9.5 Update 4 and Microsoft Azure Blob Storage

Post by veremin » Sep 25, 2019 4:22 pm 1 person likes this post

It's not responsible for enabling faster backup, it makes backup import procedure work faster.

If you'd like to transfer backups offsite via 3-party utility, you can skip .vbm file. However, should disaster happen, you will need to import backup chain to backup server first (before you restore anything), without .vbm file this process will be significantly longer.

Hope it helps.

Thanks!

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests