Line 2: |
Line 2: |
| | | |
| [http://dar.linux.free.fr/ DAR homepage] | | [http://dar.linux.free.fr/ DAR homepage] |
| + | |
| + | ===Backup timeouts explained=== |
| + | Even if you choose not to timeout your full backups, a full backup cannot |
| + | exceed 24h (or the cron will launch a conflicting backup job). |
| + | |
| + | So when you choose "Don't timeout full backup sessions", there is a default |
| + | timeout just before 24h. Then the full backup can stop cleanly, and the new |
| + | (incremental) backup will continue the backup. |
| + | |
| + | The real goal of setting a timeout+"Don't timeout full backup sessions" is for |
| + | big user files systems, when we want that the backup session occurs only the |
| + | night on the week days (we need the cpu and the bandwith for something else |
| + | than backuping, and if we backup on the time there is too much activity, the |
| + | risk of a failing backup with dar grows up, because a file can be modified |
| + | during his backup), and all the days on saturday and sunday (for most common |
| + | case). |
| + | |
| + | We can set : |
| + | |
| + | Backup time : 10:00 PM |
| + | DaysInSet : 7 |
| + | FullDay on friday or saturday |
| + | IncOnlyTimeOut : yes |
| + | Timeout : 8 (backup stops at 6:00 AM on week days) |
| + | |
| + | On monday morning we can have fully backuped our server, even if the time to do |
| + | it is about 32 hours (24+8). On the week days the server and the lan are are |
| + | not busy with backups between 6:00 AM and 10:00 PM |
| + | |
| | | |
| ===Backup disk size limits workaround=== | | ===Backup disk size limits workaround=== |