I’ve got URBACKUP working (using docker / latest version) - and things appear to be working well.
One of the things I do however, is to backup to an external hard drive to protect against disk crash/corruption etc.
Do you have any information over what I must copy to backup, and what is optional? - for example, I can see there’s loads of ‘hash’ files - if these are only used to work out whether a file has changed, then I would think that I don’t actually need them in the ‘offsite’ backup - which would only be used to perform a restore…
Am I correct? - also are there other file types/directories that I don’t need to copy…
I interpreted @carlbeech to mean they wanted to “duplicate” on-site backup in the server backup original location onto “off-site storage” (USB drive). A “backup of the backup” so to speak.
I searched through the posts. The nearest I could find to my interpretation, if that is the case, is the following reference:
It sounds “promising” to extract certain folders onto an offsite storage device. Then if needed put those extracted pieces back where they belong.
your interpretation might be different. But it might point you in the right direction.
Yep - sort of on these lines… to hopefully explain a little better…?
I have PCs/Servers, these are backing up to a URBackup server…
The URBackup program has a number of sub-directories, where it stores all the backup information - so the question is - while I could take a backup (i.e. copy to an external disk) of all the directories on the URBackup, do I need ‘all’ of the directories and files… as mentioned there’s directories with hundreds of ‘hash’ files… I’d like to not copy these unless I have to… - it takes time and space to copy these off…
If I lost the server or disks holding the URBackup database and all the backed up files, I want to be able to copy them back from the external disk and be able to carry on.
So, its not just about the backup ‘database’, its about the database and all the files / images that URBackup creates…
Hope that clarifies…?
Thanks
Carl.
That is about the database, those files can just be copied straight up whenever.
No it doesn’t, that is the DATA that you back up, the actual files and directories.
The INFORMATION (hashes and such) is stored in the database files in a single directory at a different location.
If it is the DATA you are backing up you are talking about it’s doable, but not by just copy/paste (most likely)
I do this with btrfs, I can copy (send) selected btrfs snapshots to another btrfs drive, making a copy of the backup.
No info from you is given about your system so I can not recommend anything, but I can tell you this, it’s NOT just copy/paste (unless every single backup is a full file backup).
Perhaps (for a *nix system) rsync –az –H –numeric-ids sourcedestination which retains all hard links.
Would rsync the whole client subdirectory copy, in essence all of the data from the backup storage location to an offsite storage unit?
I think the question would be what is the purpose of the offsite storage unit? To put back in the original backup storage location if something goes amiss? Or to have the data that is backed up offsite so that it can be restored if disaster strikes. From what I can see, all of the subdirectories/hardlinks are to files that can simply be copied and used as needed. Now putting the entire structure back into the original backup storage location might be a bit more demanding.
@carlbeech I guess there are some clever ways to save a little bit of space by cherry-picking directories to copy, but do you really want some wacky hacks on your backup system? Personally, I don’t.
Since you are on linux already I think a lot safer and better solution would be to invest some time and set up btrfs or zfs replication to a remote location or cold storage, that would definitely solve your time and effort issues plus you can pretty much automate it.
In any case, don’t forget about whole /var/urbackup directory.