QuObject Limitation and object store question

[mwhite]

Hi All,
I have recently configured a client with QuObject as the primary backup target, on the QuObject site it shows the below table on its storage limitation.

Size of VM backup Storage Optimization option
< 16 TB Local Target (Large Blocks)
< 4 TB Local Target
< 2 TB LAN Target
< 1 TB WAN Target

Does anyone know if this applies to the whole job, a VM in the job or a disk in a VM?
Is it referring to size of the source VM/s or the amount of space used by the backup chain?

For my object storage question, is there a way to remove a single restore point from the backups? EG if I have 10 fulls and 7 incrementals, can I manually delete one of the full points (obviously not the one the incrementals depend on)?

[Mildur]

Hi mwhite

Those are job settings and will be applied to the entire job.
https://helpcenter.veeam.com/docs/backu ... timization

It specifies which block size we use when storing our backup files.
Many on-premise object storage appliance vendors recommend to use a higher block size, because it requires fewer objects to store a backup. Such appliances benefit from fewer objects because they are perform better with larger objects.
The default is 1MB, which is LAN Target from your list. Please note, if you choose a higher block size, incremental backups will require more space on object storage. Changing it to 4 MB (4 TB Local Target), will require approximately 2x more storage space.

For my object storage question, is there a way to remove a single restore point from the backups? EG if I have 10 fulls and 7 incrementals, can I manually delete one of the full points (obviously not the one the incrementals depend on)?

No, you cannot remove a single restore point. But why do you want to remove a full backup? Object Storage is forever forward incremental. Even if you could remove a full backup, you would gain only a small amount of free space.

Best,
Fabian

[mwhite]

Thanks Fabian,
So just to clarify, if I have the job set to 4MB blocks and the total consumed space including incrementals exceeds 16TB will the job fail? Or is it that if an individual source VM exceeds 16TB will it fail?

Re removing a single point, I have an incomplete full backup which Veeam says is only using <1MB of space, but the storage is down ~3.6TB (source VM is over 4TB).

I need to log a case with support though as the backups aren't playing nice ATM.

EDIT: The table in my original post lost it's spacing, heres a slightly better version using | to split the columns.
Size of VM backup | Storage Optimization option
< 16 TB | Local Target (Large Blocks)
< 4 TB | Local Target
< 2 TB | LAN Target
< 1 TB | WAN Target

[Gostev]

To be clear, Veeam does not impose any limitation on backup sizes, nor most object storage out there. This appears to be some QuObject-specific limitations, so you should better clarify this directly with QNAP.

I can only say this is the first time I see object storage vendor imposing such a low limitation, 4TB with the default setting. Honestly, this does not give me much confidence about its maturity...

[mwhite]

Thanks Gostev,
I'll contact their support and see what they say.
The limitation is very far down the page so I wouldn't be surprised if people miss it.

QuObject is in the Veeam supported list, I assume though the testing is just 'does it work and follow the spec for S3'. It would probably be impossible to test for all possible limitations in systems.

[rennerstefan]

Hi,
thanks for bringing that up, we will also check on our side with them to understand what they talk about here.

[mwhite]

Thanks,
I'll update this thread with what I hear as well.

[mwhite]

Finally heard back from QNAP support. So the limitation they refer to is the inode limit of the filesystem, not some weird and wonderful limitation with QNAPs.

[Gostev]

Well, that's a really weird response as object storage has no file system in principle. There are no files, folders or anything like that. In fact, that's exactly what distinguishes it from block and file storage. And also is what makes me so happy about object storage, as we no longer have to deal with weird file system limitations and quirks (like the infamous struggle with ReFS in its early days). Instead, WE are the file system!

[rennerstefan]

we are still waiting for a response on our side.
I will update this thread once we got some details on how it works on their end and what the limitation really means.

[mwhite]

Well, that's a really weird response as object storage has no file system in principle. There are no files, folders or anything like that. In fact, that's exactly what distinguishes it from block and file storage. And also is what makes me so happy about object storage, as we no longer have to deal with weird file system limitations and quirks (like the infamous struggle with ReFS in its early days). Instead, WE are the file system!

QuObjects is an app, it uses the existing Ext4 filesystem instead of provisioning a new block of raw storage for it. So it's kind of a hack, but also not really a limitation since 18TB with 64k chunks is just over 280m files. (if I understand how inodes work)

[Gostev]

Got it... this would indicate they did not bother building proper object storage and instead just bolted an S3 client on top of a regular file system.

It is really sad to see storage vendors approaching the need for object storage like that as this does nothing but gives a bad name to object storage as a whole. Customers are choosing object storage for better scalability, increased reliability, built-in transparent redundancy etc... in other words, for everything file systems like ext4 cannot deliver natively (and because they cannot).

[Andreas Neufert]

Operating System:
QTShero has no object number limitation. Max volume size is 5PB there.

QTS has a maximum volume size of 127.99TB and with the for Veeam recommended default 32KB "Bytes per inode" setting a 4B maximum number of objects.
For Veeam Backup & Replication my calculations showed that the number of objects there is way lower than the 4B even under worst case scenario.

In general many vendors that can expose their storages as well to NFS/SMB or other protocols use an underlaying filesystem and usually this is not a limiting factor.

If you are concerned with the 4B maximum at QTS, I suggest to go with the QTShero OS.