From ad65c5ac16915f0476feec0cce2bc27cc9887add Mon Sep 17 00:00:00 2001 From: Thomas Waldmann Date: Fri, 24 Jun 2016 21:48:21 +0200 Subject: [PATCH 1/3] support docs: add freenode web chat link, fixes #1175 --- docs/support.rst | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/docs/support.rst b/docs/support.rst index 1547c6668..7cd1890d3 100644 --- a/docs/support.rst +++ b/docs/support.rst @@ -23,6 +23,12 @@ Join us on channel #borgbackup on chat.freenode.net. As usual on IRC, just ask or tell directly and then patiently wait for replies. Stay connected. +You could use the following link (after connecting, you can change the random +nickname you got by typing "/nick mydesirednickname"): + +http://webchat.freenode.net/?randomnick=1&channels=%23borgbackup&uio=MTY9dHJ1ZSY5PXRydWUa8 + + Mailing list ------------ From f54f159db88589256b2cc75a15d969899f4ed52c Mon Sep 17 00:00:00 2001 From: Thomas Waldmann Date: Fri, 24 Jun 2016 22:32:38 +0200 Subject: [PATCH 2/3] more details about checkpoints, add split trick, fixes #1171 --- docs/faq.rst | 46 +++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 43 insertions(+), 3 deletions(-) diff --git a/docs/faq.rst b/docs/faq.rst index 0051a48c0..0d6a1185f 100644 --- a/docs/faq.rst +++ b/docs/faq.rst @@ -180,13 +180,53 @@ Yes, |project_name| supports resuming backups. During a backup a special checkpoint archive named ``.checkpoint`` is saved every checkpoint interval (the default value for this is 5 -minutes) containing all the data backed-up until that point. This means -that at most worth of data needs to be retransmitted -if a backup needs to be restarted. +minutes) containing all the data backed-up until that point. + +Checkpoints only happen between files (so they don't help for interruptions +happening while a very large file is being processed). + +This checkpoint archive is a valid archive (all files in it are valid and complete), +but it is only a partial backup (not all files that you wanted to backup are +contained in it). Having it in the repo until a successful, full backup is +completed is useful because it references all the transmitted chunks up +to the checkpoint. This means that in case of an interruption, you only need to +retransfer the data since the last checkpoint. + +If a backup was interrupted, you do not need to do any special considerations, +just invoke ``borg create`` as you always do. You may use the same archive name +as in previous attempt or a different one (e.g. if you always include the current +datetime), it does not matter. + +|project_name| always does full single-pass backups, so it will start again +from the beginning - but it will be much faster, because some of the data was +already stored into the repo (and is still referenced by the checkpoint +archive), so it does not need to get transmitted and stored again. Once your backup has finished successfully, you can delete all ``.checkpoint`` archives. +How can I backup huge file(s) over a instable connection? +--------------------------------------------------------- + +You can use this "split trick" as a workaround for the in-between-files-only +checkpoints (see above), huge files and a instable connection to the repository: + +Split the huge file(s) into parts of manageable size (e.g. 100MB) and create +a temporary archive of them. Borg will create checkpoints now more frequently +than if you try to backup the files in their original form (e.g. 100GB). + +After that, you can remove the parts again and backup the huge file(s) in +their original form. This will now work a lot faster as a lot of content chunks +are already in the repository. + +After you have successfully backed up the huge original file(s), you can remove +the temporary archive you made from the parts. + +We realize that this is just a better-than-nothing workaround, see :issue:`1198` +for a potential solution. + +Please note that this workaround only helps you for backup, not for restore. + If it crashes with a UnicodeError, what can I do? ------------------------------------------------- From b10025c6e535a3665cdb69ee0eb39ccf1c10f2ec Mon Sep 17 00:00:00 2001 From: Thomas Waldmann Date: Fri, 24 Jun 2016 23:30:27 +0200 Subject: [PATCH 3/3] document sshd settings, fixes #545 --- docs/faq.rst | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/docs/faq.rst b/docs/faq.rst index 0d6a1185f..100abd89b 100644 --- a/docs/faq.rst +++ b/docs/faq.rst @@ -143,6 +143,24 @@ stops after a while (some minutes, hours, ... - not immediately) with That's a good question and we are trying to find a good answer in `ticket 636 `_. +Why am I seeing idle borg serve processes on the repo server? +------------------------------------------------------------- + +Maybe the ssh connection between client and server broke down and that was not +yet noticed on the server. Try these settings: + +:: + + # /etc/ssh/sshd_config on borg repo server - kill connection to client + # after ClientAliveCountMax * ClientAliveInterval seconds with no response + ClientAliveInterval 20 + ClientAliveCountMax 3 + +If you have multiple borg create ... ; borg create ... commands in a already +serialized way in a single script, you need to give them --lock-wait N (with N +being a bit more than the time the server needs to terminate broken down +connections and release the lock). + The borg cache eats way too much disk space, what can I do? -----------------------------------------------------------