[bareos-users] Restore Automatic Backup Bareos
Hello! Can anyone tell me if Bareos 16.2.4 has how to do automatic restore of backups made by it? -- 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 post to this group, send email to bareos-users@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [bareos-users] How to get parallel jobs working?
Hello Martin, >> I have a few comments. >> >> - Do you have really monolithic config files? They are bad to read >> and old school :-). > In reality the config files are split via the @ operator (one file for pools, > one for storage, one for job templates and schedules, and one for each of ca. > 100 clients in a subdirectory)... I just reduced it for better readability > and kept only one job for each pool. Since 16.2 you don't need the @ operator any more if you use the new directory structure. > >> - For me your configuration is more complex than needed. E.g. >> Storage definitions at Pools, Jobs and JobDefs is too much. > There is no Storage definition in the Jobs. But Indeed I could remove the > Storage= statement from the JobDefs without error (IIRC I got an error > message for that some time and some versions ago). Sorry, I saw the catalog backup job has a storage definition. >> Probably this complex configuration is the reason for your >> challenge. > Yes, but I see no way to reduce complexity... Sadly Bareos still thinks in > "Tapes", frankly the limit of one concurrent Job per "Device" is hard to work > around... So I have to split Full, Diff and Incr for different retention > periods, and also split in different Pool sets in an attempt to get at lease > partial parallelism. Or more then one device per storage definition. Another way could be spooling, but I never worked with this. Cleaning the JobDefs and Storage definition should make your configuration more clear and straight. Regards, Stefan -- *CaC, Computer and Communication* Inhaber Stefan Klatt End-2-End Senior Network Consultant CISSP / CISM / ISO27001 Lead Implementer / TOGAF9 Badges: https://www.youracclaim.com/users/stefan-klatt Triftstrasse 9 60528 Frankfurt Germany USt-IdNr.: DE260461592 Tel.: +49-(0)172-6807809 Tel.: +49-(0)69-67808-900 Fax: +49-(0)69-67808-837 Email: stefan.kl...@cac-netzwerk.de Profil: http://www.cac-netzwerk.de/profil -- 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 post to this group, send email to bareos-users@googlegroups.com. For more options, visit https://groups.google.com/d/optout. smime.p7s Description: S/MIME Cryptographic Signature
Re: [bareos-users] Super slow query after upgrade to 17.2 from 16.2
Hi there, after disabling the accurate mode for a few days and re-enabling it, things are working well again. Maybe restarting the bareos machine also helped. So for me the problem is solved. Greets Stephan Am 27.02.2018 22:55 schrieb Stephan Hermann: Hi again, What can I do to analyze/fix this? would it be possible/reasonable to clean up all the "accurate mode" information and start from zero? If yes, how can I do this? Unfortunately I'm not that much experienced with mySQL databases... Thanks for your support and many greets Stephan Am 25.02.2018 um 00:49 schrieb Stephan Hermann: Hi, it seems that I run into this issue, too. I just upgraded from 16.2.7 to 17.2.5 (from subscription repo) and updated the database scheme from 2004 to 2171. Since then incremental backups with a lot of files hang at 'Sending Accurate information.' There is one mysql process at 100% cpu, but I can't see any relevant disk activity (iotop -o). Killing the queries inside mySQL allow me to continue the jobs, but the result looks like a full job, not an incremental. Some outputs: mysql> analyze table File; +-+-+--+--+ | Table | Op | Msg_type | Msg_text | +-+-+--+--+ | bareos.File | analyze | status | OK | +-+-+--+--+ 1 row in set (0.04 sec) mysql> optimize table File; +-+--+--+---+ | Table | Op | Msg_type | Msg_text | +-+--+--+---+ | bareos.File | optimize | note | Table does not support optimize, doing recreate + analyze instead | | bareos.File | optimize | status | OK | +-+--+--+---+ 2 rows in set (4 min 35.79 sec) What can I do to analyze/fix this? Thanks a lot and many greets Stephan Am 23.01.2018 um 22:26 schrieb Stephan Duehr: Hi, that looks like the query being run for accurate backup. I wonder why it's slower after the upgrade, as it's one table less for the join. This kind of problem with accurate has also been seen with the Bareos 16.2 DB schema in MySQL. Please check if the indexes on the File table match the ones defined in /usr/lib/bareos/scripts/ddl/creates/mysql.sql May be do ANALYZE TABLE File; in mysql again. If that does not help, disabling accurate for that job meanwhile may be better than killing the query. Regards, Stephan On 01/22/2018 02:30 PM, jsfre...@ludia.com wrote: Hi, After the upgrade to 17.2.4 (21 Sep 2017) I noticed the following sql query: SELECT Path.Path, T1.Name, T1.FileIndex, T1.JobId, LStat, DeltaSeq , Fhinfo, Fhnode FROM ( SELECT FileId, Job.JobId AS JobId, FileIndex, File.PathId AS PathId, File.Name AS Name, LStat , DeltaSeq, Fhinfo, Fhnode, Job.JobTDate AS JobTDate FROM Job, File, (SELECT MAX(JobTDate) AS JobTDate, PathId, FileName FROM (SELECT JobTDate, PathId, File.Name AS FileName FROM File JOIN Job USING (JobId) WHERE File.JobId IN (2897,2941,2963,3005,3023,3041) UNION ALL SELECT JobTDate, PathId, File.Name AS FileName FROM BaseFiles JOIN File USING (FileId) JOIN Job ON (BaseJobId = Job.JobId) WHERE BaseFiles.JobId IN (2897,2941,2963,3005,3023,3041) ) AS tmp GROUP BY PathId, FileName) AS T1 WHERE (Job.JobId IN (SELECT DISTINCT BaseJobId FROM BaseFiles WHERE JobId IN (2897,2941,2963,3005,3023,3041)) OR Job.JobId IN (2897,2941,2963,3005,3023,3041)) AND T1.JobTDate = Job.JobTDate AND Job.JobId = File.JobId AND T1.PathId = File.PathId AND T1.FileName = File.Name ) AS T1 JOIN Path ON (Path.PathId = T1.PathId) WHERE FileIndex > 0 ORDER BY T1.JobTDate, FileIndex ASC This query is taking a very long time to complete. Now it's been running over 13 hours and it is still running and taking 100% CPU. I'm using mysql 5.5, and the schema was upgraded when upgrading from 16.2 to 17.2. For the last few days I had to kill the queries, but it would be great to have this fixed. Any idea what is wrong here ? Thank you. -- 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 post to this group, send email to bareos-users@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[bareos-users] BPs for resolving full disk usage
BareOS users, I could use some direction for best practices to resolve when backups to disk fill the disk. Historically I've only been able to purge my entire installation (drop db, delete everything on disk) to get back to a working installation. I've tried deleting volumes with mixed success in the past. My current 16.2.4 installation was getting better having resolved issues with duplicate backups and not purging volumes. Now I'm in production and looks like perhaps I just had too long a retention period. Where can I begin to free some space and preserve the data and hosts I have backed up already? -- Russell Adamsrlad...@adamsinfoserv.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3 -- 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 post to this group, send email to bareos-users@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
