Re: [bareos-users] space management on tape

2020-12-26 Thread 'Frank Kirschner' via bareos-users 
Thanks and yes, working with different pools will be a good thing for 
controlling the usage of the tapes. 

Thanks, Frank 

Am 26. Dezember 2020 18:49:53 MEZ schrieb Brock Palen 
:
>Your hunch is correct. Tape is linear and only appended to. Even
>systems like LTFS only append and never write data in hold of
>deleted/expired data. 
>
>This is one reason why many outlets full and incrementals on different
>pools and this different tapes. So they expire at similar times so the
>entire tape can be reclaimed. Not leaving one job with massively
>different retention time. 
>
>Sent from my iPhone
>Brock Palen
>989-277-6075
>
>> On Dec 26, 2020, at 12:32 PM, Spadajspadaj 
>wrote:
>> 
>> 
>> It's almost obvious if you look at possible medium states but to give
>you a verbose answer - the media can be read from any point but can
>only be appended at the end.
>> 
>> So if any job is being pruned/purged/deleted, it's just being
>"forgotten" by the database but is still present on the media where it
>originally was.
>> 
>> Oversimplifying a bit - a media life cycle is:
>> 
>> Purged -> Recycled -> Append -> Used/Full -> Purged again.
>> 
>> So, as you can see, there is no (de)fragmentation. A volume is
>getting appended to, then it's getting recycled. Simple as that.
>> 
>> With disk-based storage it's getting a bit more complicated with
>dynamicaly created volumes, single-job volumes and auto-truncate on
>purge.
>> 
>> On 26/12/2020 17:18, 'Frank Cherry' via bareos-users wrote:
>>> 
>>> Hi there,
>>> a question how Bareos managed space on tape:
>>> Hypothetc:
>>> 
>>> On a LTO tape are stored in this order 3 jobs:
>>> 1: 3 TB
>>> 2: 2 TB
>>> 3: 1 TB
>>> 
>>> Job 1 is deleted.
>>> Now a new job is queued, the spooling file has a size of 2 TB.
>>> 
>>> Will now the SD despool it 
>>> a) on position 4 of the tape (append) [this is what I think]
>>> or
>>> b) replace position1 because the is availabe space
>>> 
>>> So, thinking about fragmentation would be one part of a backup
>strategy when working with tapes.
>>> 
>>> Thanks and all the best, Frank
>>> 
>>> 
>>> -- 
>>> You received this message because you are subscribed to the Google
>Groups "bareos-users" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>send an email to bareos-users+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>https://groups.google.com/d/msgid/bareos-users/b5b7f195-056e-4391-99f0-6de9b0b87129n%40googlegroups.com.
>> -- 
>> You received this message because you are subscribed to the Google
>Groups "bareos-users" group.
>> To unsubscribe from this group and stop receiving emails from it,
>send an email to bareos-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>https://groups.google.com/d/msgid/bareos-users/55470d56-be2b-8a22-496a-c0120426c902%40gmail.com.
>
>-- 
>You received this message because you are subscribed to a topic in the
>Google Groups "bareos-users" group.
>To unsubscribe from this topic, visit
>https://groups.google.com/d/topic/bareos-users/iBMyqlxPn-A/unsubscribe.
>To unsubscribe from this group and all its topics, send an email to
>bareos-users+unsubscr...@googlegroups.com.
>To view this discussion on the web visit
>https://groups.google.com/d/msgid/bareos-users/516B15B7-AA4C-45D8-9AC4-60E6A6EC55F5%40mlds-networks.com.

-- 
You received this message because you are subscribed to the Google Groups 
"bareos-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to bareos-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/bareos-users/BE1A6858-9A4D-4D63-B08D-634F6A05755E%40celebrate.de.

Re: [bareos-users] space management on tape

2020-12-26 Thread Brock Palen 
Your hunch is correct. Tape is linear and only appended to. Even systems like 
LTFS only append and never write data in hold of deleted/expired data. 

This is one reason why many outlets full and incrementals on different pools 
and this different tapes. So they expire at similar times so the entire tape 
can be reclaimed. Not leaving one job with massively different retention time. 

Sent from my iPhone
Brock Palen
989-277-6075

> On Dec 26, 2020, at 12:32 PM, Spadajspadaj  wrote:
> 
> 
> It's almost obvious if you look at possible medium states but to give you a 
> verbose answer - the media can be read from any point but can only be 
> appended at the end.
> 
> So if any job is being pruned/purged/deleted, it's just being "forgotten" by 
> the database but is still present on the media where it originally was.
> 
> Oversimplifying a bit - a media life cycle is:
> 
> Purged -> Recycled -> Append -> Used/Full -> Purged again.
> 
> So, as you can see, there is no (de)fragmentation. A volume is getting 
> appended to, then it's getting recycled. Simple as that.
> 
> With disk-based storage it's getting a bit more complicated with dynamicaly 
> created volumes, single-job volumes and auto-truncate on purge.
> 
> On 26/12/2020 17:18, 'Frank Cherry' via bareos-users wrote:
>> 
>> Hi there,
>> a question how Bareos managed space on tape:
>> Hypothetc:
>> 
>> On a LTO tape are stored in this order 3 jobs:
>> 1: 3 TB
>> 2: 2 TB
>> 3: 1 TB
>> 
>> Job 1 is deleted.
>> Now a new job is queued, the spooling file has a size of 2 TB.
>> 
>> Will now the SD despool it 
>> a) on position 4 of the tape (append) [this is what I think]
>> or
>> b) replace position1 because the is availabe space
>> 
>> So, thinking about fragmentation would be one part of a backup strategy when 
>> working with tapes.
>> 
>> Thanks and all the best, Frank
>> 
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "bareos-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to bareos-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/bareos-users/b5b7f195-056e-4391-99f0-6de9b0b87129n%40googlegroups.com.
> -- 
> You received this message because you are subscribed to the Google Groups 
> "bareos-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to bareos-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/bareos-users/55470d56-be2b-8a22-496a-c0120426c902%40gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 
"bareos-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to bareos-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/bareos-users/516B15B7-AA4C-45D8-9AC4-60E6A6EC55F5%40mlds-networks.com.

Re: [bareos-users] space management on tape

2020-12-26 Thread Spadajspadaj 
It's almost obvious if you look at possible medium states but to give 
you a verbose answer - the media can be read from any point but can only 
be appended at the end.


So if any job is being pruned/purged/deleted, it's just being 
"forgotten" by the database but is still present on the media where it 
originally was.


Oversimplifying a bit - a media life cycle is:

Purged -> Recycled -> Append -> Used/Full -> Purged again.

So, as you can see, there is no (de)fragmentation. A volume is getting 
appended to, then it's getting recycled. Simple as that.


With disk-based storage it's getting a bit more complicated with 
dynamicaly created volumes, single-job volumes and auto-truncate on purge.


On 26/12/2020 17:18, 'Frank Cherry' via bareos-users wrote:


Hi there,
a question how Bareos managed space on tape:
Hypothetc:

On a LTO tape are stored in this order 3 jobs:
1: 3 TB
2: 2 TB
3: 1 TB

Job 1 is deleted.
Now a new job is queued, the spooling file has a size of 2 TB.

Will now the SD despool it
a) on position 4 of the tape (append) [this is what I think]
or
b) replace position1 because the is availabe space

So, thinking about fragmentation would be one part of a backup 
strategy when working with tapes.


Thanks and all the best, Frank


--
You received this message because you are subscribed to the Google 
Groups "bareos-users" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to bareos-users+unsubscr...@googlegroups.com 
.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/bareos-users/b5b7f195-056e-4391-99f0-6de9b0b87129n%40googlegroups.com 
.


--
You received this message because you are subscribed to the Google Groups 
"bareos-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to bareos-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/bareos-users/55470d56-be2b-8a22-496a-c0120426c902%40gmail.com.