all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox Backup Server development discussion
	<pbs-devel@lists.proxmox.com>,
	Dominik Csapak <d.csapak@proxmox.com>
Subject: Re: [pbs-devel] [PATCH] tape: forbid operations on a s3 datastore
Date: Wed, 23 Jul 2025 21:51:09 +0200	[thread overview]
Message-ID: <931c8fa8-694e-43fe-9354-7ba752063b2c@proxmox.com> (raw)
In-Reply-To: <20250723143152.3829064-1-d.csapak@proxmox.com>

This was fine and I applied it but still have some comments on one
of the arguments that would indicate that this never makes sense to
have, as IMO it can.

Am 23.07.25 um 16:31 schrieb Dominik Csapak:
> namely:
> * backup to tape from s3 (including a configuring such a job)
> * restore to s3 from tape
> 
> It does not work currently, but it probably does not make sense to allow
> that at all for several reasons:
> * both are designed to be 'off-site', so copying data from one off-site
>   location to another directly does not make sense most of the time

S3 can be off-site, but it can be also the single main storage for
huge amount of data in a environment. W.g., if one's applications
and use cases all support S3 and one has a performant local storage
providing that, why not use that also for the "hot" backup store, one
can backup directly onto a S3-backed datastore after all, and then
sync to tape for relatively cheap off-site cold storage.

And not all countries have slow internet, 5 to 25 Gbps connections are a
thing (e.g. provided by the swiss ISP Fiber7), as are Dark Fiber connections
between sites, which means that even if the S3 storage is indeed offsite,
it might be faster to pull data from there than the tape can be written too.


> * (modern) tape operations can reach relatively high speeds (> 300MB/s)
>   and up/downloading to an (most likely remote) s3 storage will slow
>   down the tape

Does it really? I'd expect that local S3 storage backed by good HW should
be able to get at least to 300 MB/s.

And even if, what's better, not being able to make a tape backup because
one e.g. has not an intermediate storage with multiple TB of space available
on the PBS directly, or having to wait a bit longer?

Again, totally justified stop-gap for now, but I would not write this
off as not making sense in general, as while for some setups your
points will be true, they doesn't necessarily have to be. So if there
is actual user demand, which is a different topic, I'd see it worthwhile
into looking more closely in what it would take to somewhat sanely support
such an use case.


_______________________________________________
pbs-devel mailing list
pbs-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel


  parent reply	other threads:[~2025-07-23 19:50 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-23 14:31 Dominik Csapak
2025-07-23 18:37 ` [pbs-devel] applied: " Thomas Lamprecht
2025-07-23 19:51 ` Thomas Lamprecht [this message]
2025-07-24  6:50   ` [pbs-devel] " Dominik Csapak
2025-07-26 21:19     ` Laurent GUERBY
2025-07-28  7:25       ` Christian Ebner
2025-07-28 18:08         ` Laurent GUERBY

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=931c8fa8-694e-43fe-9354-7ba752063b2c@proxmox.com \
    --to=t.lamprecht@proxmox.com \
    --cc=d.csapak@proxmox.com \
    --cc=pbs-devel@lists.proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal