# How to test a backup?



## hockey97 (Jun 26, 2012)

Hi, I would like to know how to test a backup created in a bz2 compressed format? I just want to make sure my backups will work flawlessly. I mean what would be the point to backup something and when you need it then you find out it's corrupted or something went wrong.


----------



## jrm@ (Jun 26, 2012)

`# bzip2 -t compressed.bz2` will check the compressed file(s).

If you have the space, you could decompress the file(s) to a new location and do a diff with the original.

Also, bzip2() "uses 32-bit CRCs to make sure that the decompressed version of a file is identical to the original."


----------



## SirDice (Jun 26, 2012)

Yes, excellent idea. Definitely test your restore procedures.

As noted by jrm, the best way would be to do a complete restore. Preferably on a scratch disk.


----------



## vermaden (Jun 26, 2012)

hockey97 said:
			
		

> How to test a backup?


Restore.


----------



## hockey97 (Jun 26, 2012)

vermaden said:
			
		

> Restore.



Yeah, but wouldn't that overwrite the data on my hard drive? I mean if the backup is corrupted and I test by restoring the corrupted data. That would then render my hard drive useless. It would overwrite the data with corrupted data. I am asking for a safe way where I can test that it's a working backup without having to restore and finding out *I* just messed up my hard drives. I only have two hard drives. One is internal hard drive a server drive and one is a external hard drive. 

I just want to verify that the correct data got backed up and that it can restore without any problems. I just don't want to blindly make a backup of my whole hard drive and then when I need to restore the drive I find out the backup is corrupted. I don't want to monkey around with the internal hard drive. I can't afford to mess it up. I need some other way rather then restoring the backup.


----------



## vermaden (Jun 26, 2012)

hockey97 said:
			
		

> Ya, but wouldn't that overwrite the data on my hard drive?


1. Restore into other machine
2. Restore into virtual machine (VirtualBox / QEMU)
3. Restore into Jail
4. Think


----------



## hockey97 (Jun 27, 2012)

vermaden said:
			
		

> 1. Restore into other machine
> 2. Restore into virtual machine (VirtualBox / QEMU)
> 3. Restore into Jail
> 4. Think



Yes, but my concern is that I won't have the space to test it on my hard drive. If I go to Virtual Box  route. If I restore the backup. How would it take up the space? Or can I just simulate the restore and after seeing it work. The restore wont affect my computer at all? 

I never tested a restore nor never have used Unix to make a backup and restore a backup. So everything is pretty new to me. I never did use a virtual box. I would like to know if going the virtual route way if it will use up my hard drive space?


----------



## vermaden (Jun 27, 2012)

hockey97 said:
			
		

> I never tested a restore nor never have used Unix to make a backup and restore a backup.



Here mate:
http://www.halfgaar.net/backing-up-unix
http://freebsd.org/handbook/backup-strategies.html
http://freebsd.org/handbook/backup-basics.html


----------



## wblock@ (Jun 27, 2012)

Pipe the output of restore(8) into mtree(8), having it create a listing with md5 checksums.  diff(1) that against a list generated from the actual files.


----------

