You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* allow starting backup from any folder
* automatically run using sudo
(to never fail due to ./backup owned by root)
* run post_backup.sh after 'docker-compose start', to minimize downtime
when e.g. uploading backups to a remote server
* chown all of ./backup to the appropriate user
Fixes#566
@@ -4,55 +4,64 @@ This page explains how to use the backup and restore functionality of IOTstack.
4
4
## Backup
5
5
The backup command can be executed from IOTstack's menu, or from a cronjob.
6
6
7
-
### Running backup
8
-
To ensure that all your data is saved correctly, the stack should be brought down. This is mainly due to databases potentially being in a state that could cause data loss.
7
+
To ensure that all your data is saved correctly, the stack has to be stopped.
8
+
This is mainly due to databases potentially being in a state that could cause
9
+
data loss.
9
10
10
11
There are 2 ways to run backups:
11
12
12
13
* From the menu: `Backup and Restore` > `Run backup`
13
14
* Running the following command: `bash ./scripts/backup.sh`
14
15
15
-
The command that's run from the command line can also be executed from a cronjob:
16
+
The command that's run from the command line can also be executed from crontab:
16
17
17
-
```0 2 * * * cd /home/pi/IOTstack && /bin/bash ./scripts/backup.sh```
18
+
```
19
+
0 2 * * * cd /home/pi/IOTstack && /bin/bash ./scripts/backup.sh
20
+
```
18
21
19
22
The current directory of bash must be in IOTstack's directory, to ensure that it can find the relative paths of the files it's meant to back up. In the example above, it's assume that it's inside the `pi` user's home directory.
20
23
21
-
### Arguments
22
-
```
23
-
./scripts/backup.sh {TYPE=3} {USER=$(whoami)}
24
+
**Usage:**
25
+
```console
26
+
$ ~/IOTstack/scripts/backup.sh {TYPE}
24
27
```
25
28
26
-
* Types:
27
-
* 1 = Backup with Date
28
-
* A tarball file will be created that contains the date and time the backup was started, in the filename.
29
-
* 2 = Rolling Date
30
-
* A tarball file will be created that contains the day of the week (0-6) the backup was started, in the filename.
31
-
* If a tarball already exists with the same name, it will be overwritten.
32
-
* 3 = Both
33
-
* User:
34
-
This parameter only becomes active if run as root. This script will default to the current logged in user
35
-
If this parameter is not supplied when run as root, the script will ask for the username as input
29
+
**Types:**
30
+
31
+
1. Backup with Date. Backup to filename with the date and time the backup was
32
+
started.
33
+
2. Rolling Date. Filename will based on the day of the week (0-6) the backup
34
+
was started. New backups will overwrite old ones.
35
+
3. Both
36
+
37
+
You can find the backups in the `~/IOTstack/backups/` folder. With rolling
38
+
being in `~/IOTstack/backups/rolling/` and date backups in
39
+
`~/IOTstack/backups/backup/`. Log files can also be found in the logs/
40
+
directory.
36
41
37
-
Backups:
42
+
**Examples:**
38
43
39
-
* You can find the backups in the ./backups/ folder. With rolling being in ./backups/rolling/ and date backups in ./backups/backup/
40
-
* Log files can also be found in the ./backups/logs/ directory.
44
+
- Regular date & timestamped backup into ~/IOTstack/backup/backups:
41
45
42
-
### Examples:
46
+
`~/IOTstack/scripts/backup.sh 1`
43
47
44
-
*`./scripts/backup.sh`
45
-
*`./scripts/backup.sh 3`
48
+
- Either these commands will produce backups of both types:
46
49
47
-
Either of these will run both backups.
50
+
`~/IOTstack/scripts/backup.sh` or<br />
51
+
`~/IOTstack/scripts/backup.sh 3`
48
52
49
-
*`./scripts/backup.sh 2`
50
53
51
-
This will only produce a backup in the rollowing folder. It will be called 'backup_XX.tar.gz' where XX is the current day of the week (as an int)
54
+
- Produce a backup into ~/IOTstack/backup/rolling/. It will be called
55
+
'backup_XX.tar.gz' where XX is the current day of the week (as an int):
52
56
53
-
*`sudo bash ./scripts/backup.sh 2 pi`
57
+
`~/IOTstack/scripts/backup.sh 2`
54
58
55
-
This will only produce a backup in the rollowing folder and change all the permissions to the 'pi' user.
59
+
- (expert use) Usually the backup should be executed without sudo using your
60
+
regular user, as this will automatically produce backups with correct
61
+
permissions. This will only produce a backup in the rolling folder and
62
+
change all the permissions to the 'pi' user:
63
+
64
+
`sudo bash ~/IOTstack/scripts/backup.sh 2 pi`
56
65
57
66
## Restore
58
67
There are 2 ways to run a restore:
@@ -64,7 +73,7 @@ There are 2 ways to run a restore:
64
73
65
74
*Note*: It is suggested that you test that your backups can be restored after initially setting up, and anytime you add or remove a service. Major updates to services can also break backups.
@@ -76,35 +85,126 @@ The restore script takes 2 arguments:
76
85
## Pre and post script hooks
77
86
The script checks if there are any pre and post back up hooks to execute commands. Both of these files will be included in the backup, and have also been added to the `.gitignore` file, so that they will not be touched when IOTstack updates.
78
87
79
-
### Prebackup script hook
80
-
The prebackup hook script is executed before any compression happens and before anything is written to the temporary backup manifest file (`./.tmp/backup-list_{{NAME}}.txt`). It can be used to prepare any services (such as databases that IOTstack isn't aware of) for backing up.
88
+
Both of these scripts will be run as root.
89
+
90
+
### Pre-backup script hook
91
+
The pre-backup hook script is executed before any compression happens and before anything is written to the temporary backup manifest file (`./.tmp/backup-list_{{NAME}}.txt`). It can be used to prepare any services (such as databases that IOTstack isn't aware of) for backing up.
81
92
82
-
To use it, simple create a `./pre_backup.sh` file in IOTstack's main directory. It will be executed next time a backup runs.
93
+
To use it, simple create the `~/IOTstack/pre_backup.sh` file. It will be executed next time a backup runs.
83
94
84
-
### Postbackup script hook
85
-
The postbackup hook script is executed after the tarball file has been written to disk, and before the final backup log information is written to disk.
95
+
### Post-backup script hook { #post-backup }
96
+
The post-backup hook script is executed after the backup tarball file has been
97
+
written to disk and the stack has been started back up. Any output will be
98
+
included in the backup log file.
86
99
87
-
To use it, simple create a `./post_backup.sh` file in IOTstack's main directory. It will be executed after the next time a backup runs.
100
+
To use it, simple create the `~/IOTstack/post_backup.sh` file. It will be
101
+
executed after the next time a backup runs. It will be provided the backup
102
+
.tar.gz as its first argument.
103
+
104
+
This is useful for triggering transfer of the backup to a cloud or another
105
+
server, see below for possible third party integrations as to what is possible.
88
106
89
107
### Post restore script hook
90
108
The post restore hook script is executed after all files have been extracted and written to disk. It can be used to apply permissions that your custom services may require.
91
109
92
110
To use it, simple create a `./post_restore.sh` file in IOTstack's main directory. It will be executed after a restore happens.
93
111
94
112
## Third party integration
95
-
This section explains how to backup your files with 3rd party software.
113
+
This section explains how you could backup your files to different
114
+
integrations. Actual initiation of the transfer of the backup has to be done
115
+
using the [post backup](#post-backup) hook described above.
116
+
117
+
### IOTstackBackup
118
+
119
+
[IOTstackBackup](https://github.com/Paraphraser/IOTstackBackup) is a project
120
+
aiming to provide a sophisticated all-in-on solution: on-line backups of
121
+
databases and configurable transfers to remotes without writing your own
122
+
scripts.
96
123
97
124
### Dropbox
98
-
Coming soon.
125
+
Dropbox-Uploader is a great utility to easily upload data from your Pi to the cloud. https://magpi.raspberrypi.org/articles/dropbox-raspberry-pi. It can be installed from the Menu under Backups.
126
+
127
+
#### Troubleshoot: Token added incorrectly or install aborted at the token screen
128
+
129
+
Run `~/Dropbox-Uploader/dropbox_uploader.sh unlink` and if you have added it key then it will prompt you to confirm its removal. If no key was found it will ask you for a new key.
130
+
131
+
Confirm by running `~/Dropbox-Uploader/dropbox_uploader.sh` it should ask you for your key if you removed it or show you the following prompt if it has the key:
Ensure you **are not** running as sudo as this will store your api in the /root directory as `/root/.dropbox_uploader`
152
+
153
+
If you ran the command with sudo the remove the old token file if it exists with either `sudo rm /root/.dropbox_uploader` or `sudo ~/Dropbox-Uploader/dropbox_uploader.sh unlink`
154
+
155
+
99
156
100
157
### Google Drive
101
-
Coming soon.
158
+
rclone is a program uploading to Google Drive. Install it from the menu then
0 commit comments