0

There are several servers under CentOS with PHP projects, and the task is to make a server (or servers) for them to store yesterday's versions of uncompressed files of all projects from all servers, while simultaneously synchronizing lists of users and giving them access to the appropriate folder, as on the original server. It would seem that the task is not difficult? What implementation options I could come up with:

  1. Create one common backup server, where project files + groups + users from each server will be copied every night using rsync. But in this case, difficulties arise with the user UIDs; it will be necessary to reassign them on the backup server, plus change the owners of the files. And it is unknown how rsync will react to a different owner, since if it downloads the entire file each time, this option is unacceptable.
  2. Create backup servers according to the number of source servers, copy all project files + groups + users every night using rsync. The UIDs of users and groups on the files will be correct, however, it will be necessary to manually split the backup partition into several small ones in order to mount them to different servers. And manually adjust their size if necessary. And I wouldn’t want to increase the number of backup servers.
  3. Use svn/git for this and create a separate repository for each project. It would be possible to store the entire history of changes for all projects, but this option is also not without flaws, starting at least with user synchronization, and ending with the need to create .git/.svn directories that may already exist on client projects.

Has anyone encountered similar tasks? Maybe there are some opensource projects that implement all the necessary functionality? Thank you!

Improve this question
2
  • 1
    Can I suggest a more modern CI/CD approach? Setup a Git / Ci / CD. For example GitLab on-prem, copy those projects over to GitLab and setup proper authentication and authorization. Make sure GitLab is properly backup-ed. Wit Gi a developer himself can easily go to a yesterday or days before that php code. Setup CI-CD pipelines to push approved and tested code to the servers.
    – Ace
    Oct 9 at 4:39
  • Backup and version control are very different exercises - it sounds like you're trying to implement version control. Use a VC service.
    – symcbean
    Oct 9 at 9:29

2 Answers 2

Reset to default
1

Backup protection storage exists to restore files as they were. And yes, this includes metadata like owner and permissions.

I'll add an additional requirement that some tier of the backup storage is as difficult to alter as is reasonable. Also known as ransomware insurance. Cold storage media like tape. Pull backup methods were the backup system downloads the data, the hosts being backed up have no access to change the backup. Regarding people, only backup administrators should have users that can log into the protection storage, no one else needs to be able to touch it.

Your file copy ideas imply a backup server that is synced with every user who owns a file. Such as joined to a central user directory. While nice for a rsync target, a snapshot mount host, or a file share host, that's difficult to make work with my idea of an isolated protection storage. And in environments that don't have strong management of user IDs, it can be surprisingly messy. Test how user names are preserved on such volumes. For example, note that rsync will try to map names but might fall back to numeric IDs. Numeric IDs might work for restoring back to the same host, but what about when copying the file to a different host with a uid conflict?

Consider in addition a backup software that can record user name in its archives. For example, tar will record this, and some flavors can also include ACLs. Then the archive can be stored on whatever blob storage. Many archives, from different hosts, can be stored on a very large protection storage if desired. Not recommending tar over anything else, just noting that containers that also store metadata have existed for a long time.

Version control systems are not ideal for backups. I don't want to merge histories and resolve their conflicts, I want the simpler thing of store this tree. git (without extensions) does not preserve file owner or permissions, which fails that requirement. Also, some version control systems keep objects around as long as they are referenced, which complicates deleting backups older than however many days.

As always, test backups by doing restores. Spot check the restores integrity, and know how long it takes to recover.

Improve this answer
-2

Maybe you can try a third-party software like Vinchin Backup & Recovery to simply the job.

Improve this answer
New contributor
Bethanie Kristeen is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .