Nextcloud Maintenance
04 Aug 2020Setting up Nextcloud Server is half of the work - the other half, maintenance, is as important, if not more.
Basics
occ
Command
The occ
(OwnCloud Console), originated from Owncloud, is the command-line interface for server management operations, e.g. upgrading, backing up, configuring the server.
Depending on the installation method, occ
is run as:
- Non-snap installation:
sudo -u www-data php /var/www/[own|next]cloud/occ [--args]
. Original installations typically shipsocc
as a wrapper php scripts, where the core functionality are called from other php source scripts. It is required to execute theocc
script withphp
and run as userwww-data
; -
snap installation:
sudo nextcloud.occ [--args]
.occ
is shipped as a executable binary.
Notice that sudo
might be required depending on user permissions.
For the remaining of the post, we will simply use occ
to denote the command.
Other Dependencies
Other than occ
, snap also comes in handy with some dependencies and tools pre-installed.
For example,
- Non-snap installations require setting up apache server, whilst snap bundles the dependencies into the Nextcloud itself;
-
snap installation comes with
nextcloud.mysql-client
,nextcloud.mysqldump
as a bundled database solution; -
snap installation also comes with
nextcloud.enable-https
, in place of external tools (e.g. certbot), and many more.
For the rest of this post, we use a snap installation as an example.
Directories
For a snap installation, it is helpful to know how are the directories of snap applications organized. There are mainly two directories that we are concerned with in this post:
/snap[/nextcloud]
Dir Generally speaking, /snap
contains the core files of the applications.
For example, /snap/bin
contains the applications aliases:
$ cd /snap/bin; ls *nextcloud*
nextcloud.disable-https nextcloud.enable-https nextcloud.export nextcloud.import
nextcloud.manual-install nextcloud.mysql-client nextcloud.mysqldump nextcloud.occ
And /snap/core
contains the virtual file system used by snap applications:
$ cd /snap/core/current/; ls
bin boot dev etc home lib lib64 media meta mnt opt
proc root run sbin snap srv sys tmp usr var writable
/snap/nextcloud
contains the core files required to run the Nextcloud application:
$ cd /snap/nextcloud/current; ls
bin cgi-bin config error fixes icons lib logs meta my.cnf README share
support-files utilities certbot_nextcloud_plugin conf docs etc htdocs include
LICENSE man modules php setup.py snap usr var
where bin
holds the binaries aliased in /snap/bin
, lib
; htdocs
, include
, usr
, etc holds many scripts and libraries; so on and forth.
For application level configuration and maintenance, it is usually not required to mess with /snap
.
/var/snap[/nextcloud]
Dir On the other hand, /var/snap
is more like a container for application data.
Peeking in
$ cd /var/snap/nextcloud; ls
23027 23171 common current lost+found
there are two main targets common
and current
(23027
and 23171
are two versions of the applications and current
is a symlink to the latter one).
common
contains users’ data:
$ cd /var/snap/nextcloud/common/nextcloud/data; ls
admin appdata_oc5ijq344eib user1 user2 files_external index.html nextcloud.log
and current
contains app data (including that of the apps installed as dependencies)
$ cd /var/snap/nextcloud/current; ls
apache certs mysql nextcloud php redis
which includes logs, configs, etc.
Admin
Nextcloud web interface provides access to the admin user to many administrative functionalities (add users, config changes, etc). Most day-to-day tasks can be easily accomplished using that alone. If circumstances arise such that other measurements are to be taken, we might need to get our hands dirty.
First thing first, always turn on maintenance mode before making anything changes (and back off when done):
$ occ maintenance:mode --[on|off]
Restart
Restarting the application using snap:
$ sudo snap disable nextcloud
$ sudo snap enable nextcloud
Upgrade
Upgrade with snap installation is fairly simple:
# first update the snap package
$ sudo snap refresh nextcloud
# now upgrade in occ
$ occ upgrade
Logs
To read the logs, simply
$ snap logs nextcloud[.app]
Database Management
Snap uses its own bundled version of database nextcloud.mysql-client
.
Log in
# For reference: 'mysql -u root -p'
$ sudo nextcloud.mysql-client
Manual Changes and Syncing
Sometimes manually forcing syncing the changes are required (e.g. manually resolving failed syncs or corruptions, after making large changes that are much faster to add them manually to data directory /var/snap/nextcloud/common/nextcloud/data
, etc).
A simple command for this purpose:
$ occ files:scan --all
Backup and Restore
Nextcloud might be often used as a file backup service, but strictly speaking it is more of a file syncing service. It is important for the admin to set up proper backup solution to avoid losing data over accidental changes or server error (including faulty hardware, etc).
Backup Artifacts
When backing up, there are three main artifacts:
-
server config:
/var/snap/nextcloud/current/nextcloud/config/config.php
; - database: includes user information, permissions, file ownership and sharing information, etc. Nextcloud supports many different database software, e.g. mysql, mariadb, etc;
-
data directory:
/var/snap/nextcloud/common/nextcloud
;
Scripts, Tools and Automation
Server config:
# save config
$ sudo rsync /var/snap/nextcloud/current/nextcloud/config/config.php /backup/nextcloud/config/config_`date +"%Y-%m-%d"`.php
# restore config
$ sudo rsync /backup/nextcloud/config/config_YYYY-MM-DD.php /var/snap/nextcloud/current/nextcloud/config/config.php
Database:
# dump database
$ sudo nextcloud.mysqldump --single-transaction > /backup/nextcloud/database/nextcloud-sql_`date +"%Y-%m-%d"`.bak
# restore database, first recreate the 'nextcloud' database, then load it from backup file
$ sudo nextcloud.mysql-client -e "DROP DATABASE nextcloud";
$ sudo nextcloud.mysql-client -e "CREATE DATABSE nextcloud";
$ sudo nextcloud.mysql-client nextcloud < /backup/nextcloud/database/nextcloud-sql_YYYY-MM-DD.bak
Because the user data is relatively large, we use Borg Backup as the back up solution. It is feature-rich, reliable, compression-friendly and supports incremental backup nicely.
# Initialize a repo for nextcloud user data
$ borg init --encryption none /backup/nextcloud/data-borg/
# Create a backup. Borg automatically compresses and deduplicates. Notice the 'sudo' is required because 'common' is 'root'-owned.
$ sudo borg create --progress /backup/nextcloud/data-borg::userdata-$(date '+%Y-%m-%d') /var/snap/nextcloud/common/nextcloud
# Borg requires providing full-path for extraction. Head to root dir '/' before executing.
# The starting '/' at the extraction path is intentionally omitted.
$ sudo borg extract --progress /backup/nextcloud/data-borg::userdata-YYYY-MM-DD var/snap/nextcloud/common/nextcloud
# If unsure about the name, query the repo or archive
$ sudo borg [list|info] /backup/nextcloud/data-borg[::userdata-YYYY-MM-DD]
Alternately, if one wishes to use rsync instead, it is important to toggle the right flags to preserve all information:
# -A: preserve Access Control Lists;
# -a: archive. Recursive, preserve everything (with a few exceptions);
# -x: one-file-system.
# Backup
$ sudo rsync -Aaxv /var/snap/nextcloud/common/nextcloud /backup/nextcloud/data-rsync/nextcloud-backup_$(date '+%Y-%m-%d')
# Restore
$ sudo rsync -Aaxv /backup/nextcloud/data-rsync/nextcloud-backup_YYYY_MM_DD /var/snap/nextcloud/common/nextcloud
cron
Domain
Depending on how the domain was set up, routinely maintenance might be required.
- Free domain name providers might require routinely verification (e.g. NOIP require monthly logins);
- Dynamic DNS needs to be set up if the server’s public IP is not fixed;
- SSL certification needs to be renewed every couple of years (exact length depends on CA).
Snap installation of Nextcloud integrated certbot as a dependency, so renewal is straight-forward:
[sudo] nextcloud.enable-https lets-encrypt