UrBackup Server/Client/Restore 2.0.0 beta was recently released. This marks the beginning of the UrBackup 2.0 beta phase.
See the forums for download links and discussion.
UrBackup 2.0 marks the beginning of UrBackup having no major limitations. If you still find some please start a discussion in the forums. The next beta version will also properly support sparse file backup.
Letsencrypt is in public beta now. As promised I switched the main page as well as the download site to SSL. The main page redirects to HTTPS and therefore cannot be accessed without SSL anymore.
The Letsencrypt certificate causes the main page to not work with Windows XP anymore. That are 2,6% of all visitors to that page. They are working on a fix for that issue, though. Let me know if there are any other problems.
By always being on a SSL-protected site you can be certain you are getting the official UrBackup binaries even if an attacker is able to modify your network traffic.
Currently the next major UrBackup version is kind of close to getting finished. There are a few major work in progress areas. Once they are finished and I have done some overall testing I will release a beta version.
The major changes in the new version are:
- Completely reworked the file deduplication and file backup statistics calculation. This should be much faster, scalable and reliable now.
- The Copy-on-Write image backups on btrfs mentioned in the last post. Synthetic full backups for the VHD/VHDZ file format and settings for basing image backups on the last full or last incremental backup (differential/incremental).
- File backups include file metadata including file modification time, ACLs, alternate data streams etc.
- Backup of streaming data. E.g. the output of “mysqldump”/”pg_dump”. I plan to add basic backup scripts for popular Open Source databases to the client
- New file restore feature which restores file backups and properly restores the file meta-data
- The ACLs/file permissions are used to enable users to directly access backups on the web interface from the explorer on the clients (via right click -> Access/Restore backups)
- Proper backups of symbolic links. Symbolic links which point to folders/files which are backed up are backed up as symbolic links and symbolic links which point outside of the selected backup set are followed/not followed depending on a setting
- The web interface has been bootstrapified (http://getbootstrap.com/ – mombojuice did the work) and looks much more modern now
- Simultaneous image and file backups
- Backup and restore EFI boot sector and partition on UEFI systems. Restore CD that boots with UEFI firmware
- Client for Mac OS X
- Forward secrecy for Internet clients via ECDH and Internet client security improvement by using AES-GCM
- Switch from DSA to ECDSA for client update and server identity signatures
Still to do:
- Lot’s of testing and bug fixing
- Backup and restore of file meta-data on Mac OS X and Linux
- Symbolic link backup handling on Mac OS X and Linux
- Automatic client update for Mac OS X like for Windows
- Restoring files which are in use on Windows (via restarting)
- Update Documentation
Remaining UrBackup limitations (to be done after with a subsequent version):
- Recognize hard links and backup the files only once
- Backup only used areas of sparse files
- Continuous file backup
Once the “to do”s are done this is a big step forward for UrBackup. Having streaming file backups and incremental, differential, synthetic full and full image backups basically allows you to implement pretty much every backup strategy with UrBackup. The only thing missing is the continuous file backup and I already started work on that.
For example you could use UrBackup instead of TimeMachine on Mac OS X and do a full system restore via the file restore feature (this is not implemented at all – it is just an example what it might be able to do). You probably don’t even need an image of your Windows system partition but can restore it via the file backup restore (albeit inefficiently, because the hard links in C:\windows\winsxs are not handled properly).
Currently UrBackup is storing images of volumes as VHD (Virtual HardDisk) files. In UrBackup Server 1.4 the VHD file format was augmented with a custom compression. This combination gives following advantages over storing images as „raw“ files:
- Only used parts of the volumes are stored to the VHD files (sparse image)
- If the compression is enabled, the volume data is compressed
- Incremental image backups: A VHD file can reference another VHD file, so unchanged data does not have to be stored twice (differential image)
All this can be implemented with btrfs. Volume images can then be stored as raw files:
- There is a Linux system call to „punch holes“ into a file. Btrfs supports this. Using hole punching only the parts of the raw image file which are used are stored
- Btrfs has a compression feature
- You can copy a file on btrfs without copying the data the files contain. You can do this in a Linux console via „cp –reflink=always“. A file copied this way only adds another reference to the file data. The file only becomes a “real” copy at changed parts of the file (Copy on Write).
An incremental image backup can then be done like this: Create reflink of the last image backup, change the parts in the image file that have changed since the last image backup and then punch holes into the file to remove unused parts.
As you can see, this moves the implementation of compression, sparse image support and differential image support into btrfs, which is a good thing, because btrfs is starting to get widespread adoption.
The implementation using btrfs has several advantages:
- The volumes are stored as raw files, which makes inter-operation easier. For example you can directly map the file to a Linux volume device, which makes the file look like a volume on a hard drive.
- UrBackup can delete any image in the incremental backup chain and btrfs takes care of cleaning up the unused blocks. This makes running infinite incremental image backups viable. After the initial full backup you only need to make incremental image backups
The only disadvantage I saw till now is that UrBackup cannot accurately display the size of incremental image backups anymore. It always shows the size as if it was an uncompressed full image.
This new image file format will be available in UrBackup 1.5 if UrBackup is configured such that it uses btrfs.
If you are planning on setting up a larger UrBackup server instance you will find some hints about performance in this post. “Large” in this context is difficult to define, because it depends on the number of clients, the number of files and file sizes in the backups and the backup intervals.
If you plan on setting up a “larger” UrBackup instance you should keep the following things in mind:
- UrBackup uses an internal (SQLite) database. This database could cause performance problems, especially with a large number of backed-up files and full file backups. The database should be stored on storage suited for databases.
- UrBackup has some tuning options, but is nevertheless pretty optimized per default. You should only have to tune UrBackup in special circumstances. You will find information about the tuning options in the administration manual.
- There are many platform options and each has its own considerations, so you should read up on the platform-specific performance considerations. For example you should not run FreeNAS virtualized.
Your system will almost certainly be IO limited. If you have a running system you can verify that by looking at the performance monitor on Windows, iostat on Linux and zfs iostat on FreeBSD. Often it is limited by random read/write performance (Input/Output operations per second).
If you want maximum IO performance following should therefore be the case:
- The UrBackup database should be on an SSD. This should be a no-brainer, as this database does not get too large and SSDs are way faster than spinning disks. The random reads/writes are for example 900 times faster with a Samsung 840 Pro (97K IOPS).
- The UrBackup database should not be on the same disk as the backup storage.
- The UrBackup database should not be on a RAID-5, as this is not optimal for databases.
- If the database is still the bottleneck (because it is a separate device you can find this out using iostat or an equivalent), you can use the “file entry cache” (see manual). This cache should be on a separate SSD, otherwise it will only cause more IO on the one device.
- Save the filesystem metadata of your backup storage on an SSD and only the actual data on a spinning disk RAID-5/6 to get the maximum performance. This is only possible with btrfs on Linux.
- Avoid full file backups. When doing a full file backup UrBackup has to load all files, calculate their hash value and look this value up in the database. This incurs a lot of IO on both the database and the backup storage (and the client). UrBackup can run an infinite amount of incremental file backups without any full file backups.
- Optimize the maximum number of concurrent backups such that the throughput is maximized.
Ways to absolutely kill performance:
- Save the UrBackup database on ZFS/btrfs on a spinning disk. Databases (those who use WAL or intent logging; including SQLite3) on ZFS/btrfs are a known pathological case for copy-on-write file systems. The database files get horribly fragmented. Btrfs has a (currently disabled per default, because it is not stable) background defragmentation for that, but ZFS does not.
- Save the UrBackup database on a RAID-5. See http://www.baarf.com/.
- A lot of full file backups.
- Enable ZFS deduplication without having enough RAM for the dedup table. See here for a discussion.
Because the file transfer in UrBackup 1.4 was changed, I wanted to test it with a second layer: During the file backup a Python script which goes over all files in all backup paths on the client, selects a random subset and calculates the md5-sums of this random subset. On the server those md5-sums are then verified.
Turns out file tree walking in Python on Windows has a few issues.
First of all, even though the os.walk function has a „followlinks“ parameter, this parameter does not work on Windows with Junctions. In particular it followed the compatibility junctions in the C:\Users\Username folder causing an infinite loop, till the file system complained about the path length (32k). Usually this is not an issue, because users seem to not have the permission to use those junctions, but the UrBackup client backend is running as a SYSTEM-service.
os.path.islink returns False for those junctions.
os.path.realpath does not return the target path of the junction.
To solve this I had to install the Python for Windows extensions and manually call the respective API functions. The Python for Windows extensions does not define the FILE_ATTRIBUTE_REPARSE_POINT file attribute constant. So I had to use the value explicitly. Solution:
attrs = win32file.GetFileAttributesW(path)
return attrs & 1024
print("Error with GetFileAttributesW with dir "+path)
output = 
for root, dirs, files in os.walk(path):
for name in files:
torm = 
for cdir in dirs:
if is_reparse_point(os.path.join(root, cdir)):
for cdir in torm:
Current hard linking incremental file backup schema
Currently files which are unchanged between incremental file backups are hard linked. This means there exist more than one file paths for the same data. The advantages are
- The operating systems takes care of managing the data. If there are no file entries pointing at the data it deletes it. Removing a backup means removing a folder.
- Every file backup looks like a full backup on the backup server. This makes restoring and browsing file backups really easy.
But there are some issues in some cases:
- On some filesystems and/or slow hard disks the hard link operations are slow (NTFS) and are the bottleneck during backups.
- Some filesystems only have a limited amount of available file entries (ext e.g.).
With a lot of unchanged files between incremental backups it is almost certain the hard linking operation is the bottleneck.
To improve this situation UrBackup server 1.4 will create symlinks to large directories which are completely unchanged during incremental backups. This avoids a lot of the hard linking operations.
Symlinking large unchanged directories to a pooled directory
If, during incremental backups, a large unchanged directory is detected it is moved into a client specific directory pool. Then a symbolic link in the current and last backup to the directory in the pool is created. If the last backup already contains a link to the pool a symlink in the current backup is created to the pooled directory. Because the operating system does not count how many symbolic links point to a directory, the number of symlinks per pooled directory is saved into UrBackups internal database. If a backup is deleted and has symlinks the relevant entries in the database are removed. If there are no entries for the directory in the database the pooled directory is removed.
There are some caveats:
- There are now symbolic links in the backups. Some tools may not be able to handle them, or need to be told how to handle them.
- If you rename the backup folder all symbolic links are invalidated and won’t work anymore. The UrBackup server has a tool to fix that, but it will be slow.
- The reference counting of symbolic links has some tricky corner cases and needs some testing.
- You cannot just delete file backups anymore as then pooled directories may not be deleted. The UrBackup server includes a tool to detect that, but this might be slow with an increasing amount of directories in the pool.
The symbolic linking of large unchanged directories will be the default behavior in UrBackup server 1.4, though you will be able to deactivate it in the advanced settings. UrBackup server will not symlink directories on btrfs, as there the snapshotting provides a superior method to do fast backups.
I moved the blog from Sourceforge to a different server, because the spam detection plugins of WordPress do not work on the Sourceforge webspace. The comments should work now. Sorry for the inconvenience.
It has been a while and there are now a lot new features in UrBackup Server 1.3.
Users of the web interface can download a Client specific installer directly from the server now. The installer has the UrBackup Server information embedded, such that the client automatically connects to the server once it is installed. I’ve also published a script that connects to a UrBackup server, creates a client named like the local computer and then downloads and executes the client installer. This enables a one click setup experience for Internet clients.
The new live log lets you see what the UrBackup server is currently busy with. You can either see all debug level log messages or client specific log messages.
You can see which files the UrBackup Server is currently working on and the usual log messages which you can also view afterwards via web interface or on the client.
A “hidden” feature is now accessible via web interface: You can disable any type of backup for any client.
More fine grained permissions for the client allow you to prevent the users from starting full file backups, but still allow incremental file backups.
The soft client quota allows you to limit the amount of storage each client can use. During the nightly cleanup UrBackup deletes the client’s backups until the storage usage is within the bounds prescribed by the soft client quota. Other than a percentage value you can also use something like “20G” as soft client quota.
You can now have separate backup windows for incremental/full file/image backups.
Client-side file hashes prevent the re-transfer of files that are already on the server, e.g., because another client has the same file. In some situations this drastically reduces the bandwidth requirements and speeds up file backups over Internet.
If you have performance problems with file backups the new file entry cache may help you. If the file entry cache is enabled file entries (a mapping from file hash to file paths) are cached in a separate database which may speed up backups. The caches are automatically created and destroyed if this setting is changed (and the server restarted), but creation may take a long time. LMDB makes heavy use of memory mapped files and is therefore only advisable on a 64bit operating system. It does also create a very large sparse file on Windows. When in doubt use the SQLite cache.
Binaries of UrBackup for Raspian are available now here (Update: See the nighlty builds or the “wheezy” folder of Debian of the official releases). Performance isn’t that good on the raspberry pi, obviously. I’d avoid using any kind of compression, for example.
First setup the backup storage. I suggest using btrfs. Plug in a USB-hard disk and create a partition, e.g. using cfdisk. Then install btrfs and create the filesystem:
apt-get install btrfs-tools
Add an entry to /etc/fstab to automatically mount the USB-hard disk:
/dev/sda1 /media/backup btrfs defaults,nossd 0 0
Then mount the hard disk:
Download the UrBackup server package and install it:
dpkg -i urbackup-server_1.2-1_armhf.deb
Resolve the dependencies:
apt-get -f install
Enter e.g. /media/backup/urbackup when it asks for the backup storage path.
UrBackup server should run now and automatically backup clients as soon as you install the UrBackup client on one of your PCs in the local network (from here). If you want to change any settings you should go to the web interface. Let 192.168.0.42 be the IP of your raspberry pi. You can then access the web interface of UrBackup via typing http://192.168.0.42:55414 into your address bar. If you want to access your files you should share /media/backup/urbackup e.g. via samba. There are guides on how to install samba on a raspberry pi (here for example).
Sidenote: I’ve heard that it runs even better on a Cubieboard. It has a SATA-port so the USB-Bottlenet is gone. Unfortunately, they’re even harder to get than Raspberry Pis.