On Thu, 24 Jan 2019 11:27:00 -0500 Chris Laprise <tas...@posteo.net> wrote:
> On 01/24/2019 06:29 AM, unman wrote: > > On Thu, Jan 24, 2019 at 01:00:15AM -0500, Chris Laprise wrote: > >> On 01/23/2019 08:15 PM, js...@bitmessage.ch wrote: > >>> Mike Keehan: > >>>> Hi, > >>>> > >>>> I'm using Qubes Backup to save some of my qubes into another VM. > >>>> The backup VM has 18 Gb of storage available, but whenever the > >>>> backup file reaches 3Gb, the backup process just hangs. > >>>> > >>>> No CPU usage, no error messages, just stops. The backup window > >>>> shows 40% complete, but never moves any further (different % for > >>>> different combinations of qubes in the backup list). > >>>> > >>>> After waiting a considerable time (well, 5-10 minutes), hitting > >>>> Cancel in the backup window does cancel it. The rest of the > >>>> system is continuing to work without problem. Happens every > >>>> time I try to use Qubes backup. > >>>> > >>>> The Qubes Disk Space widget shows less than 50% disk used > >>>> overall, the backupVM shows only 18% disk used when the 3Gb file > >>>> has been saved. > >>>> > >>>> I'm stumped. > >>>> > >>>> Mike. > >>> > >>> Hi, > >>> > >>> You may have to wait longer than 5-10 minutes. I experience > >>> something similar when doing a full backup, except it's worse > >>> because i'm backing up like 2.5TB. It appears to hang for several > >>> hours at a time (and this happens more than once), but it does > >>> eventually make visible progress again. The whole process takes > >>> over 24 hours. This is why i do full backups very infrequently. > >>> > >>> For you it shouldn't take nearly as long because it's a lot less > >>> data, but the progress appearing to hang for a while seems to be > >>> normal. > >>> > >>> I'm using 3.2 tho, and i know they made changes to the backup > >>> mechanism under the hood in 4.0, so i'm not sure if this issue > >>> still applies in 4.0. > >> > >> Marek, > >> > >> Isn't this the null bytes bug in GNU tar? > >> > >> https://groups.google.com/d/msgid/qubes-users/f4d997d5-7191-06d0-e7bb-ef42745a7db5%40posteo.net > >> > >> It would be a good idea to update this in dom0. My own backup tool > >> uses GNU tar as well. > >> > >> -- > >> > >> Chris Laprise, tas...@posteo.net > >> https://github.com/tasket > >> https://twitter.com/ttaskett > >> PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 > > > > It seems a little early to judge. > > > > Mike - it looks from your comment as if you have been trying with > > subsets of the qubes? Can you confirm if these are running or > > stopped. > > > > Like jsnow, I'm regularly able to backup far more than 3G without > > issue, so it looks as if there's something particular about this > > scenario. It would be helpful if you could confirm the issue when > > all qubes you are backing up are stopped. > > Then try bisecting the qubes backup group - keep bisecting if you > > hit the problem again until you either find the problematic qubes > > or have backed them all up. > > > > Oops, I pasted the wrong link. Here is the correct one: > > https://utcc.utoronto.ca/~cks/space/blog/sysadmin/TarFindingTruncateBug > > The symptoms sound remarkably the same... potentially hours-long > delays with no adverse effect on data. Trigger condition is not about > size, but due to corner cases that involve backing up nulls. > Thanks to all of you !! I've been out today, but will have a look at tracking down the culprit tomorrow:) Mike. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20190124184812.24128610.mike%40keehan.net. For more options, visit https://groups.google.com/d/optout.
