Frequent asked questions about raspiBackup. Every new user of raspiBackup should read all questions and answers.
I run three Raspberries at home. Two of them run 7/24 all the time as LAN servers. It's common practice to backup a server on a regular base just in case there are any failures. In particular the SD card of the Raspberry tends to fail after some time. That's why I wrote a small script which creates a dd backup. Then support for tar was added because the dd backup saves the whole SD card all the time even there is only a subset of the space used. tar just saves the used data. Finally rsync backup was added which uses hardlinks and saves backupspace and backuptime becaus it's an incremental backup. raspiBackup helped me multiple times to revover from a broken SD card so I thought the script may also be helpful for other people running Raspberries and decided to publish raspiBackup.
The most reliable backup is a backup from a stopped system. Unfortunately this cannot be done on a regular base with cron automatically. If you stop all active services as mysql, samba, nfs, seafile, Owncloud, Webserver and all other active services before starting the backup in order to keep all the data consistent the backup can be used to restore the system. If these services are not stopped there is a high probability the backup will become inconsistent. Parameter -a and -o help to achieve this. See also FAQ 18. As an alternative a sample wrapper script can be used and extended.
raspiBackup can restore all created backups (See this page for details). raspiBackup runs on Linux only. Windows user can use windisk32imager to restore a dd backup. For all other backup types a Linux system is required.
Fortunately your Raspberry can be used to restore the backup with raspiBackup. Install a Linux OS (e.g. raspbian) on a second SD card, start it and install raspiBackup. Now connect an external SD card reader and the drive with the backup and use raspiBackup to restore the backup to the external SD card. Shutdown the system, insert the external SD card with the restored backup and start your Raspberry again.
raspiBackup can save two partitionens via tar or rsync in the normal backup mode: The boot and the rootpartition of the SD card. If the rootpartition was moved to an external partition this external partition is also saved.The dd backup will save the whole SD card but no external root partition will be saved.
An unlimited number of partitions on the SD card will be saved in the partition oriented mode. Additional external partitions will not be saved in this mode. This mode is usefull for NOOBs images. If a restore with win32diskimager should be possible you can use the dd backup in the normal backup mode.
You can use dd, tar and rsync to backup the data. dd and tar backups can be zipped also. See the following page for pros and cons of the different backup methods.
That was a requirement for raspiBackup: It should be possible to restore the backup with Linux means only.
raspiBackup creates readable files of the output of the Linux commands sfdisk, blkid and fdisk of the SD card. This allows to restore the partition layout of the original SD card with Linux means. Then the partition backups can be restored into these partition using the corresponding linux backup tools.
If you use a dd backup this will work for a lrger SD card. But you have to use a Linux tool to expand the second partition if you want to use the whole space.
This works perfectly for smaller and larger SD cards if backup mode tar or rsync and the normal backup mode is used. The root partition size is either truncated if the SD card is smaller than the original SD card or expanded to use the whole SD card size if it's larger. But the used space on the backup SD card has to be smaller than the restore SD card size. Otherwise the restore will fail.
Option -0 (zero) allows to use the existing partitioning of the target SD card for restore. That way you have full control about the size the partitions should have on the restored SD card. So it's possible to restore partition oriented backups also on a smaller SD card.
A partition oriented backup can be restored on a smaller SD card by formatting all partitions on the SD card first and then restore the backup with option -0.
There exist two options which give you full control of the way the new SD card is partitioned. Option -1 (one) forces raspiBackup to create the same partitioning on the target SD card even the partitions are smaller or larger than the size of the target SD card. Option -0 (zero) disables partitioning by raspBackup. This allows to create the partitioning and formating on the target SD card upfront and these paritions are used as is by raspiBackup during restore.
In general on every device which can be mounted on Linux:
- External USB Stick
- External USB disk
- cifs/samba networking disk
- nfs networking disk
- sshfs networking disk
- webdav networking disk
- ftpfs networking disk
Use one of the following approaches:
a) Use a wrapper script (see here) and write your own code which is executed before and after raspiBackup and saves additional data
b) Use extension points which are called before and after the backup function to save the data. There exist two sample extensions (see here) which report the CPU temperature before and after a backup run and the used memory. An eMailExtension can be used to plug in your own eMailClient.
exim4, postfix and nullmailer, sendEmail, ssmtp and msmtp are supported. The eMailExtension plugpoint can be used to plugin every other eMailClient (Details see here).
Use the eMalExtension plugpoint to write a small extension which will be used to send the emails from raspiBackup. The existing extensionsamples include one sample code for the mailx eMailClient.
Please note: I'm talking about raspBackup questions - no Linuxquestions or -issues. For them please read FAQ38 and FAQ47.
There exist following communication channels:
1) Open an issue in github if you have an issue or a question. That's my preference because an issue tracking system is very helpful. You have to register in github first. Don't worry about this. github access is for free.
2) At the bottom of every webpage you can create comments but please ask questions only. No problem report. To eliminate spam the comments are checked manually and that's why it usually takes one day until the comment is published and will be answered. Unfortunately there is no longer a notification eMail sent when an update happens on your comment because of GDPR. You have to check for updates manually now.
3) Ask your question on Facebook. No problem report. You have to register on Facebook first.
See also this note
Note: Any other commincation pathes are silently ignored.
Every software can have bugs and raspiBackup is no exception. Please report the issue on this website in a comment, in github or in Facebook. See here for details.
raspiBackup checks in every invocation whether there exist a new version. A message will be written and the notification eMail will have a smiley ;-) in it's mail title. Now you can check on this page what's new in the new version and update raspiBackup with parameter -U.
raspiBackup creates a backup copy every time an upgrade is done with parameter -U. Option -V can be used to revert to a previous version. A list of all saved raspiBackup versions will be presented and the version to restore can be selected.
dd backup backups the whole SD card. There is a configuration parameter
DEFAULT_DD_BACKUP_SAVE_USED_PARTITIONS_ONLY which causes raspiBackup to save only the space used by defined partitions. So you just have to resize the 32GB partition to 8GB with gparted or other repartitiontools and the backup will only use 8GB. Current partiton sizes can be checked with lsblk command.
Hardlinks are used by raspiBackup with rsync if a local attached USB stick or a local attached USB disk formatted with ext3/ext4 or a remote disk mounted via nfs is used. Samba and sshfs don't support hardlinks.
sudo du -sh * displays the used backup space and
sudo du -shl
* displays how much space would be used if no hardlinks are used.
root@raspberrypi:/media/nas-backup/raspberrypi# du -sh *
root@raspberrypi:/media/nas-backup/raspberrypi# du -shl *
How hardlinks work is described in detail on this page.
All services which keep any states in databases or in memory or on filesystemhave to be stopped. Otherwise inconsistent data may be saved and when the backup is restored the backup is unusable. raspiBackup offers option -o to stop services before starting the backup and option -a to start the services afterwards. For convenience you can define the services to start/stop also with the installer which will add the services in the configuration file. Please note the installer only offers system services to start/stop. Applications which are not started as a system service have to be started/stopped manually with options -a and -o.
At least following services should be stopped with option -o:
|nfs||systemctl stop nfs-kernel-serv er|
|Samba||systemctl stop samba|
|Pilight||systemctl stop pilight|
|Cups||systemctl stop cups|
|Minidlna||systemctl stop minidlna|
|Apache||systemctl stop apache2|
|Wordpress||systemctl stop wordpress|
|nginx||systemctl stop nginx|
|seafile||systemctl stop seafile|
|mysql||systemctl stop mysql|
|FHEM||systemctl stop fhem|
|iobroker||systemctl stop iobroker|
|cron||systemctl stop cron|
To start the services again use option -a and use the reverse service sequence used with -o. If you are dead certain you don't need to stop and start services use ":" as parameter for option -a and -o.
The installer makes sure the seleted systemd controlled services are stopped ans started in seuqence. Unfortunately systemd doesn't make sure the configured service dependecies are respected.
Example for -o:
-o "systemctlstoppilight && systemctl
stopsamba && systemctl
Example for -a:
-a "systemctlstartnfs-kernel-server && systemctl
startsamba && systemctl start pilight"
The configuration file may have following contents:
DEFAULT_STOPSERVICES="systemctlstopnfs-kernel-server && systemctl
stoppilight && systemctl stop samba"
startpilight && systemctl
Note: All commands are executed as root. There is no sudo required.
--systemstatusturns on the creation of a list of started services and open files before starting the backup.
If for some reasons you want no service to stop or start use a colon as command in option -a and -o, i.e.
-a : -o
In general every filesystem can be used which can be mounted on LInux. But there are following constraints:
- rsync backup uses hardlinks which are supported with ext3/4. Only changed files are copied during backup and hardlinks are used to reuse the previouse saved files. If an ext4 filesystem is exported via samba there is no support for hardlinks. NFS is an alternative. If no hardlinks are supported rsync cannot be used.
- FAT32 can store files with max 4GB only. A dd backup will become as large as the SD card is (Configuration option DEFAULT_DD_BACKUP_SAVE_USED_PARTITIONS_ONLY can reduce the size) and is in general larger than 4GB. It's similar for tar backups which become larger than 4GB quite quickly. An alternative may be NTFS on windows.
General suggestion: Use ext3/4 if possible. On Linux use NFS for remote drives and on windows use NTFS for exported samba network drives. Use FAT32 only if you are sure the backup files will not become larger than 4GB.
WARNING: Don't use NTFS when you want to use rsync ! The backup seems to be OK but is NOT! File ownership is not stored correctly in the backup. See also here for filesystems to use. Use tar instead or use ext2/3/4 as filesystem on your backuppartition.
There are various raspiBackup users who successfully save their backups on Synology via nfs. Unfortunately I don't have a Synology and cannot help much on this. But there exists a dedicated page for Synology where raspiBackup users told me what they configured on their Synology in order to save their backups successfully.
In about 98% situations this is true. But a firmware update can change the bootpartition. There is a configuration parameter DEFAULT_LINK_BOOTPARTITIONFILES which causes raspiBackup to link the bootpartition backups with hardlinks if they are supported. That way every backup is 60MB smaller. But the bootpartition is nevertheless saved all the time to check whether there are changes to the previous backup and then replaced with a hardlink. This option is useful only if you use a very small backup device.
raspiBackup looks up different places to retrieve its options. The priority goes from low to high:
2) ./.raspiBackup.conf (current directory)
3) ~/.raspiBackup.conf (home directory)
4) Configuration file specified with option -f
5) Invocation options
Option -g enables a progress bar for dd, tar and rsync. Should be used only when raspiBackup is manually invoked.
The errormessage looks like
??? RBK0024E: Backup tool rsync received an error
rsync: set_acl: sys_acl_set_file(media/pi, ACL_TYPE_ACCESS): Operation not supported (95)
default_mntopts = acl,user_xattr
sudo getfacl -Rs /The command will take time.
1) Add following line
DEFAULT_RSYNC_BACKUP_OPTIONS="-aHx --delete" (no uppercase A) in /usr/local/etc/raspiBackup.conf which will cause rsync to exclude ACLs in the backup.
2) Use tar instaed of rsync
4) Use nfs version 2 or nfs version 3. Read this article for details. This option does NOT work with a Synology.
5) Use raspiBackupWrapper.sh which includes code using a loop device to mount an image formatted with ext4 and thus supports ACLs (See this page for details) (For experienced users only)
In Bullseye Debian enabled persistent journaling and now there exists /var/log/journal with ACLs on the system. Everybody using release 0.6.6 or below has to upgrade to release 0.6.6.1 or use the workaround described here.
sudo fdisk -l /dev/mmcblk0
sudo fdisk -l /dev/mmcblk0
Disk /dev/mmcblk0: 15.5 GB, 15548284928 bytes
Disk /dev/mmcblk0: 15.9 GB, 15931539456 bytes
gpartedfor some hundred MB or even 1 GB.
192.168.2.203:/data/raspi /media/nas nfs defaults 0 0
192.168.2.203:/data/raspi /media/nas nfs defaults,noatime,noauto,x-systemd.automount 0 0
--systemstatuslists the active system services in the debug log with their open files. This will help to locate the service which modifies files during the backup.
inotifywait -m -e delete -e create -e move -e modify -e attrib <directory>
101 - Programming error occured
102 - Linux command returned error
103 - raspiBackup was terminated with CTRL C
104 - An extension returned an error
105 - During stop of services an error occured
106 - During start of services an error occured
107 - An option parameter is invalid
108 - Missing files
109 - Backup program dd, tar or rsync got an error
110 - Impossible to create a link to a file
111 - Collection of partition information failed
112 - Creation of partition layout failed during restore
114 - dd image creation failed
115 - Missing required partition
116 - Restore aborted by user
117 - Restore program dd, tar or rsync got an erro
118 - Device missing/incorrect
119 - Unable to create a directory
120 - Missing Linux tools
121 - Unable to find a valid boot partition
|;-)||There is a new release of raspiBackup available. Upgrade should be done with option -U and can be reverted with option -V.|
|:-D||There is a beta of next raspiBackup release available. Beta testers are welcome and can install the beta with option -U and revert with option -V.|
|O.o||raspiBackup wrote a warning message.|
|:-(||Current raspiBackup release has a serious bug is considered deprecated. It's stronlgy recommended to upgrade to the latest release with option -U.|
raspiBackup was written to help Linux beginners to have a convenient way to create backups of their Raspberry. But nevertheless you have to have some Linux knowledge. A lot of issues with raspiBackup are just Linux issues and not raspiBackup issues. It's not possible to help on these issues on this website. There exist foren with a big community. I suggest to visit Raspberry.org and ask for help. Don't hesitate to link me to your post and I'll jump in. My nick is @framp in this forum.
raspiBackup creates a debug log raspiBackup.log and messages in raspiBackup.msg in /tmp directory first and finally copies the logs into the backup directory if the backup was successful. If for some reasons the backup fails the logs are copied into the home directory of the caller.
In general there are new options introduced in a new version. It's possible to add them manually. But it's much more convenient to use a helper script which creates a new configuration file with all the latest options and merges your local options. Merge conflicts have to be solved manually. You find details for the script on this page.
The debug file raspiBackup.log is written into /tmp when raspiBackup runs. If raspiBackup finishes successfully the logfile is moved into the backupdirectory. If raspiBackup fails the backupdirectory will be deleted and the debug log will be copied into the home directory of the caller which will be /root or /home/<user>. Note: If raspiBackup was started via cron the target directory is /root. During restore the home directories will be used also.
raspiBackup supports following configurations but only /boot and /root partitions are saved. gesichert werden. Additional partitions are ignored.
1) /boot and /root on SD card
2) /boot on SD card and /root on SSD or disk
3) /boot and /root on SSD or disk
In the raspiBackup menu on the right side you find links to the most important pages about raspiBackup. If you want to get a list of all pages about raspiBackup klick on the last link in the menu called List of all pages about raspiBackup . If you are interested in special topics use the search capability on hte top right side and insert the topic you're interested in.
That's a question asked a lot of time. In about 80% of the cases it's caused by a defective SD card.
A lot of options can be used to turn something on or off. In general you define everything once in the configuration file and that's it. If you want to turn an option off or on in a single call append + (on) or - (off) to the option. Example: You have enable zipping of a dd backup. You turn it off temporarily with option
Please read this article.
From time to time there pop up Linux issues or questions when configuring or running raspiBackup. I will not answer them in comments or even emails sent to me. I support raspiBackup but I'm not willing to support Linux and thus all such kind of questions will be rejected by pointing to this FAQ47. There exists an English Raspberry forum and there you will get help for general Linux questions or -issues. If you speak German I also suggest to visit the German Raspberry Forum. See also FAQ38.
It's possible but you will get a system which will be unreliable and most of the time not boot. YThat's why raspiBackup rejects this kind of request. You have to connect an USB card reader to your Raspberry and restore the backup to the external SD card.
In 99.9% of all cases it's a bad SD card which causes this issue. Just use another, better a brand new SD card and the issue will be gone. You also can use option -C to check the SD card for bad blocks when you restore the backup. But keep in mind the restore will take a long time now. Please also read this article about issues with a dd backup.
The backup and restore time depends on the amount of data to save and the speed of the backup partition. If your backup partition is mounted via a network protocol (nfs or Samba) it even will take loger. If you use rsync the first backup will take long because it's a full backup. All next backups will be incremental backups and usually faster.
It may happen the backup or restore does not terminate or will take extremly long. That's usually because there are backup errors. In general it's either read- oder write errors reported by the Linux backup tool used (dd, tar or rsync). If you use rsync it may because ACLs cannot be saved because either authorization is missing or ACLs are not supported on the backup partition. ACLs are not supported if your backup partition is connected via nfs or samba. See FAQ24 for details.
Check whether mount option sync is used and use async instead.
Option --timestamps should be used to get an idea in which step raspiBackup spends so much time. Next the debug log will help to nail it down further.
raspiBackup does not do any calculations. Instead the available options of the backup tools are used. For dd option status=progress and for rsync option info=progress2 is used. tar does not have a progress option and thus the Linux tool pv is used to pipe through the tar data. For details about the statistic calculation check the documentation of the tool options and pv.
You have to use following script im github. Invoke it with
curl -s https://raw.githubusercontent.com/framps/raspiBackup/master/scripts/raspiBackupDownloadFromGit.sh | sudo bash -s -- <branchname>
<branchname> has to be the git branch name where you want to download raspibackup.sh. Then invoke this raspiBackup version in the following way:
sudo ./raspiBackup.sh <options>
raspiBackup snapshots are backups with two special properties:
1) They are not included in the backup recycle and thus have to be deleted manually in the backup directory
2)They have a description which is inlcuded in the backup directory name which allows to identify a snapshot and the reason why it was created.
A snapshot will be created with option
-M and is very helpful when you setup a new system or change an existing system. Create a snapshot at any major installation or update steps. In case something goes wrong you can revert to any previous snapshot and start over. The description helps you to identify the snapshot you want to revert to.
raspiBackup stores the boot partition in an image file. Execute following commands on a Raspberry to access the contents of the boot partition in your backup directory:
sudo losetup -f <hostname>-backup.img
sudo mount /dev/loop0 /mnt
During restore of a backup the PARTUUID of the original system is used for partitions. Iy ou mount this restore system on the original system you will see the PARTUUIDs twice and you usually will get issues when you boot the original system. For these cases there exists option -updateUUIDs for restore to generadte a different PARTUUID during restore.