From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id E16581FF17C for ; Wed, 23 Jul 2025 21:50:26 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id E03DC1B815; Wed, 23 Jul 2025 21:51:45 +0200 (CEST) Message-ID: <931c8fa8-694e-43fe-9354-7ba752063b2c@proxmox.com> Date: Wed, 23 Jul 2025 21:51:09 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta To: Proxmox Backup Server development discussion , Dominik Csapak References: <20250723143152.3829064-1-d.csapak@proxmox.com> Content-Language: en-US From: Thomas Lamprecht In-Reply-To: <20250723143152.3829064-1-d.csapak@proxmox.com> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1753300269117 X-SPAM-LEVEL: Spam detection results: 0 AWL -0.031 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pbs-devel] [PATCH] tape: forbid operations on a s3 datastore X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Proxmox Backup Server development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pbs-devel-bounces@lists.proxmox.com Sender: "pbs-devel" 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