* [pbs-devel] [PATCH] tape: forbid operations on a s3 datastore
@ 2025-07-23 14:31 Dominik Csapak
2025-07-23 18:37 ` [pbs-devel] applied: " Thomas Lamprecht
2025-07-23 19:51 ` [pbs-devel] " Thomas Lamprecht
0 siblings, 2 replies; 7+ messages in thread
From: Dominik Csapak @ 2025-07-23 14:31 UTC (permalink / raw)
To: pbs-devel
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
* (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
Note that we could make the check in the restore case more efficient
(since we already have the parsed DataStore struct), but this to be done
only once for each tape restore operation and most of the time there
aren't that many datastores involved, so the extra runtime cost is
probably not that bad vs having multiple code paths for the error.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
---
pbs-config/src/datastore.rs | 13 +++++++++++++
src/api2/config/tape_backup_job.rs | 7 +++++++
src/api2/tape/backup.rs | 6 +++++-
src/api2/tape/restore.rs | 6 +++++-
src/tape/mod.rs | 12 +++++++++++-
5 files changed, 41 insertions(+), 3 deletions(-)
diff --git a/pbs-config/src/datastore.rs b/pbs-config/src/datastore.rs
index 396dcb37..5a5553db 100644
--- a/pbs-config/src/datastore.rs
+++ b/pbs-config/src/datastore.rs
@@ -113,3 +113,16 @@ pub fn complete_calendar_event(_arg: &str, _param: &HashMap<String, String>) ->
.map(|s| String::from(*s))
.collect()
}
+
+/// Returns the datastore backend type from it's name
+pub fn datastore_backend_type(store: &str) -> Result<pbs_api_types::DatastoreBackendType, Error> {
+ let (config, _) = config()?;
+ let store_config: DataStoreConfig = config.lookup("datastore", &store)?;
+
+ let backend_config: pbs_api_types::DatastoreBackendConfig = serde_json::from_value(
+ pbs_api_types::DatastoreBackendConfig::API_SCHEMA
+ .parse_property_string(store_config.backend.as_deref().unwrap_or(""))?,
+ )?;
+
+ Ok(backend_config.ty.unwrap_or_default())
+}
diff --git a/src/api2/config/tape_backup_job.rs b/src/api2/config/tape_backup_job.rs
index f2abf652..786acde0 100644
--- a/src/api2/config/tape_backup_job.rs
+++ b/src/api2/config/tape_backup_job.rs
@@ -13,6 +13,8 @@ use pbs_api_types::{
use pbs_config::CachedUserInfo;
+use crate::tape::assert_datastore_type;
+
#[api(
input: {
properties: {},
@@ -71,6 +73,8 @@ pub fn create_tape_backup_job(
job: TapeBackupJobConfig,
_rpcenv: &mut dyn RpcEnvironment,
) -> Result<(), Error> {
+ assert_datastore_type(&job.setup.store)?;
+
let _lock = pbs_config::tape_job::lock()?;
let (mut config, _digest) = pbs_config::tape_job::config()?;
@@ -180,6 +184,9 @@ pub fn update_tape_backup_job(
delete: Option<Vec<DeletableProperty>>,
digest: Option<String>,
) -> Result<(), Error> {
+ if let Some(store) = &update.setup.store {
+ assert_datastore_type(&store)?;
+ }
let _lock = pbs_config::tape_job::lock()?;
let (mut config, expected_digest) = pbs_config::tape_job::config()?;
diff --git a/src/api2/tape/backup.rs b/src/api2/tape/backup.rs
index 31293a9a..16a26b83 100644
--- a/src/api2/tape/backup.rs
+++ b/src/api2/tape/backup.rs
@@ -20,7 +20,7 @@ use pbs_config::CachedUserInfo;
use pbs_datastore::backup_info::{BackupDir, BackupInfo};
use pbs_datastore::{DataStore, StoreProgress};
-use crate::tape::TapeNotificationMode;
+use crate::tape::{assert_datastore_type, TapeNotificationMode};
use crate::{
server::{
jobstate::{compute_schedule_status, Job, JobState},
@@ -140,6 +140,8 @@ pub fn do_tape_backup_job(
schedule: Option<String>,
to_stdout: bool,
) -> Result<String, Error> {
+ assert_datastore_type(&setup.store)?;
+
let job_id = format!(
"{}:{}:{}:{}",
setup.store,
@@ -302,6 +304,8 @@ pub fn backup(
force_media_set: bool,
rpcenv: &mut dyn RpcEnvironment,
) -> Result<Value, Error> {
+ assert_datastore_type(&setup.store)?;
+
let auth_id: Authid = rpcenv.get_auth_id().unwrap().parse()?;
check_backup_permission(&auth_id, &setup.store, &setup.pool, &setup.drive)?;
diff --git a/src/api2/tape/restore.rs b/src/api2/tape/restore.rs
index 2cc1baab..9e55cae2 100644
--- a/src/api2/tape/restore.rs
+++ b/src/api2/tape/restore.rs
@@ -37,7 +37,7 @@ use pbs_tape::{
};
use crate::backup::check_ns_modification_privs;
-use crate::tape::TapeNotificationMode;
+use crate::tape::{assert_datastore_type, TapeNotificationMode};
use crate::{
tape::{
drive::{lock_tape_device, request_and_load_media, set_tape_device_state, TapeDriver},
@@ -354,6 +354,10 @@ pub fn restore(
bail!("no datastores given");
}
+ for (_, (target, _)) in &used_datastores {
+ assert_datastore_type(target.name())?;
+ }
+
for (target, namespaces) in used_datastores.values() {
check_datastore_privs(
&user_info,
diff --git a/src/tape/mod.rs b/src/tape/mod.rs
index f276f948..69fc373b 100644
--- a/src/tape/mod.rs
+++ b/src/tape/mod.rs
@@ -1,6 +1,6 @@
//! Magnetic tape backup
-use anyhow::{format_err, Error};
+use anyhow::{bail, format_err, Error};
use proxmox_auth_api::types::Userid;
use proxmox_sys::fs::{create_path, CreateOptions};
@@ -155,3 +155,13 @@ impl From<(Option<Userid>, Option<NotificationMode>)> for TapeNotificationMode {
}
}
}
+
+/// Asserts that the datastore is on a supported backend type
+pub fn assert_datastore_type(store: &str) -> Result<(), Error> {
+ match pbs_config::datastore::datastore_backend_type(store)? {
+ pbs_api_types::DatastoreBackendType::Filesystem => Ok(()),
+ pbs_api_types::DatastoreBackendType::S3 => {
+ bail!("direct s3/tape operations are not supported")
+ }
+ }
+}
--
2.39.5
_______________________________________________
pbs-devel mailing list
pbs-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel
^ permalink raw reply [flat|nested] 7+ messages in thread
* [pbs-devel] applied: [PATCH] tape: forbid operations on a s3 datastore
2025-07-23 14:31 [pbs-devel] [PATCH] tape: forbid operations on a s3 datastore Dominik Csapak
@ 2025-07-23 18:37 ` Thomas Lamprecht
2025-07-23 19:51 ` [pbs-devel] " Thomas Lamprecht
1 sibling, 0 replies; 7+ messages in thread
From: Thomas Lamprecht @ 2025-07-23 18:37 UTC (permalink / raw)
To: pbs-devel, Dominik Csapak
On Wed, 23 Jul 2025 16:31:52 +0200, Dominik Csapak wrote:
> 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
> * (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
>
> [...]
Applied, thanks!
[1/1] tape: forbid operations on a s3 datastore
commit: d8634d30f4b14983a13ff1d07d984f070aac0231
_______________________________________________
pbs-devel mailing list
pbs-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [pbs-devel] [PATCH] tape: forbid operations on a s3 datastore
2025-07-23 14:31 [pbs-devel] [PATCH] tape: forbid operations on a s3 datastore Dominik Csapak
2025-07-23 18:37 ` [pbs-devel] applied: " Thomas Lamprecht
@ 2025-07-23 19:51 ` Thomas Lamprecht
2025-07-24 6:50 ` Dominik Csapak
1 sibling, 1 reply; 7+ messages in thread
From: Thomas Lamprecht @ 2025-07-23 19:51 UTC (permalink / raw)
To: Proxmox Backup Server development discussion, Dominik Csapak
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [pbs-devel] [PATCH] tape: forbid operations on a s3 datastore
2025-07-23 19:51 ` [pbs-devel] " Thomas Lamprecht
@ 2025-07-24 6:50 ` Dominik Csapak
2025-07-26 21:19 ` Laurent GUERBY
0 siblings, 1 reply; 7+ messages in thread
From: Dominik Csapak @ 2025-07-24 6:50 UTC (permalink / raw)
To: Thomas Lamprecht, Proxmox Backup Server development discussion
Hi
On 7/23/25 21:51, Thomas Lamprecht wrote:
> 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.
true>
>
>> * (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.
yeah, i agree with you. I probably was too eager to find a rationale to
not allow this at all, since I feared that making tape -> s3 backups
(or vice versa) will make problems for too many people (that don't
have high bandwidth uplinks, etc.)
_______________________________________________
pbs-devel mailing list
pbs-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [pbs-devel] [PATCH] tape: forbid operations on a s3 datastore
2025-07-24 6:50 ` Dominik Csapak
@ 2025-07-26 21:19 ` Laurent GUERBY
2025-07-28 7:25 ` Christian Ebner
0 siblings, 1 reply; 7+ messages in thread
From: Laurent GUERBY @ 2025-07-26 21:19 UTC (permalink / raw)
To: Proxmox Backup Server development discussion, Thomas Lamprecht
On Thu, 2025-07-24 at 08:50 +0200, Dominik Csapak wrote:
> Hi
>
> On 7/23/25 21:51, Thomas Lamprecht wrote:
> > 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
Hi,
With my CISO hat on I see tapes physically removed from the tape
library as an essential security tool providing the "offline" property
to one copy of the backups, this is orthogonal to "off-site" being
discussed here.
S3 is typically online, even if some providers offer S3 to
tape/offline.
Bandwith/delay constraints especially for full restore after a
successful deep cyberattack might favor an "on-site "offline" tape
backup for many organization.
Backup solutions like Veeam already provide "object to tape".
I think it would be nice to have this feature in the PBS roadmap if
there's no technical roadblock to having the same feature set for S3
and directory datastore, including tape.
Sincerely,
Laurent GUERBY
_______________________________________________
pbs-devel mailing list
pbs-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [pbs-devel] [PATCH] tape: forbid operations on a s3 datastore
2025-07-26 21:19 ` Laurent GUERBY
@ 2025-07-28 7:25 ` Christian Ebner
2025-07-28 18:08 ` Laurent GUERBY
0 siblings, 1 reply; 7+ messages in thread
From: Christian Ebner @ 2025-07-28 7:25 UTC (permalink / raw)
To: pbs-devel
On 7/27/25 12:37 AM, Laurent GUERBY wrote:
> On Thu, 2025-07-24 at 08:50 +0200, Dominik Csapak wrote:
>> Hi
>>
>> On 7/23/25 21:51, Thomas Lamprecht wrote:
>>> 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
>
> Hi,
>
> With my CISO hat on I see tapes physically removed from the tape
> library as an essential security tool providing the "offline" property
> to one copy of the backups, this is orthogonal to "off-site" being
> discussed here.
>
> S3 is typically online, even if some providers offer S3 to
> tape/offline.
>
> Bandwith/delay constraints especially for full restore after a
> successful deep cyberattack might favor an "on-site "offline" tape
> backup for many organization.
>
> Backup solutions like Veeam already provide "object to tape".
>
> I think it would be nice to have this feature in the PBS roadmap if
> there's no technical roadblock to having the same feature set for S3
> and directory datastore, including tape.
Hi,
please do open an issue on https://bugzilla.proxmox.com for this, maybe
also linking to this thread via the following link:
https://lore.proxmox.com/pbs-devel/ad4d893fad70444ed36ebcd1cefbf58081d905e5.camel@guerby.net/T
By this you can get also notifications on status progress, I will have a
look at how to implement S3 <-> tape as well.
Thanks,
Chris
_______________________________________________
pbs-devel mailing list
pbs-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [pbs-devel] [PATCH] tape: forbid operations on a s3 datastore
2025-07-28 7:25 ` Christian Ebner
@ 2025-07-28 18:08 ` Laurent GUERBY
0 siblings, 0 replies; 7+ messages in thread
From: Laurent GUERBY @ 2025-07-28 18:08 UTC (permalink / raw)
To: Proxmox Backup Server development discussion
On Mon, 2025-07-28 at 09:25 +0200, Christian Ebner wrote:
> On 7/27/25 12:37 AM, Laurent GUERBY wrote:
> > On Thu, 2025-07-24 at 08:50 +0200, Dominik Csapak wrote:
> > > Hi
> > >
> > > On 7/23/25 21:51, Thomas Lamprecht wrote:
> > > > 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
> >
> > Hi,
> >
> > With my CISO hat on I see tapes physically removed from the tape
> > library as an essential security tool providing the "offline" property
> > to one copy of the backups, this is orthogonal to "off-site" being
> > discussed here.
> >
> > S3 is typically online, even if some providers offer S3 to
> > tape/offline.
> >
> > Bandwith/delay constraints especially for full restore after a
> > successful deep cyberattack might favor an "on-site "offline" tape
> > backup for many organization.
> >
> > Backup solutions like Veeam already provide "object to tape".
> >
> > I think it would be nice to have this feature in the PBS roadmap if
> > there's no technical roadblock to having the same feature set for S3
> > and directory datastore, including tape.
>
> Hi,
>
> please do open an issue on https://bugzilla.proxmox.com for this, maybe
> also linking to this thread via the following link:
> https://lore.proxmox.com/pbs-devel/ad4d893fad70444ed36ebcd1cefbf58081d905e5.camel@guerby.net/T
>
> By this you can get also notifications on status progress, I will have a
> look at how to implement S3 <-> tape as well.
Done : https://bugzilla.proxmox.com/show_bug.cgi?id=6582
Sincerely,
Laurent GUERBY
_______________________________________________
pbs-devel mailing list
pbs-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2025-07-28 18:12 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-07-23 14:31 [pbs-devel] [PATCH] tape: forbid operations on a s3 datastore Dominik Csapak
2025-07-23 18:37 ` [pbs-devel] applied: " Thomas Lamprecht
2025-07-23 19:51 ` [pbs-devel] " Thomas Lamprecht
2025-07-24 6:50 ` Dominik Csapak
2025-07-26 21:19 ` Laurent GUERBY
2025-07-28 7:25 ` Christian Ebner
2025-07-28 18:08 ` Laurent GUERBY
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.