View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0001404 | bareos-core | director | public | 2021-11-25 11:24 | 2023-09-13 11:36 |
Reporter | Int | Assigned To | bruno-at-bareos | ||
Priority | high | Severity | major | Reproducibility | have not tried |
Status | closed | Resolution | fixed | ||
Platform | Linux | OS | CentOS | OS Version | 7 |
Product Version | 19.2.11 | ||||
Summary | 0001404: prune deletes virtualfull job from volume although the retention period is not expired | ||||
Description | executing the command prune volume=Bilddaten-0408 yes caused the virtualfull job, which was stored on this volume to be deleted, although the retention period of "9 months 6 days" was not expired. The volume was last written 1 day ago. The bconsole output was: Automatically selected Catalog: MyCatalog Using Catalog "MyCatalog" The current Volume retention period is: 9 months 6 days There are no more Jobs associated with Volume "Bilddaten-0408". Marking it purged. | ||||
Tags | No tags attached. | ||||
how can I recover the deleted virtualfull job from the now purged volume? | |
The bareos daemon sent this message: 25-Nov 11:00 bareos-dir JobId 0: Volume "Bilddaten-0408" has Volume Retention of 23846400 sec. and has 0 jobs that will be pruned 25-Nov 11:00 bareos-dir JobId 0: Pruning volume Bilddaten-0408: 0 Jobs have expired and can be pruned. 25-Nov 11:00 bareos-dir JobId 0: Volume "" contains no jobs after pruning. |
|
What was the purpose of running prune volume=Bilddaten-0408 yes ? If the media has not been used or truncated (depending of your configuration) you can still use bscan to reimport it inside the database. |
|
the pool contains other volumes that were expired. My goal was to truncate the expired volumes to gain free disk space. I ran the shell script #!/bin/bash for f in `echo "list volumes pool=Bilddaten" | bconsole | grep Bilddaten- | cut -d '|' -f3`; do echo "prune volume=$f yes" | bconsole; done to prune each volume in the pool. But the prune command did not only prune the expired volumes but also all volumes that contained the virtualfull job. My second step would have been to truncate the pruned volumes. But since I did not execute the truncate I will try to restore the virtualfull job by using bscan as you suggested. |
|
Sorry busy on other tasks. In fact what you expect was not was is configured and how it works with virtualfull. The date of the virtualfull job used it the one of the first job composing the virtualfull (let say the first job was done in 1st January) even if the volume has been written yesterday, the date of the job on it is 1st jan That's why you get the result you had, and not the one you expected ... In AI the documentation stated clearly that Volumes/Files/Client retention should be setup with high number It is the job of consolidate to do the cleanup, and nothing else should be used. I hope this will help you understand better how to setup and use the product. |
|
Documentation has been upgraded to reflect the right usage of volume retention. See warnings in https://docs.bareos.org/bareos-22/TasksAndConcepts/AlwaysIncrementalBackupScheme.html#storages-and-pools |
|
Date Modified | Username | Field | Change |
---|---|---|---|
2021-11-25 11:24 | Int | New Issue | |
2021-11-25 11:32 | Int | Note Added: 0004361 | |
2021-11-25 11:41 | Int | Note Added: 0004362 | |
2021-11-25 18:48 | bruno-at-bareos | Note Added: 0004363 | |
2021-11-29 10:52 | Int | Note Added: 0004371 | |
2021-12-22 16:32 | bruno-at-bareos | Note Added: 0004406 | |
2023-09-13 11:36 | bruno-at-bareos | Assigned To | => bruno-at-bareos |
2023-09-13 11:36 | bruno-at-bareos | Status | new => closed |
2023-09-13 11:36 | bruno-at-bareos | Resolution | open => fixed |
2023-09-13 11:36 | bruno-at-bareos | Note Added: 0005431 |