Topic: failed DAR backup

[julianop]

After a period of successful backups under SME 8, I upgraded to 9.2 about two weeks ago

Incremental backup was working (though I had accidentally configured it for 17 incremental backups per set!) until 6/15 (last Friday) when it failed - still doing incrementals...

==================================
DAILY BACKUP TO WORKSTATION REPORT
==================================
Backup of spencer.barnlea.com started at Fri Jun 15 23:35:04 2018
Destination //degas.fawnroad/home/pub/spencer.barnlea.com/set1
Basename inc-011-20180615233504
Starting the backup with a timeout of 7 hours
*** No backup allowed or error during backup ***
Failed to add set /mnt/smb/spencer.barnlea.com/set1/inc-011-20180615233504 to catalog. No child processes

A manually triggered full backup also failed...

==================================
DAILY BACKUP TO WORKSTATION REPORT
==================================
Backup of spencer.barnlea.com started at Sun Jun 17 10:32:53 2018
Destination //degas.fawnroad/home/pub/spencer.barnlea.com/set2
Basename full-20180617103253
Starting the backup with a timeout of 24 hours


 --------------------------------------------
 356903 inode(s) saved
   including 414 hard link(s) treated
 0 inode(s) changed at the moment of the backup and could not be saved properly
 0 byte(s) have been wasted in the archive to resave changing files
 0 inode(s) not saved (no inode/file change)
 0 inode(s) failed to be saved (filesystem error)
 301 inode(s) ignored (excluded by filters)
 0 inode(s) recorded as deleted from reference backup
 --------------------------------------------
 Total number of inode(s) considered: 357204
 --------------------------------------------
 EA saved for 0 inode(s)
 --------------------------------------------
*** No backup allowed or error during backup ***
Failed to add set /mnt/smb/spencer.barnlea.com/set1/inc-011-20180615233504 to catalog. No child processes


An Internet search on the "Failed to add set to catalog" message brought me to a discussion between developers back in 2014...

https://bugs.contribs.org/show_bug.cgi?id=8610

but the issue was slightly different to mine (I'm backing up to a an NFS share, not a USB stick), and I saw no clear resolution to it that seemed helpful.

Could somebody point me in the right direction to resolve this, please?

[TerryF]

Hi

What was the error message when the full was attempted

==================================
DAILY BACKUP TO WORKSTATION REPORT
==================================
Backup of spencer.barnlea.com started at Sun Jun 17 10:32:53 2018
Destination //degas.fawnroad/home/pub/spencer.barnlea.com/set2
Basename full-20180617103253
Starting the backup with a timeout of 24 hours

The rest of the  quoted message is for a inc backup

[julianop]

Hi

What was the error message when the full was attempted

==================================
DAILY BACKUP TO WORKSTATION REPORT
==================================
Backup of spencer.barnlea.com started at Sun Jun 17 10:32:53 2018
Destination //degas.fawnroad/home/pub/spencer.barnlea.com/set2
Basename full-20180617103253
Starting the backup with a timeout of 24 hours

The rest of the  quoted message is for a inc backup

Well, that WAS the entire message from the single invocation, Terry, so maybe that's part of the problem: it is the ONLY backup command I had (indeed, have EVER) run from the command line, and I didn't interrupt it in any way.

I had run:
"/etc/e-smith/events/actions/workstation-backup-dar", taken from Brian Reed's comment of 2014-11-22 on the forum article I referenced earlier.

It started as a full backup, as the log shows, and if it then decided it wanted to do an incremental one instead, it is not from any action on my part.

I copied and pasted that entire log text as-is, no more, no less from the one single invocation - honest

I do notice that the opening comment was about set 2, while the fail message refers to set 1; that is certainly interesting...

Anyway...
not being one to sit and wait helplessly, I had reconfigured the backup schedule by correcting the errant "Daily backups in each set" value from 17 to 7, set up a new target share (still NFS), set the time to do it immediately, and let it go.
It completed successfully...

(I think I'm supposed to use code tags for logs, right?

Code: [Select]

==================================
DAILY BACKUP TO WORKSTATION REPORT
==================================
Backup of spencer.barnlea.com started at Sun Jun 17 12:48:02 2018
Destination //degas.fawnroad/mnt/ax/spencer.barnlea.com/set2
Basename full-20180617124802
Starting the backup with a timeout of 24 hours

 --------------------------------------------
 356913 inode(s) saved
   including 414 hard link(s) treated
 0 inode(s) changed at the moment of the backup and could not be saved properly
 0 byte(s) have been wasted in the archive to resave changing files
 0 inode(s) not saved (no inode/file change)
 0 inode(s) failed to be saved (filesystem error)
 301 inode(s) ignored (excluded by filters)
 0 inode(s) recorded as deleted from reference backup
 --------------------------------------------
 Total number of inode(s) considered: 357214
 --------------------------------------------
 EA saved for 0 inode(s)
 --------------------------------------------
Destination disk usage 1.3T, 50% full, 1.3T available
Backup successfully terminated at Sun Jun 17 14:14:11 2018

What is interesting is that it chose to do set 2 (of two), telling me that it knew that it had already done a set 1. This is of course correct, but that first set was on the original target. I don't know where on the server backup history is kept, but I hope it won't get confused by the temporary change of target. It seems not to have...

So my questions now, are:
1. Having now successfully completed set 2 of two, can I now reconfigure the backup to use the intended target?
2. Should I manually copy the dar files and the dar-catalog file from the temporary target to the original?
3. Is there any implicit or explicit requirement of extra available space on the target? And...
4. Is there anything else I can/should do to ensure smooth future backups?

Thank you for your help on this.

[TerryF]

Was once advised by someone smarter than me, better to use

# /sbin/e-smith/do_backupwk

1. Having now successfully completed set 2 of two, can I now reconfigure the backup to use the intended target? 

Can't see why not.

2. Should I manually copy the dar files and the dar-catalog file from the temporary target to the original?

Again see above, after deleting old ones.

3. Is there any implicit or explicit requirement of extra available space on the target? And...

What is the size of a full backup, how large are the incrementals?

If two full sets is configured you need enough space for a minimum of 2 full sets plus incrementals plus 1 further temp full set, This is created during a full backup, after deletion of old set the temp full is moved to relevant dir and becomes the "live" full.

4. Is there anything else I can/should do to ensure smooth future backups?

Bit like that piece of string

[julianop]

Was once advised by someone smarter than me, better to use

# /sbin/e-smith/do_backupwk

1. Having now successfully completed set 2 of two, can I now reconfigure the backup to use the intended target? 

Can't see why not.

2. Should I manually copy the dar files and the dar-catalog file from the temporary target to the original?

Again see above, after deleting old ones.

3. Is there any implicit or explicit requirement of extra available space on the target? And...

What is the size of a full backup, how large are the incrementals?

If two full sets is configured you need enough space for a minimum of 2 full sets plus incrementals plus 1 further temp full set, This is created during a full backup, after deletion of old set the temp full is moved to relevant dir and becomes the "live" full.

4. Is there anything else I can/should do to ensure smooth future backups?

Bit like that piece of string

Oops, yes. I need that extra space for the extra full set, don't I? Well, that might have been my trouble:
The full backup was 12G, and because of my mistake over the 17 count for incrementals, they added another 16G. The latest full attempt added another 24G, and the free space is only 47G, so while it isn't definite that there was insufficient space, it is getting too close for comfort.

Thanks again for your help, Terry, I'll take your advice above.