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 <[email protected]>: >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 <[email protected]> >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 [email protected]. >>> 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 [email protected]. >> 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 >[email protected]. >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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/bareos-users/BE1A6858-9A4D-4D63-B08D-634F6A05755E%40celebrate.de.
