The hardware<\/h2>\n\n\n\n
I dabbled with a BeagleBoard that I used for an embedded systems course, and I pondered a Raspberry Pi with a case. I decided against both of those, because I wanted something with a bit more wiggle room. And besides, I like having a BeagleBoard free to mess around with<\/a> now and then.<\/p>\n\n\n\n In the end, I picked out an Intel NUC<\/a>, and I threw in an old SSD and a stick of RAM:<\/p>\n\n\n\n It’s tiny, it’s quiet, and it looks okay too! (Just find somewhere to hide the power brick). My only real complaint is the wifi hardware doesn’t work with older Linux kernels, but that wasn’t a big deal for my needs and I’m sure it will work in the future.<\/p>\n\n\n\n I installed Ubuntu Core 16<\/a>, which is delightful<\/em>. Installing it is a bit surprising for the uninitiated because there isn’t really an install process: you just clone the image to the drive you want to boot from and you’re done. It’s easier if you do this while the drive is connected to another computer. (I didn’t feel like switching around SATA cables in my desktop, so I needed to write a different OS to a flash drive, boot from that on the NUC, transfer the Ubuntu Core image to there, then dd that image to the SSD. Kind of weird for this use case).<\/p>\n\n\n\n Now that I figured out how to run it, I’ve been enjoying how this system is designed to minimize the time you need to spend with your device connected to a screen and keyboard like some kind of savage. There’s a simple setup process (configure networking, log in to your Ubuntu One account), and that’s it. You can bury the thing somewhere and SSH to it from now on. In fact, you’re pretty much forced to: you don’t even get a login prompt. Chances are you won’t need to SSH to the system anyway since it keeps itself up to date. As someone who obsesses over loose threads, I’m finding this all very satisfying.<\/p>\n\n\n\n Although, with that in mind, one important thing: if you haven’t played with Ubuntu for a while, head over to login.ubuntu.com<\/a> and make sure your SSH keys are up to date. The first time I set it up, I realized I had a bunch of obsolete SSH keys in my account and I had no way to reach the system from the laptop I was using. Fixing that meant changing Ubuntu Core’s writable files from another operating system. (I would love to know if there is a better way).<\/p>\n\n\n\n Okay, using Ubuntu Core is probably a bit weird when I want to run all these servers and I’m probably a little picky, but it’s so elegant! And, happily, there are Snap packages for both Nextcloud<\/a> and Syncthing<\/a>. I ended up using both.<\/p>\n\n\n\n I really like how files you can edit are tucked away in \/writable<\/em>. For this guide, I always refer to things by their full paths under \/writable. I found thinking like that spared me getting lost in files that I couldn’t change, and it helped to emphasize the nature of this system.<\/p>\n\n\n\n Before I get to the fun stuff, there were some networking conundrums I needed to solve.<\/p>\n\n\n\n First, public DNS. My router has some buttons if you want to use a dynamic DNS service, but I just rolled my own thing. To start off, I added some additional records for my DNS pointing at my home IP address. My web host has an API for editing DNS rules, so I set up a dynamic DNS after everything else was working, but I will get to that further along.<\/p>\n\n\n\n Next, my router didn’t support hairpinning (or NAT Loopback), so requests to core.example.com<\/em> were still resolving to my public IP address, which means way too many hops for sending data around. My ridiculous solution: I’ll run my own DNS server, darnit.<\/p>\n\n\n\n To get started, check the network configuration in \/writable\/system-data\/etc\/netplan\/00-snapd-config.yaml<\/em>. You’ll want to make sure the system requests a static IP address (I used 192.168.1.2<\/em>) and uses its own nameservers. Mine looks like this:<\/p>\n\n\n\n After changing the Netplan configuration, use For the actual DNS server, we can install an unofficial snap that provides dnsmasq:<\/p>\n\n\n\n You’ll want to edit \/writable\/system-data\/etc\/hosts<\/em> so the service’s domains resolve to the devices’s local IP address:<\/p>\n\n\n\n Now it’s safe to go into your router’s configuration, reserve an IP address for this device, and set it as your DNS server:<\/p>\n\n\n\n And that solved it.<\/p>\n\n\n\n To check, run tracepath<\/em> from another computer on your network and the result should be something simple like this:<\/p>\n\n\n\n While you’re looking at the router, you may as well forward some ports, too. By default you need TCP ports 80 and 443 for Nextcloud, and 22000 for Syncthing.<\/p>\n\n\n\n The Nextcloud snap<\/a> is fantastic. It already works out of the box: it adds a system service for its copy of Apache on port 80, and it comes with a bunch of scripts for setting up common things like SSL certificates. I wanted to use an external hard drive for its data store, so I needed to configure the mount point for that and grant the necessary permissions for the snap to access removable media.<\/p>\n\n\n\n Let’s set up that mount point first. These are configured with Systemd mount units<\/a>, so we’ll want to create a file like \/writable\/system-data\/etc\/systemd\/system\/media-data1.mount<\/em>. You need to tell it how to identify the storage device. (I always give them nice volume labels when I format them so it’s easy to use that). Note that the name of the unit file must correspond to the full name of the mount point:<\/p>\n\n\n\n One super cool thing here is you can start and stop the mount unit just like any other system service:<\/p>\n\n\n\n Now let’s set up Nextcloud. The code repository for the Nextcloud snap<\/a> has lots of documentation if you need.<\/p>\n\n\n\n Before we do anything else we need to tell Nextcloud to store its data in \/media\/data1\/nextcloud\/<\/em>, and allow access through the public domain from earlier. To do that, edit \/writable\/system-data\/var\/snap\/nextcloud\/current\/nextcloud\/config\/config.php<\/em>:<\/p>\n\n\n\n Move the existing data directory to the new location, and restart the service:<\/p>\n\n\n\n Now you can enable HTTPS. There is a lets-encrypt option (for letsencrypt.org<\/a>), which is very convenient:<\/p>\n\n\n\n At this point you should be able to reach Nextcloud from another computer on your network, or remotely, using the same domain.<\/p>\n\n\n\n If you aren’t me, you can probably stop here and use Nextcloud, but I decided Nextcloud wasn’t quite right for all of my files, so I added Syncthing to the mix. It’s like a peer to peer Dropbox, with a somewhat more geeky interface. You can link your devices by globally unique IDs, and they’ll find the best way to connect to each other and automatically sync files between your shared folders. It’s very elegant, but I wasn’t sure about using it without some kind of central repository. This way my systems will sync between each other when they can, but there’s one central device that is always there, ready to send or receive the newest versions of everything.<\/p>\n\n\n\n Syncthing has a snap<\/a>, but it is a bit different from Nextcloud, so the package needed a few extra steps. Syncthing, like Dropbox, runs one instance for each user, instead of a monolithic service that serves many users. So, it doesn’t install a system service of its own, and we’ll need to figure that out. First, let’s install the package:<\/p>\n\n\n\n Once you’re satisfied, you can stop syncthing. That isn’t very useful yet, but we needed to run it once to create a configuration file.<\/p>\n\n\n\n So, first, we need to give syncthing a place to put its data, replacing “USERNAME” with your system username:<\/p>\n\n\n\n Unfortunately, you’ll find that the syncthing application doesn’t have access to \/media\/data1, and its snap doesn’t support the removable-media interface, so it’s limited to your home folder. But that’s okay, we can solve this by creating a bind mount. Let’s create a mount unit in \/writable\/system-data\/etc\/systemd\/system\/home-USERNAME-syncthing.mount<\/em>:<\/p>\n\n\n\n (If you’re wondering, yes, systemd figures out that it needs to mount media-data1 before it can create this bind mount, so don’t worry about that).<\/p>\n\n\n\n Now update Syncthing’s configuration and tell it to put all of its shared folders in that directory. Open \/home\/USERNAME\/snap\/syncthing\/common\/syncthing\/config.xml<\/em> in your favourite editor, and make sure you have something like this:<\/p>\n\n\n\n With those changes, Syncthing will create new folders inside \/home\/USERNAME\/syncthing<\/em>, you can move the default “Sync” folder there as well, and its web interface will be accessible over your local network at http:\/\/192.168.1.2:8384<\/em>. (I’m not enabling TLS here, for two reasons: it’s just the local network, and Nextcloud enables HSTS for the core.example.com<\/em> domain, so things get confusing when you try to access it like that).<\/p>\n\n\n\n You can try Now we need to add a service file so Syncthing runs automatically. We could create a service that has the User field filled in and it always runs as a certain user, but for this type of service it doesn’t hurt to set it up as a template unit<\/a>. Happily, Syncthing’s documentation<\/a> provides a unit file we can borrow, so we don’t need to do much thinking here. You’ll need to create a file called \/writable\/system-data\/etc\/systemd\/system\/syncthing@.service<\/em>:<\/p>\n\n\n\n Note that our Exec<\/em> line is a little different than theirs, since we need it to run syncthing<\/em> under the snap<\/em> program.<\/p>\n\n\n\n And there you have it, we have Syncthing! The web interface for the Ubuntu Core system is only accessible over your local network, but assuming you forwarded port 22000 on your router earlier, you should be able to sync with it from anywhere.<\/p>\n\n\n\n If you install the Syncthing desktop client ( Once your devices are all connected, it’s a good idea to go to Syncthing’s web interface at http:\/\/192.168.1.2:8384<\/em> and edit the settings for each device. You can enable “Auto Accept” so whenever a device shares a new folder with core.example.com<\/em>, it will be accepted automatically.<\/p>\n\n\n\n There is one last thing I did here. Syncthing and Nextcloud have some overlap, but I found myself using them for pretty different sorts of tasks. I use Nextcloud for media files and archives that I want to store on a single big hard drive, and occasionally stream over the network; and I use Syncthing for files that I want to have locally on every device.<\/p>\n\n\n\n Still, it would be nice if I could have Nextcloud’s web UI and sharing options with Syncthing’s files. In theory we could bind mount Syncthing’s data directory into Nextcloud’s data directory, but the Nextcloud and Syncthing services run as different users. So, that probably won’t go particularly well.<\/p>\n\n\n\n Instead, it works quite well to mount Syncthing’s data directory using SSH.<\/p>\n\n\n\n First, in Nextcloud, go to the Apps section and enable the “External storage support” app.<\/p>\n\n\n\n Now you need to go to Admin, and “External storages”, and allow users to mount external storage.<\/p>\n\n\n\n Finally, go to your Personal settings, choose “External storages”, add a folder named Syncthing, and tell it connect over SFTP. Give it the hostname of the system that has Syncthing (so, core.example.com<\/em>), the username for the user that is running Syncthing (USERNAME<\/em>), and the path to Syncthing’s data files (\/home\/USERNAME\/syncthing). It will need an SSH key pair to authenticate.<\/p>\n\n\n\n When you click Generate keys<\/em> it will create a key pair. You will need to copy and paste the public key (which appears in the text field) to \/home\/USERNAME\/.ssh\/authorized_keys<\/em>.<\/p>\n\n\n\n If you try the gear icon to the right, you’ll find an option to enable sharing for the external storage, which is very useful here. Now you can use Nextcloud to view, share, or edit your files from Syncthing.<\/p>\n\n\n\n I spun tires for a while with backups, but eventually I settled on Restic<\/a>. It is fast, efficient, and encrypted. I’m really impressed with it.<\/p>\n\n\n\n Unfortunately, the snap for Restic doesn’t support strict confinement, which means it won’t work on Ubuntu Core. So I cheated. Let’s set this up under the root user.<\/p>\n\n\n\n You can find releases of Restic<\/a> as prebuilt binaries. We’ll also need to install a snap that includes curl. (Or you can download the file on another system and transfer it with scp, but this blog post is too long already).<\/p>\n\n\n\n We need to figure out the environment variables<\/a> we want for Restic. That depends on what kind of storage service you’re using. I created a file with those variables at \/root\/restic-MYACCOUNT.env<\/em>. For Backblaze B2<\/a>, mine looked like this:<\/p>\n\n\n\n Next, make a list of the files you’d like to back up in \/root\/backup-files.txt<\/em>:<\/p>\n\n\n\n I added a couple of quick little helper scripts to handle the most common things you’ll be doing with Restic:<\/p>\n\n\n\n \/root\/bin\/restic-MYACCOUNT<\/em>.sh<\/strong><\/p>\n\n\n\n Use this as a shortcut to run restic with the correct environment variables.<\/p>\n\n\n\n \/root\/bin\/backups-push.sh<\/strong><\/p>\n\n\n\n This will ignore any directory that contains a file named “.backup-ignore”. (So to stop a directory from being backed up, you can run \/root\/bin\/backups-clean.sh<\/strong><\/p>\n\n\n\n This will periodically remove old snapshots, prune unused blocks, and then check for errors.<\/p>\n\n\n\n Make sure all of those scripts are executable:<\/p>\n\n\n\n We still need to add systemd stuff, but let’s try this thing first!<\/p>\n\n\n\n Have fun playing with Restic, try restoring some files, note that you can list all the files in a snapshot and restore specific ones. It’s a really nice little backup tool.<\/p>\n\n\n\n It’s pretty easy to get systemd helping here as well. First let’s add our service file. This is a different kind of system service because it isn’t a daemon. Instead, it is a oneshot service. We’ll save it as \/writable\/system-data\/etc\/systemd\/system\/backups-task.service<\/em>.<\/p>\n\n\n\n Now we need to schedule it to run on a regular basis. Let’s create a systemd timer unit<\/a> for that: \/writable\/system-data\/etc\/systemd\/system\/backups-task.timer<\/em>.<\/p>\n\n\n\n![\"\"](\"https:\/\/i0.wp.com\/dylanmc.ca\/wp-content\/uploads\/IMG_20180428_013430.jpg?resize=525%2C394&ssl=1\")
<\/figure><\/li>![\"\"](\"https:\/\/i0.wp.com\/dylanmc.ca\/wp-content\/uploads\/IMG_20180428_013506.jpg?resize=525%2C394&ssl=1\")
<\/figure><\/li><\/ul><\/figure>\n\n\n\nThe software<\/h2>\n\n\n\n
![\"\"](\"https:\/\/i0.wp.com\/dylanmc.ca\/wp-content\/uploads\/Screenshot-from-2018-05-05-13-41-29.png?resize=525%2C288&ssl=1\")
<\/figure><\/li><\/ul><\/figure>\n\n\n\nThe other software<\/h2>\n\n\n\n
DNS<\/h3>\n\n\n\n
![\"\"](\"https:\/\/i0.wp.com\/dylanmc.ca\/wp-content\/uploads\/Screenshot-2018-5-5-Add-DNS-Resource-Record-example-com-NearlyFreeSpeech-NET-Member-Interface.png?resize=525%2C162&ssl=1\")
<\/figure><\/li><\/ul><\/figure>\n\n\n\nnetwork:\n ethernets:\n eth0:\n dhcp4: false<\/strong>\n dhcp6: false<\/strong>\n addresses: [192.168.1.2\/24, '2001:1::2\/64']<\/strong>\n gateway4: 192.168.1.1\n nameservers:<\/strong>\n addresses: [8.8.8.8, 8.8.4.4]<\/strong>\n version: 2<\/pre>\n\n\n\n
sudo netplan generate<\/code> to update the system.<\/p>\n\n\n\n$ snap install dnsmasq-escoand<\/pre>\n\n\n\n
127.0.0.1 localhost.localdomain localhost\n::1 localhost6.localdomain6 localhost6\n\n192.168.1.2 core.example.com<\/em><\/strong>\nfe80::96c6:91ff:fe1a:6581 core.example.com<\/em><\/strong>\n\n\u2026<\/pre>\n\n\n\n
![\"\"](\"https:\/\/i0.wp.com\/dylanmc.ca\/wp-content\/uploads\/Screenshot-2018-4-28-NETGEAR-Router-R6400v2-Address-reservation.png?resize=525%2C81&ssl=1\")
<\/figure><\/li>![\"\"](\"https:\/\/i0.wp.com\/dylanmc.ca\/wp-content\/uploads\/Screenshot-2018-4-28-NETGEAR-Router-R6400v2-DNS-address.png?resize=525%2C132&ssl=1\")
<\/figure><\/li><\/ul><\/figure>\n\n\n\n$ tracepath core.example.com<\/em>\n 1?: [LOCALHOST] pmtu 1500\n 1: core.example.com<\/em> 0.789ms reached\n 1: core.example.com<\/em> 0.816ms reached\n Resume: pmtu 1500 hops 1 back 1<\/pre>\n\n\n\n
![\"\"](\"https:\/\/i0.wp.com\/dylanmc.ca\/wp-content\/uploads\/Screenshot-2018-4-28-NETGEAR-Router-R6400v2-Port-forward.png?resize=525%2C82&ssl=1\")
<\/figure><\/li><\/ul><\/figure>\n\n\n\nNextcloud<\/h3>\n\n\n\n
[Unit]\nDescription=Mount unit for data1\n\n[Mount]\nWhat=\/dev\/disk\/by-label\/data1\nWhere=\/media\/data1\nType=ext4\n\n[Install]\nWantedBy=multi-user.target\n\n<\/pre>\n\n\n\n
$ sudo systemctl daemon-reload\n$ sudo systemctl start media-data1.mount\n$ sudo systemctl enable media-data1.mount<\/pre>\n\n\n\n
$ snap install nextcloud\n$ snap connect nextcloud:removable-media :removable-media\n$ sudo snap run nextcloud.manual-install USERNAME PASSWORD\n$ snap stop nextcloud<\/pre>\n\n\n\n
<?php\n$CONFIG = array (\n 'apps_paths' =>\n array (\n \u2026\n ),\n \u2026\n 'trusted_domains' =>\n array (\n 0 => 'localhost',\n 1 => 'core.example.com<\/strong><\/em>'\n ),\n 'datadirectory' => '\/media\/data1\/nextcloud\/data<\/strong>',\n \u2026\n);<\/pre>\n\n\n\n
$ snap stop nextcloud\n$ sudo mkdir \/media\/data1\/nextcloud\n$ sudo mv \/writable\/system-data\/var\/snap\/nextcloud\/common\/nextcloud\/data \/media\/data1\/nextcloud\/\n$ snap start nextcloud<\/pre>\n\n\n\n
$ sudo snap run nextcloud.enable-https lets-encrypt -d\n$ sudo snap run nextcloud.enable-https lets-encrypt<\/pre>\n\n\n\n
![\"\"](\"https:\/\/i0.wp.com\/dylanmc.ca\/wp-content\/uploads\/Screenshot-2018-4-27-Nextcloud.jpg?resize=525%2C309&ssl=1\")
<\/figure><\/li>![\"\"](\"https:\/\/i0.wp.com\/dylanmc.ca\/wp-content\/uploads\/Screenshot-from-2018-05-04-23-01-29.png?resize=525%2C375&ssl=1\")
<\/figure><\/li><\/ul><\/figure>\n\n\n\nSyncthing<\/h3>\n\n\n\n
$ snap install syncthing\n$ snap connect syncthing:home :home\n$ snap run syncthing<\/pre>\n\n\n\n
$ sudo mkdir \/media\/data1\/syncthing\n$ sudo chown USERNAME<\/em>:USERNAME<\/em> \/media\/data1\/syncthing<\/pre>\n\n\n\n
[Unit]\nDescription=Mount unit for USERNAME<\/em>-syncthing\n\n[Mount]\nWhat=\/media\/data1\/syncthing\/USERNAME<\/em>\nWhere=\/home\/USERNAME<\/em>\/syncthing\nType=none\nOptions=bind\n\n[Install]\nWantedBy=multi-user.target<\/pre>\n\n\n\n
$ sudo systemctl daemon-reload\n$ sudo systemctl start home-USERNAME<\/em>-syncthing.mount\n$ sudo systemctl enable home-USERNAME<\/em>-syncthing.mount<\/pre>\n\n\n\n
<configuration version=\"27\">\n <folder id=\"default\" label=\"Default Folder\" path=\"\/home\/USERNAME<\/em>\/syncthing\/Sync\"<\/strong> type=\"readwrite\" rescanIntervalS=\"60\" fsWatcherEnabled=\"false\" fsWatcherDelayS=\"10\" ignorePerms=\"false\" autoNormalize=\"true\">\n \u2026\n <\/folder>\n <device id=\"\u2026\" name=\"core.example.com<\/strong><\/em>\" compression=\"metadata\" introducer=\"false\" skipIntroductionRemovals=\"false\" introducedBy=\"\">\n <address>dynamic<\/address>\n <paused>false<\/paused>\n <autoAcceptFolders>false<\/autoAcceptFolders>\n <\/device>\n <gui enabled=\"true\" tls=\"false\" debugging=\"false\">\n <address>192.168.1.2:8384<\/strong><\/address>\n \u2026\n <\/gui>\n <options>\n <defaultFolderPath>\/home\/USERNAME<\/em>\/syncthing<\/strong><\/defaultFolderPath>\n <\/options>\n<\/configuration><\/pre>\n\n\n\n
snap run syncthing<\/code> again, just to be sure.<\/p>\n\n\n\n![\"\"](\"https:\/\/i0.wp.com\/dylanmc.ca\/wp-content\/uploads\/Screenshot-2018-5-5-core-example-com-Syncthing.png?resize=525%2C350&ssl=1\")
<\/figure><\/li><\/ul><\/figure>\n\n\n\n[Unit]\nDescription=Syncthing - Open Source Continuous File Synchronization for %I\nDocumentation=man:syncthing(1)\nAfter=network.target\n\n[Service]\nUser=%i\nExecStart=\/usr\/bin\/snap run syncthing -no-browser -logflags=0\nRestart=on-failure\nSuccessExitStatus=3 4\nRestartForceExitStatus=3 4\n\n[Install]\nWantedBy=multi-user.target<\/pre>\n\n\n\n
$ sudo systemctl daemon-reload\n$ sudo systemctl start syncthing@USERNAME<\/em>.service\n$ sudo systemctl enable syncthing@USERNAME<\/em>.service<\/pre>\n\n\n\n
snap install syncthing<\/code> in Ubuntu, dnf install syncthing-gtk<\/code> in Fedora), you’ll be able to connect your other devices to each other. On each device that you connect to this one, make sure you set core.example.com<\/em> as an Introducer<\/em>. That way they will discover each other through it, which saves a bit of time.<\/p>\n\n\n\n![\"\"](\"https:\/\/i0.wp.com\/dylanmc.ca\/wp-content\/uploads\/Screenshot-from-2018-05-04-23-04-30.png?resize=525%2C388&ssl=1\")
<\/figure><\/li><\/ul><\/figure>\n\n\n\nNextcloud + Syncthing<\/h3>\n\n\n\n
![\"\"](\"https:\/\/i0.wp.com\/dylanmc.ca\/wp-content\/uploads\/Screenshot-2018-4-28-Apps-Nextcloud.png?resize=525%2C308&ssl=1\")
<\/figure><\/li>![\"\"](\"https:\/\/i0.wp.com\/dylanmc.ca\/wp-content\/uploads\/Screenshot-2018-4-28-Admin-Nextcloud.png?resize=525%2C179&ssl=1\")
<\/figure><\/li>![\"\"](\"https:\/\/i0.wp.com\/dylanmc.ca\/wp-content\/uploads\/Screenshot-2018-5-5-Personal-Nextcloud.png?resize=525%2C151&ssl=1\")
<\/figure><\/li><\/ul><\/figure>\n\n\n\n![\"\"](\"https:\/\/i0.wp.com\/dylanmc.ca\/wp-content\/uploads\/Screenshot-2018-5-3-Example-Files-Nextcloud.png?resize=525%2C340&ssl=1\")
<\/figure><\/li>![\"\"](\"https:\/\/i0.wp.com\/dylanmc.ca\/wp-content\/uploads\/Screenshot-from-2018-05-04-23-09-04.png?resize=525%2C382&ssl=1\")
<\/figure><\/li><\/ul><\/figure>\n\n\n\nBackups<\/h3>\n\n\n\n
$ snap install demo-curl\n$ snap run demo-curl.curl -L \"https:\/\/github.com\/restic\/restic\/releases\/download\/v0.8.3\/restic_0.8.3_linux_amd64.bz2\" | bunzip2 > restic\n$ chmod +x restic\n$ sudo mkdir \/root\/bin\n$ sudo cp restic \/root\/bin<\/pre>\n\n\n\n
#!\/bin\/sh\n\nexport RESTIC_REPOSITORY=\"b2:core-example-com--1<\/em>\"\nexport B2_ACCOUNT_ID=\"\u2026\"\nexport B2_ACCOUNT_KEY=\"\u2026\"\nexport RESTIC_PASSWORD=\"\u2026\"<\/pre>\n\n\n\n
\/media\/data1\/nextcloud\/data\/USERNAME<\/em>\/files\n\/media\/data1\/syncthing\/USERNAME<\/em>\n\/writable\/system-data\/<\/pre>\n\n\n\n
#!\/bin\/sh\n\n. \/root\/restic-MYACCOUNT<\/em>.env\n\/root\/bin\/restic $@<\/pre>\n\n\n\n
#!\/bin\/sh\n\nRESTIC=\"\/root\/bin\/restic-MYACCOUNT<\/em>.sh\"\nRESTIC_ARGS=\"--cache-dir \/root\/.cache\/restic\"\n\n${RESTIC} ${RESTIC_ARGS} backup --files-from \/root\/backup-files.txt --exclude \".stversions\" --exclude-if-present \".backup-ignore\" --exclude-caches<\/pre>\n\n\n\ntouch \/path\/to\/the\/directory\/<\/em>.backup-ignore<\/code>). This is a great way to save time if you have some big directories that don’t really need to be backed up, like a directory full of, um, Linux ISOs shifty eyes<\/em>.<\/p>\n\n\n\n#!\/bin\/sh\n\nRESTIC=\"\/root\/bin\/restic-MYACCOUNT<\/em>.sh\"\nRESTIC_ARGS=\"--cache-dir \/root\/.cache\/restic\"\n\n${RESTIC} ${RESTIC_ARGS} forget --keep-daily 7 --keep-weekly 8 --keep-monthly 12 --prune\n${RESTIC} ${RESTIC_ARGS} check<\/pre>\n\n\n\n$ sudo chmod +x \/root\/bin\/restic-MYACCOUNT<\/em>.sh\n$ sudo chmod +x \/root\/bin\/restic-push.sh\n$ sudo chmod +x \/root\/bin\/restic-clean.sh<\/pre>\n\n\n\n
$ sudo \/root\/bin\/restic-MYACCOUNT<\/em>.sh init\n$ sudo \/root\/bin\/backups-push.sh\n$ sudo \/root\/bin\/restic-MYACCOUNT<\/em>.sh snapshots<\/pre>\n\n\n\n
[Unit]\nDescription=Regular system backups with Restic\n\n[Service]\nType=oneshot\nExecStart=\/bin\/sh \/root\/bin\/backups-push.sh\nExecStart=\/bin\/sh \/root\/bin\/backups-clean.sh<\/pre>\n\n\n\n
[Unit]\nDescription=Run backups-task daily\n\n[Timer]\nOnCalendar=09:00 UTC \nPersistent=true\n\n[Install]\nWantedBy=timers.target<\/pre>\n\n\n\n