My UrBackup installation has been ‘Checking database integrity’ for the past 6 hours. Is it means to take this long? According to the log, it’s checking the backup_server_files.db:
03/06/17 03:42 INFO Checking integrity of backup_server.db
03/06/17 03:42 INFO Checking integrity of backup_server_settings.db
03/06/17 03:42 INFO Checking integrity of backup_server_files.db
The local time, as of writing, is 09:37.
This file is 16Gb, and this is on a standard spinning disk, rather than an SSD, but even so - it seems an extremely long operation? While this is happening, my backups are queuing and stuck.
Total DISK READ : 1050.02 K/s | Total DISK WRITE : 11.71 K/s
Actual DISK READ: 1050.02 K/s | Actual DISK WRITE: 50.74 K/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
2359 be/4 colord 476.22 K/s 0.00 B/s 0.00 % 99.40 % urbackupsrv run --config /etc/default/urbackupsrv --daemon --pidfile /var/run/urbackupsrv.pid
Interestingly iotop shows that urbackupsrv is using up 100% I/O, but only at about 500K/s. I know that these disks can transfer much faster than that… Is something wrong with the integrity check operation? Is there a way for me to find out? The backup_server.db file is 50Mb, and that appears to have been done in less than a minute, so it would appear something is wrong here?
Just to add to this - I’ve just tried to copy the backup_server_files.db file onto another filesystem and I’m getting roughly 25-30Mb/sec speed while this database integrity check is still underway.
So does the integrity check involve lots of random disk seeks or something? Would that cause the issue and be much better on an SSD? Unfortunately my current setup precludes me from using an SSD on this server, so I’m trying to figure out if there’s anything else I can do.
I was experiencing the same problem before, the only way to speed-up the process was moving datas on a SSD storage.
This is why i moved all my backups to image backups only.
File level restore is now easy with the ability of mounting images through UrBackup GUI
It is a nightly check before the internal database backup. You can disable “Automatically backup UrBackup database” and do the backup using some other method (one method is installing a UrBackup client on the server). That is something that should be done with larger installations anyway (see manual https://www.urbackup.org/administration_manual.html#x1-540008.1.12 )
7 hours is a little bit excessive but it is probably due to the random IO with spinning rust.
I would like to do image backup or file backup only. could you share your experience about “image only” backup. will your user need to restore the files by them self? or you just need to restore everything by administrator?
In our company, backups and restore are managed by admins only, no user access.
However, if you plan to use image backups only, you can still create a new user and allow him to access the needed client(s). With this method, the “Access backups” shortcut via the tray icon will not work, customer would have to login directly from the server’s web GUI to access backups and then browse and restore files via mount image …
but it is probably due to the random IO with spinning rust.