Discussions related to using object storage as a backup target.
Post Reply
mamosorre84
Veeam Legend
Posts: 336
Liked: 34 times
Joined: Oct 24, 2016 3:56 pm
Full Name: Marco Sorrentino
Location: Ancona - Italy
Contact:

FEATURE REQUEST - Add Capacity Tier Extent Types

Post by mamosorre84 »

Hi all,

I hope it isn't a duplicate post..do you have in roadmap to add other types of extents for the capacity tier (CIFS, NFS, dedup appliances..)?

It could be useful to use the "move" feature in the SOBR instead of configure a backup copy for these other repo targets.

Thank you

Marco S.
HannesK
Product Manager
Posts: 14287
Liked: 2877 times
Joined: Sep 01, 2014 11:46 am
Full Name: Hannes Kasparick
Location: Austria
Contact:

Re: FEATURE REQUEST - Add Capacity Tier Extent Types

Post by HannesK »

Hello,
our focus for foreseeable future is object storage. What would be the use-case of the expensive and slow systems you mention if there is something faster and cheaper available? NFS and SMB have no block cloning. Dedupe appliances can hardly compete with XFS / REFS.

I could understand archiving to tape, but for SMB (CIFS is dead since a decade), NFS and dedupe appliances it makes little sense to me.

Best regards,
Hannes
mamosorre84
Veeam Legend
Posts: 336
Liked: 34 times
Joined: Oct 24, 2016 3:56 pm
Full Name: Marco Sorrentino
Location: Ancona - Italy
Contact:

Re: FEATURE REQUEST - Add Capacity Tier Extent Types

Post by mamosorre84 »

Hi Hannes,

forgive me, I left out the two most important.

I understand the future is object storage, but many of us still have kilos TB of slow legacy repo on-prem that we want to continue to use! :)

If you allow these kind of targets for standard repo and performance tier I see nothing wrong with allowing them to be used in the capacity tier as well.

My usage idea would be just to take advantage of the "move older than" option on SOBR.

I'll give you an example: nas with some fast disks and some capacitive ones, it would be useful to create the performance tier with ssd disks and the capacity tier with slower disks .. obviously always using refs or xfs + immutability.

Currently I have to create a copy job, with the result of having some duplicate chains on both targets .. I don't know if I made myself clear.
HannesK
Product Manager
Posts: 14287
Liked: 2877 times
Joined: Sep 01, 2014 11:46 am
Full Name: Hannes Kasparick
Location: Austria
Contact:

Re: FEATURE REQUEST - Add Capacity Tier Extent Types

Post by HannesK » 2 people like this post

Hello,
the idea is clear, but with "move" without "copy", it's a violation of the 3-2-1 rule ;-)

I agree that there are use-cases.

Best regards,
Hannes
PS: NAS as backup target is almost always a bad idea (price / performance)
soncscy
Veteran
Posts: 643
Liked: 312 times
Joined: Aug 04, 2019 2:57 pm
Full Name: Harvey
Contact:

Re: FEATURE REQUEST - Add Capacity Tier Extent Types

Post by soncscy » 1 person likes this post

Hey Marco,

I've heard the idea before and I know some other vendors do this, but I want to do a sanity check on this:

> I'll give you an example: nas with some fast disks and some capacitive ones, it would be useful to create the performance tier with ssd disks and the capacity tier with slower disks .. obviously always using refs or xfs + immutability.

> Currently I have to create a copy job, with the result of having some duplicate chains on both targets

How do you mean on these two points? Backup copies only move the incremental data necessary to create a restore point that represents the machine state at that time.

Capacity Tier works the exact same way. Where there's a difference is that visually you'll see more restore points as a result of the Backup Copy, but if you're using XFS/ReFS, you're effectively moving the same volume of data, it just is visualized differently.

I'm not against your idea, but it works only with "simple" backups, that is, never changing. With the potential for the backup files to constantly be changing (forever forward, reverse incremental), I don't see how simple tiering can work unless it does what Veeam does with Tape and periodically dumps a fully inflated backup file (periodic full) to the storage, which increases your space usage instead of keeping it slim.

I actually think Backup Copy hits your needs really well, it's just in a different presentation than you're expecting.
mamosorre84
Veeam Legend
Posts: 336
Liked: 34 times
Joined: Oct 24, 2016 3:56 pm
Full Name: Marco Sorrentino
Location: Ancona - Italy
Contact:

Re: FEATURE REQUEST - Add Capacity Tier Extent Types

Post by mamosorre84 »

Hi Harvey,

i would like to use ssd disks and capacitive disks on prem, and i would like my target repository to be immutable.

The theory says that to use the fast clone I have to use the data locality on the performance tier, and therefore I cannot split my disks at this level; so if I want to use these two types of discs within a SOBR I am already in trouble.

The most elegant and practical solution would be the one proposed, so as not to have the effort of an additional job (backup copy) to manage and configure.

Regarding the second point, the "move to capacity tier" option assures me that I am going to move only the inactive backup chains, with the result that these will only exist on the capacity tier and no longer on the performance tier.

Perhaps this thing can also be achieved by setting the retention on the backup and backup copy correctly, but in my opinion it is more "complicated" and with the risk that it does not work as it should (for example in the event of a fail of one or more copies job).

If you think that the functionality can be useful but you don't want to change the capacity tier function, you could for example insert another performance tier, for example "Performance Tier Fast" and "Performance Tier Slow" and allow an offload of data between two.
soncscy
Veteran
Posts: 643
Liked: 312 times
Joined: Aug 04, 2019 2:57 pm
Full Name: Harvey
Contact:

Re: FEATURE REQUEST - Add Capacity Tier Extent Types

Post by soncscy »

> The theory says that to use the fast clone I have to use the data locality on the performance tier, and therefore I cannot split my disks at this level; so if I want to use these two types of discs within a SOBR I am already in trouble.

Sorry I feel I'm missing something -- why not just two SOBRs, one with SSDs, one with spinning disk drives?

> The most elegant and practical solution would be the one proposed, so as not to have the effort of an additional job (backup copy) to manage and configure.

Indeed, a backup copy is an extra job and repository, but capacity tier is many offload jobs and an S3 provider and permissions and the network connection in between! ;) I'm not trying to dissuade from capacity tier (it works quite well), but even if the offloading could go to local disks, you don't have any less jobs to manage. You just have few abilities to tweak and adjust it.

Basically, I get exactly what you're going for, but in fact, Backup Copy already allows this, and it's pretty common to target slower deduplication appliances for long term storage to do exactly what you're hoping today, with a few clicks in the UI.
mamosorre84
Veeam Legend
Posts: 336
Liked: 34 times
Joined: Oct 24, 2016 3:56 pm
Full Name: Marco Sorrentino
Location: Ancona - Italy
Contact:

Re: FEATURE REQUEST - Add Capacity Tier Extent Types

Post by mamosorre84 »

I was talking about backup file placement for SOBR: if I could have used performance policy I would have been okay! :)

Anyway, it doesn't matter .. I accept your advice, but I remain of the opinion that it can be a good functionality, at least for my environment! :D
Post Reply

Who is online

Users browsing this forum: No registered users and 9 guests