Your message dated Fri, 27 Nov 2015 12:43:05 +0200 with message-id <[email protected]> and subject line Re: Bug#806419: obnam: creates checkpoints too often has caused the Debian Bug report #806419, regarding obnam: creates checkpoints too often to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 806419: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806419 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: obnam Version: 1.18.2-1 Severity: normal I'm using Obnam to create a full backup of my ${HOME} to a local disk attached via USB3. During this obnam seems to create checkpoints quite often, so that just that seems to take half of the time: 12h19m13s Backing up: found 141447 files, 1.05 TiB; uploaded: 1.03 TiB making checkpoint: re-opening repository 12h19m45s Backing up: found 141447 files, 1.05 TiB; uploaded: 1.03 TiB making checkpoint: continuing backup 12h20m14s Backing up: found 141447 files, 1.05 TiB; uploaded: 1.03 TiB making checkpoint: adding chunks to shared chunk indexes 12h20m22s Backing up: found 141447 files, 1.05 TiB; uploaded: 1.03 TiB making checkpoint: re-opening repository 12h21m11s Backing up: found 141447 files, 1.05 TiB; uploaded: 1.03 TiB 12h21m29s Backing up: found 141450 files, 1.05 TiB; uploaded: 1.03 TiB making checkpoint: committing per-client data The "re-opening repository" step takes around 30s after which 30s writing data follows, then the next checkpoint happens. Ansgar -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (100, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.2.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages obnam depends on: ii libc6 2.19-22 ii python 2.7.9-1 ii python-cliapp 1.20150829-1 ii python-fuse 2:0.2.1-11 ii python-larch 1.20151025-1 ii python-paramiko 1.15.3-1 ii python-tracing 0.9-1 ii python-ttystatus 0.30-1 ii python-yaml 3.11-2+b1 obnam recommends no packages. obnam suggests no packages. -- no debconf information
--- End Message ---
--- Begin Message ---On Fri, Nov 27, 2015 at 11:14:34AM +0100, Ansgar Burchardt wrote: > Package: obnam > Version: 1.18.2-1 > Severity: normal > > I'm using Obnam to create a full backup of my ${HOME} to a local disk > attached via USB3. During this obnam seems to create checkpoints quite > often, so that just that seems to take half of the time: ... > The "re-opening repository" step takes around 30s after which 30s > writing data follows, then the next checkpoint happens. There's no checkpoint value that is good for everyone, I think. The balance between the time between checkpoints and the time it takes to commit a checkpoint generation and start a new one is difficult to get right automatically, as it depends on various environmental factors, such as speed and reliability of the connection to the backup repository. The default checkpoint size is chosen for semi-unreliable, relatively slow connections. If your connection is reliable and fast, you probably want to increase the checkpoint size from a gigabyte (the default) to, say, 16 or 64 gigabytes: --checkpoint=64G I hope that helps. Since I think this isn't a real bug, I am closing it. -- Schrödinger's backup hypothesis: the condition of any backup is undefined until a restore is attempted. -- andrewsh
signature.asc
Description: Digital signature
--- End Message ---
