View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000296 | bareos-core | General | public | 2014-05-13 17:12 | 2023-08-22 20:58 |
Reporter | MaxHeadroom | Assigned To | bruno-at-bareos | ||
Priority | normal | Severity | feature | Reproducibility | N/A |
Status | closed | Resolution | no change required | ||
Summary | 0000296: Restart a backup after a error/pause but don't backup all files again. | ||||
Description | For a full backup off an offsite it is neccassary to have these options: *To restart a failed backup. The possiblity that there is an network break is really high because of a long backuptime. *Until the workhour it should be possible to pause the backup and resume after. Maybe you can add an option that a fd is waiting for a reconnect and start after the last file that backup was ok. regards Max | ||||
Tags | No tags attached. | ||||
> *To restart a failed backup. The possiblity that there is an network break is really high because of a long backuptime. it is possible, to restart a failed job with the "rerun" command, see http://doc.bareos.org > *Until the workhour it should be possible to pause the backup and resume after. > Maybe you can add an option that a fd is waiting for a reconnect and start after the last file that backup was ok. agreed, that this is a helpful feature. However, it will take quite some efford to implement it. We leave this ticket open as a reminder and feature request. |
|
as i understand is rerun = run again with the same options this would mean that in a case of network error all previous data has to backup again. For a initial offsite backup this could end up in a never ending accurate backup when the backup is running days. |
|
As I recently hit this issue while doing the initial backup of my NAS I found this issue. As Bacula supports exactly this since a few version (as far as I can tell also in the open source variant), maybe their code could make implementing this easier? Most likely even just trying to reconnect before declaring a backup as failed would help a lot, as most interruptions are either only short connection losses or misbehaving firewalls that drop the connection state for some reason leading to a broken connection. |
|
did you test the checkpoint feature present in Bareos 22x? this will not allow to restart from the point of failure, but will allow you to use the backup (restore) up to the last checkpoint before the crash. Restart from failure, will not occur soon, without paying development and/or community PR. But we decide to not go there, because finding why the backup has failed is really prone to error. Just a thing as food for though. what to do with file that were present, and are not anymore, about those that have changed in the meantime etc ... |
|
Date Modified | Username | Field | Change |
---|---|---|---|
2014-05-13 17:12 | MaxHeadroom | New Issue | |
2014-05-16 17:21 | joergs | Note Added: 0000867 | |
2014-05-16 17:21 | joergs | Status | new => acknowledged |
2014-05-27 16:57 | MaxHeadroom | Note Added: 0000884 | |
2021-06-26 23:14 | TheChaosJack | Note Added: 0004161 | |
2023-08-22 20:58 | bruno-at-bareos | Assigned To | => bruno-at-bareos |
2023-08-22 20:58 | bruno-at-bareos | Status | acknowledged => closed |
2023-08-22 20:58 | bruno-at-bareos | Resolution | open => no change required |
2023-08-22 20:58 | bruno-at-bareos | Note Added: 0005340 |