urBackup episode 3

• Windows backup ended fine.  Other incremental backups have followed during the few times I boot this laptop under Windows 10 instead of Linux.  So far so good.  I've also tested a restore (one JPEG file), that went fine as well.
• I need to do something to save the config of the server itself I guess.  BackupPC provided the localhost host by default to do that, but the urBackup server doesn't have a default client on the server itself apparently; will check if I can install a Linux client on the same box and make that happen.
• The rtcwake script seems to work fine on kid2 too.  I enhanced it a bit to check for loadavg because it should not shutdown while the load average is anywhere above idle; so i don't need to do specific checks about urBackup processes and so forth
• One day I'll have to look at the email configuration too.  That's definitely broken by default for a home network
• The kid2 hardware looks like a good idea to start migrating to urBackup while not removing BackupPC immediately.  The only problem is I will need one more "big" hard disk before I can add any more clients to urBackup.

NFS/SSH/RSYNC issues linked to DNS / DHCP

The NFS & Backuppc server was using DHCP but with a fixed IP configured in the DHCP server (in the router). Sometimes this box was unable to resolve names of other machines on the LAN. I tried fidling with /etc/nsswitch.conf without success. I decided to move from DHCP to fixed IP since the server IP is fixed already anyways; So I also removed NetworkManager* and used /etc/network/interfaces to setup the eth0 interface. I also re-enabled the cronjob to suspend (shut down) the server when idle. Then on the next day I noticed a reboot (clock-driven) and tried to login after a couple minutes but the box wasn't responsive... I connected a screen and keyboard to troubleshoot the issue, just to discover that I forgot to add "auto eth0" in my new /etc/network/interfaces configuration. So after each reboot the server stayed offline :-\ Easy fix, now the hourly suspend/reboot seems to work fine. The script doesn't reboot in case a backup is in progress, or NFS clients are connected. To be verified after some more days.

Backuppc/RsyncD unresponsive on Windows 10

One of my windows backuppc clients is hanging during backups. On the status screen, it shows as "backup in progress" but no transfer PID is shown, and it takes ages in that state. Usually the user shuts down before the backup completes (and the status seems to stay the same). I upgraded RsyncD from 3.0.9 to 3.1.x, applied Windows Updates and rebooted. The next backup seems to have worked (in 80 minutes!) but has been interrupted again. To be checked. It might also be linked to DNS or interface problems (I'm currently migrating the backuppc server from a DHCP to a fixed IP configuration).

kid2 role, revisited

So on the ACPI side, the BIOS+LXde settings seem to be able to suspend the system, resuming (sometimes) with a double click on the mouse.  However this is not what I'd want from a server that is supposed to do "stuff" at periodic 1-hour intervals, like backuppc or my photo posting script.  So far powernap doesn't seem to do anything for me neither, so I removed it completely.

I tested IDE HDDs that were lying around.  Seems like the 500GB and the 200GB are both dead.  I'm left with an old 6GB to play with.  Mounted it on kid2, checked that there was no data left (moved some to kid2 home).  I also moved data from the Windows partition into the home partition so that I can prepare to attempt a Windows reinstall.

On the 6GB hdd I removed the old partitioning, created a single partition, and installed Puppylinux just to play with it, and have an alternate/backup boot method for kid2.  That distro is really damn small!  But quite functional as a intetnet/word processing box.  I might try that on my old eCafé that's sitting in my drawer awaiting for better days.  The installation media could be a single SD card, 512Mb would be enough...  I think the eCafé can boot from USB so that would seem like a piece of cake.

I like the internal hardware on kid2, and the way it allows to add many more 3.5" disks in the future if I wanted to.  The base hardware (packard bell) really has only one free spot left for that.  I'm starting to think about swapping roles for these two boxes.  Both could accept the USB3 PCIe card that I've ordered...  both hardware seem to be reliable still... I wonder how the slower CPU would work in the context of rsync/gzip/network backups; we'll see when I complete the backuppc setup by adding a few more clients on kid2's backup hosts list.

Backuppc archives timeout problem + new archive HDD medium

So I took delivery of my new Maxtor M3 2Tb USB 3 drive yesterday.  Still the server only has USB 2 ports so I know this is going to be still slow until I can upgrade that.
However I hooked the M3 and it powered up and connected without problems.
fdisk showed a single partition (1.8Gb) formatted as HPFS/NTFS.  I moved the contents to /home/luc/Texts/Manuals or somewhere like that.  It contained some backup software and the documentation apparently.  Then I reformatted using ext4, and changed the partition type to Linux 0x83 (and removed the bootable flag).
Afterthat I used the UUID (from blkid) so add a new line to /etc/auto.removable and it just worked under autofs.  created the backuppc directory and will use that in a new backuppc archive host.
But before that I'd like to fill the iomega HDD with some recent backup archives so that I can move that out of site.  I noticed my previous attempts all failed after 20 hours exactly so after googling a bit I found out about the Client Timeout setting in Backuppc.  Changed this to 48 hours and started a new archive again, from kid3 backup.
To be continued...