Note that systemd-inhibit requires dbus and # dbus-user-session to be installed. LogRateLimitIntervalSec = 0 # Delay start to prevent backups running during boot. If you are using an older version of systemd that # doesn't support this (pre-240 or so), you may have to remove this option.
Nice = 19 CPUSchedulingPolicy = batch IOSchedulingClass = best-effort IOSchedulingPriority = 7 IOWeight = 100 Restart = no # Prevent rate limiting of borgmatic log events. MemoryDenyWriteExecute = no # Lower CPU and I/O priority. # But you can try setting it to "yes" for improved security if you don't use those features. Description = borgmatic backup Wants = network-online.target After = network-online.target ConditionACPower = true Type = oneshot # Certain borgmatic features like Healthchecks integration need MemoryDenyWriteExecute to be off.
Now even if you have no clue what to ignore, just set up the ssh_command with the repository and initialize the borg repository using: # Change how ssh works using our previously setup key ssh_command: ssh -p specialport -i ~/.ssh/id_rsa_borgbackup '- /home/*/.vim/plugged' # Some patterns we exclude from the backup exclude_patterns: # The borg executable path on the synology remote_path: /usr/local/bin/borg # You'll see later that we can use `-dry-run` to see what actually gets # backed-up, I chose to remove non-useful data, mostly dotfiles, caches and # browser configurations patterns: home/soyuka # Repository, redactedhostname is the synology location repositories: Note that the synology home directory needs 755 permissions, as always ssh permissions should be: Once the key is created with ssh-keygen -f ~/.ssh/id_rsa_borgbackup -C I copied the key to the synology in ~/.ssh/authorized_keys. I’ll therefore use my computer username to connect. You can create a specific group/user for your backups, I was lazy to do so and I don’t think it has much benefits. Then, the trick is to create a specific RSA key that will be used by SSH to authenticate the backup user. Once installed, go create a shared folder named “borgbackup”. On the synology, I used the SynoCommunity borgbackup package.
#Synology syncthing software
It’s one of the most used software to do backups as it supports: I never heard of Borg and went to read their documentation. At first, I wanted to use this syncthing tool to backup the whole computer and by digging I found out that syncthing users usually backed up their syncthing databse with rsync or Borg. But this is not a backup solution in my opinion. It helps syncing my photos and my passwords on every devices.
#Synology syncthing android
This runs on my Android phone, my workstation, my home computer and a raspberry pi. I’m a fervent user of syncthing, a continuous file synchronization program.
#Synology syncthing windows
On OS X you have Time Machine, on Windows there’s also a backup system but on linux you have to roll your own. Since I setup my workstation with sway ( see this article), the last thing I need to add is a backup solution. So instead of automation I have to backtrack on a scheduled task and change the permissions each time to move the files out of that folder.Borg backups from my archlinux workstation to a synology NAS The way this FileBot package operates is it needs the folder and files to have an Owner of admin instead.
I run FileBot Node on the NAS and am running into permission issues with that particular folder, because after Syncthing performs the transfer it changes the folder and files Owner to syncthing. When files get put into the Completed DL folder they are transferred one-way back to the NAS. The “Client” for Syncthing is running inside a VM running Linux Mint for various other tasks, but only watching one SEND ONLY folder - Completed DL. One Shared Folder is allowed access using the Group SC-Syncthing and it is called DL. Syncthing is running on my Synology NAS as the “Main Server” for my Network. I have been using Syncthing for a while now and have a question about permissions.Īllow me explain how my setup is being run: