Hi, I am looking for some software recommendations for home dir backup.
I already use Timeshift for system snapshots & find this app great.
My laptop has 500GB internal SSD for /home. (ext4)
I also have a 1TB USB SSD to use as a backup drive.
I don’t mind connecting the backup drive via USB periodically & running an on-demand backup, but ideally I would like to connect the backup drive to router or RPi so it can be a LAN backup location.
I’d like something simple & reliable 
It’s just for home use.
Thanks for your advice.
1 Like
BackInTime, DejaDup, rsync, Grsync, BorgBackup, Bacula, etc…
There’s a lot out there, both command-line and GUI. It depends on your needs and skill level.
Why not (carefully) play around with some options using a test folder to get a feel for them?
1 Like
I am using rsync on console for backup to an internal SSD.
rsync -ahr /source /destination.
Works fine and fast. And is easy to handle.
+1 for Borg. If you want a GUI for it, you can install Vorta from the AUR.
1 Like
Timeshift can backup the home dir if you select in its settings.
1 Like
I gave DejaDup a try, but it’s not what I want. I prefer something that I can actually browse the files & not be locked into a particular software. (already suffered that with time machine)
I don’t need multiple historical copies of files, just 1 complete up-to-date backup. I can either schedule every day or run on-demand. Hopefully it will update the changes only & not run a complete sweep.
I would like a GUI tool.
1 Like
BackInTime does this. (Available in official Manjaro repositories.)
As well as Grsync. (Available in official Arch Linux repositories.)
Both are GUI frontends of rsync.
The files are easily accessible, like browsing a folder. Nothing fancy. No compression. No encryption. No containers. Just files.
EDIT: Apparently, BackInTime is available in Manjaro’s repositories (no need to build from AUR.) 
2 Likes
BackInTime looks good so far, let’s see how I get on with it.
Thanks everyone for the suggestions.
BackInTime doesnt seem to work properly. When I connect my backup drive I get a Gnome Notification “BackInTime: cant find snapshots folder” - its odd because obviously it detected the drive immediately, & the drive only has backintime snapshots folder on it : the initial on-demand back-up & no other daily’s.
Ill try GrSync. mmm, no schedule, too technical.
BackInTime would be ideal, but it doesn’t seem to function as advertised. Perhaps I am doing something wrong, but It doesn’t help my confidence with backup software when things don’t work.
I’m not sure what that means. Does it affect BackInTime’s usage?
yes, because no backup runs.
Wait, this is immediately when you plug in the external drive?
Or is it when you plug in the drive, and then quickly try to use BackInTime?
Immediately when connecting drive.
I selected the schedule as “when drive is connected”
Then I ran the 1st time backup.
The next day when I connect the drive I immediately get a gnome notification “BackInTime: cant find snapshots folder" - no back-up runs. Same next day.
My hunch is it’s not waiting long enough after you plug in the drive. (A device being detected on the USB port is not the same as the filesystem being mounted and ready.)
Is there an option to delay by at least 10 seconds?
There is not a delay option.
The notification does continue to say something about remote drives (its not, its local USB) & then."… waiting 30 seconds…" , but still nothing happens.
(I am trying BackInTime again on a new manjaro install on another partition. After the [2022-06-12 stable] I had several issues so I decided to start over.)
After playing around, I think I made a workaround to the “tries to run the backup too soon” issue.
Will update if it works.
So it appears BackInTime uses udev to create a custom rule under /etc/udev/rules.d/
I tried to modify it to wait 10 seconds (sleep 10s) before issuing the command to run any scheduled backups.
The problem is, BackInTime seems to detect if this udev rule was modified and wants to change it back. 
I couldn’t get around this.
It did “work” one time, but afterwards any time BackInTime runs or is opened, it will reset the modification (thus removing the condition to wait 10 seconds.)
I never used BackInTime for USB drives. Only local and network destinations (such as to a NAS server.)
EDIT: One way “around” this is to disable the schedule for “when device is plugged in”, and just manually run a backup task when needed.
Due to the nature of USBs, it’s not as feasible (on Linux) to automate backups.
1 Like
Thanks for your help winnie, this is really helpful info & I appreciate you taking the time to check into the issue & explain what you found.
I think Ill probably use BackInTime on-demand as you suggest.
It is odd that BiT offers the option “on connected” if its not feasible. I have submitted an issue report, so perhaps it will get a response.
Have a great day (or evening) & thanks again 
1 Like
Yeah, that seems like the best way forward.
After playing around with it some more, I figured it out, in which the BackInTime developers should use a better method instead of only “udev”.
The filesystem’s UUID becomes immediately available upon plugging in the USB device. Without a built-in delay, the command to backup (via BackInTime) tries to run immediately when the USB is plugged in.
However, the filesystem being detected (its “UUID” is known immediately) is not the same as the filesystem being mounted. THIS is the reason for its failure.
Not to mention, many users do not enable “auto mount” for their removable devices. (In my case, I need to manually permit a USB to mount. I do not allow it to mount on its own.)
Speaking of which, a better method (instead of only “udev”) could probably use the mtab. In other words “When the MOUNT PATH is active, only THEN try to run the backup task.”
So it would be a two-part logic:
-
Upon inserting the relevant USB device, udev will trigger step 2…
-
…which now polls the mtab every 5 seconds until the mount path is active.
If everything checks out, the backup task runs!
Otherwise, maybe after one minute, if the mount path is never active, only then will it fail and abort with the message “Mount path for the backup location was not available for over a minute. Backup task will not proceed. Please try again later.”
This thread can be shared with the developers.
1 Like