"Timo Neuvonen" <timo-n...@tee-en.net> kirjoitti viestissä news:hfjoo9$ks...@ger.gmane.org... > > "Simon J Mudd" <sjm...@pobox.com> kirjoitti viestissä > news:m3fx7mkdv3....@mad06.wl0.org... >> timo-n...@tee-en.net ("Timo Neuvonen") writes: >> >>> "Simon J Mudd" <sjm...@pobox.com> kirjoitti viestissä >> >> ... >> >>> > Yes, but that's what I'm trying to avoid. I realise that I MUST have >>> > sufficient >>> > space really for at least 2 full backups plus some extra for >>> > incrementals >>> > but I don't want to worry about the details. Therefore I want to >>> > configure >>> >>> You said you don't want to worry about the details. However, one such >>> very >>> strong detail is the schedule you already have specified, it says to run >>> a >>> full backup once a month. Required retention time is closely related to >>> this, and needs to be specified too. >> >> Again, I think you're missing the point. You are right, in a business >> environment you do want to decide to do X full backups every certain >> period of time, X incrementals etc. and then you need to do some >> calculations to work out how much disk space you need for this. This >> value of course changes and you may later need to add more storage or >> tapes or whatever to accommodate these changes. >> >> Think of the normal HOME user who may have an interest in Bacula to >> backup data. He has a "unix" PC with disks occupying say 100GB of >> space. So he buys himself a 1TB external USB disk and wants to use >> that for backups. If it's dedicated he'll want to use ALL the space >> for backups and keep as much as he can. So he's likely to want to do >> perhaps a single weekly or monthly backup followed by incrementals in >> between. Exactly how many backups he keeps is relatively unimportant. >> >> And for this type of scenario bacula is tricky (from what I can see) >> to setup. I've had multiple problems (due to misconfiguration) of bacula >> not labelling new disk devices in the pool and also when the disk starts >> to fill up of not removing the oldest backups. >> >> I'm not a backup "administrator" and have plenty of other distractions >> which prevent me properly working out how to get bacula running properly. >> That's why I suggested a recipe for the type of configuration I suggest >> might be extremely useful. >> >>> Since now you haven't specified the volume retention, Bacula uses its >>> internal default which is one year, 365 days. You have to specify a >>> shorter >>> volume retention time if you want to be able to recycle the volumes >>> sooner. >> >> But I dont' want retention to depend on time, but disk usage. >> > > > > Bacula can use all disk space you allow it to use, that is controlled with > volume size and maximum number of volumes, that you had set to reasonable > values in the configuration. The volume retention time is just a minimum > time limit; if your disk space will allow it, the old data in un-recycled > volumes will still be available there after much longer time (in theory, > forever). I think this is what you wanted, so I can't see any actual > problem > there. But if you absolutely don't want to change the default volume > retention time to something that would fit to your application, there > isn't
> much else to do, I think. Explicitly specifying the volume retention time > is > the only way to make Bacula recycle the volumes in less than a year, since > 365 days is Bacula's internal default. > An update / a correction to the statement above: setting Purge Oldest Volume = yes in the pool specification will override any retention period to recycle a volume when more space is needed. In general, it is a very dangerous option, but I think it is exacly what you are looking for. Still, I would vote for relying on the decently set volume retention, and forgetting the above option. > > >> ... >> >>> Btw, you can use "list media" command to see the status of the existing >>> volumes. >> >> so while you can define how many volumes to have and their sizes you >> can't >> get bacula to purge based on these values? >> >> ... >> >>> > the "pool" to auto purge if it fills up. New full or incremental >>> > backups >>> > will create new volumes as needed, and the older ones will get purged. >>> >>> Actually, Bacula will recycle the existing volumes, that is, discard the >>> old >>> data in the volume, and use the same "recycled" volume again. So the >>> volume >>> name won't change (unless this is possible due to some very new Bacula >>> feature). >> >> That's fine. In the end I don't care howe the volumes are labelled, or if >> new ones are created or existing ones are reused. >> >>> Within reasonable limits (reasonable amount of disk space available), >>> this >>> should be possible with Bacula. >> >> So it sounds part of my problem has been to misunderstand the precise >> terms >> used in Bacula. It sounds like I don't want to purge the disk volumes, >> but >> to recycle them. So how do I configure this: >> >> - A fixed number of disk volumes of a predetermined size which will >> be "recycled" when no more space is left? Ideally the recycling in this >> simple >> case would be based on a FIFO type principal. >> > > > If you don't want to have _any_ minimum time limit for volume retention, > just set it to one second, which propably is the shortest value you can > specify. > > In theory, this can result in a situation that if your one full backup > would > consume more space than is designated for backup use, and recycling of the > first volume used for that backup would then happen before that backup is > finished. But if you prefer this, instead of seeing an error message in > this > obvious case of malfunctioning, go for it. > > Seriously, a more reasonable value might be one hour, or one day. But if > you > want, you can (at least you should, I guess no one has ever tried it) use > value of as short as one second. > > > >> Simon >> >> ------------------------------------------------------------------------------ >> Join us December 9, 2009 for the Red Hat Virtual Experience, >> a free event focused on virtualization and cloud computing. >> Attend in-depth sessions from your desk. Your couch. Anywhere. >> http://p.sf.net/sfu/redhat-sfdev2dev >> _______________________________________________ >> Bacula-users mailing list >> Bacula-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bacula-users >> > > > > ------------------------------------------------------------------------------ > Join us December 9, 2009 for the Red Hat Virtual Experience, > a free event focused on virtualization and cloud computing. > Attend in-depth sessions from your desk. Your couch. Anywhere. > http://p.sf.net/sfu/redhat-sfdev2dev > _______________________________________________ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users > ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
